Editor’s Note: The following is an article written for and published in DZone’s 2026 Trend Report, Security by Design: AI Defense, Supply Chain Security, and Security-First Architecture in Practice. 

You may read the full-length article here.

AI has hit the gas pedal on software delivery. We are shipping more code, more often, and relying on automated logic and external dependencies, which expand the attack surface beyond what existing practices were designed to catch.

Research studies and industry reports show that up to 78% of AI-generated code may contain security vulnerabilities, with over 20% falling into the 2023 CWE Top 25 categories. These agents are already part of the development workflow, and soon, teams may operate with little or no humans in the loop. When this happens, clear ownership and accountability disappear. This will impact governance teams as productivity slows when teams start questioning what they can actually ship securely.

Security must be an enabler, so the answer isn’t to slow down productivity. In this article, we explore how to introduce continuously enforced security controls into the SDLC, CI/CD pipeline, and execution runtime to scale with AI automation, and how the threat model, architecture, and ownership must adapt to support security-first delivery.

The Threat Model Has Changed, and It’s Not Subtle

LLMs are trained on huge code datasets that often include outdated frameworks, deprecated APIs, and insecure patterns. They do not distinguish between code that has “worked once” and what is safe in a given environment. At scale, an insecure coding pattern can be reproduced across hundreds of codebases, creating systemic vulnerabilities.

These gaps also give attackers an advantage, speeding up tasks like recon, phishing, and exploit variant creation.

GenAI tools introduce new security risks and failure modes that traditional security tools and threat model reviews aren’t designed to catch.

Periodic security reviews and CVE-based scanning miss most of these security risks because they only look for patterns and cannot see runtime behavior.

Security Moves Into the Pipeline and Runtime

In an SDLC where large parts of the code are produced by AI, human security reviews can’t scale with the volume or velocity of dev teams. Some unreviewed AI-generated code will reach production, and that must be accounted for in the threat model. Zero trust must apply even to our own code, not only to external input.

AI agents need to be treated as members of our workforce. They make decisions, produce artifacts, require first-class identities with clearly scoped roles and ownership, least-privileged access, auditable actions, and automatic lifecycle controls like any privileged service account.

Whether code is written by a developer or an AI, zero-trust enforcement must move into the pipeline and runtime through Policy as Code to ensure builds that fail attestations are blocked, dependencies are signed, builds are reproducible, and artifact provenance is checked before deployment. As AI pipelines become part of the attack surface, they must be secured with the same assume-breach, verify-everything mindset.

At runtime, detection focuses on what actually happens. Execution traces, taint metadata, entry points, sinks, and provenance show how data flows and which code paths were exercised. Continuous runtime enforcement agents should be able to block or quarantine malicious behavior. False positives must be low, and containment has to be accurate, fast, and deterministic.

AI already improves detection and remediation by triaging and clustering related findings, but it can’t replace prompts and more context. Even if agents attempt to fix their own mistakes, many issues remain undetected. Without security controls and runtime enforcement, these become production vulnerabilities waiting for exploitation.

Responsibility Shifts: Security Is a Product Constraint, Not a Team

As AI-generated code accelerates and security teams shrink, security must become a product constraint, just as availability and resiliency are. It must be enforced by the platform by default and not rely on subject matter experts to detect based on their capacity and constraints.

This shifts ownership. Security teams define security invariants and requirements with product owners, which product and engineering teams turn into enforceable controls across the SDLC.

Here are some fundamental steps we can take:

• Build secure-by-default templates and golden paths, including hardened templates, prompt libraries, and LLM security baselines. 
• Accept that manual PR reviews do not scale; automating PR reviews requires accuracy to avoid false positives. Tools like IAST detect vulnerabilities early and provide security context.
• Accept that not all AI hallucinations are caught at the code level; enforce runtime monitoring. If an AI agent attempts access to metadata services, unauthorized APIs, or sensitive data, block the operation immediately.
• Automate evidence capture; compliance and auditing can’t be manual, and every action needs a telemetry trail.

The only way we will successfully turn security into a scalable product constraint is by building platforms that make insecure code impossible to deploy or perform unauthorized operations.

Continuous Governance in CI/CD and Beyond

Most organizations still run governance as if humans write all the code, but this breaks with AI-generated systems. Without strong observability and lineage tracking, we can’t explain agent decisions or pass audits in regulated environments.

We’re no longer just shipping binaries but also system prompts, model weights, and agent logic. This introduces risks like system prompt leakage, unintended data exposure, and use of licensed code. To handle this, we need supply chain transparency for AI. Track these components with an AI bill of materials (AI-BOM), recording model versions, fine-tuning data, plugins, and connectors, and correlating each artifact to a human or agent owner.

Governance must run continuously, not as a quarterly checkpoint. Automated security and compliance gates in CI/CD should evaluate intent, not just source code. Monitor for prompt drift, where model updates bypass safety filters.

Source control must be our single source of truth, with every AI-generated commit tagged with its prompt and model. This enables attributable authorship to prove that an AI-generated vulnerability has been reviewed by a human or an autonomous assurance gate.

AI Agents in DevSecOps: Helpful Coworkers or New Attack Surface?

We are deploying AI agents that can approve PRs, merge code, and trigger deployments, turning our DevSecOps pipelines into autonomous execution environments. When AI agents can approve PRs, deploy artifacts, or run playbooks, they become primary targets for attackers. 

Consider the following security principles when using AI agents in DevSecOps:

If done wrong, the security implications are significant. Anthropic’s research into sleeper agents showed that models can behave normally until a specific trigger makes them act maliciously. In another Anthropic research study, an agent attempted to blackmail a user to avoid being shut down. In a real-world pipeline without any guardrails, a privileged AI agent could function normally, then go rogue and silently inject a backdoor into a PR because it saw a specific string in a commit message.

Traditional testing won’t catch this. Continuous runtime monitoring and AI red teaming are essential to keep agent behavior within authorized boundaries.

What Security-First Delivery Looks Like in 2026

By the end of 2026, more teams will rely on autonomous AI coding agents across the SLDC and DevSecOps. Increased productivity should not sacrifice security, nor should it become the bottleneck. Scalable security becomes a continuous, context-aware function built into the platform. We move away from “stop-and-fix” cycles toward evidence-driven enforcement that monitors agent intent and validates actions in real time.

If you use AI agents in your infrastructure, or plan on using them, consider a few security investments for 2026: policy automation (e.g., OPA, Kyverno); unique, scoped identities with strictly limited permissions; AI-BOM and provenance tracking; runtime security (IAST, RASP, observability); telemetry and anomaly detection; data leakage prevention; and continuous AI red teaming.

AI is now security-critical infrastructure. Security-first AI infrastructure is no longer optional, and we can achieve this only with accurate security controls that scale with release pace and automation.

Recommended resources:

• Adversarial Threat Landscape for Artificial-Intelligence Systems (ATLAS), MITRE
• AI Risk Management Framework, NIST
• OWASP: GenAI Security Project, Top 10 for LLMs, AI Exchange
• “A Comprehensive Guide to Protect Data, Models, and Users in the GenAI Era” by Boris Zaikin
• “Securing AI Agents Is Now Critical and Most Companies Aren’t Ready” by Arjun Subedi
• “The AI Security Gap: Protecting Systems in the Age of Generative AI” by Tom Smith
• Generative AI: From Prototypes to Production, Operationalizing AI at Scale, DZone Trend Report
• Getting Started With Agentic AI, DZone Refcard by Lahiru Fernando

This is an excerpt from DZone’s 2026 Trend Report, Security by Design: AI Defense, Supply Chain Security, and Security-First Architecture in Practice.

Read the Free Report