Security Risks in AI-Generated Code

The Veracode 2025 GenAI Code Security Report tested more than 100 LLMs across four programming languages and found AI-generated code contained 2.74 times more vulnerabilities than human-written code; only 55% of AI-generated code passed secure coding benchmarks. Apiiro's analysis of Fortune 50 enterprises found CVSS 7.0 and above vulnerabilities appearing 2.5 times more often in AI-generated code, with 322% more privilege escalation paths and a 40% increase in secrets exposure. A 2024 empirical study of GitHub Copilot analyzed 733 generated code snippets and found that 29.5% of Python samples and 24.2% of JavaScript samples contained security weaknesses including cross-site scripting and improper input validation.

That last number is the one I keep returning to. Nearly one in three Python snippets from a widely deployed, commercial coding assistant. Not prototype tooling. Not a research toy.

Volume is what converts a quality problem into a systems problem. By June 2025, AI-generated code was adding over 10,000 new security findings per month across studied repositories, a tenfold increase from December 2024. GitHub's 2024 developer survey found 97% of developers using AI coding tools. Checkmarx found that nearly 70% of CISOs, AppSec managers, and developers estimated more than 40% of their organization's code was AI-generated. Dario Amodei suggested in April 2025 that 90% of code could be AI-generated within three to six months. CodeRabbit's December 2025 analysis of 470 open-source pull requests found AI co-authored code had approximately 1.7 times more major issues than human-written code.

Multiple independent research streams, using different methodologies and different sample populations, point in the same direction. The more unsettling question is not whether to audit AI-generated code, but whether auditing at this volume is operationally coherent at all.

The Structural Reasons Models Generate Insecure Code: Not Bad Prompts, Not Careless Users

When security teams see these numbers, the first instinct is usually workflow remediation: better prompts, stricter review gates, clearer instructions to the model. Reasonable instinct. Wrong diagnosis.

Models are trained to produce code that is syntactically correct and functionally plausible. Security is not the optimization target. A model trained on open-source repositories inherits the security posture of those repositories, including their vulnerabilities, their outdated patterns, and their context-blind copy-paste habits. A November 2024 CSET Georgetown policy brief identifies contaminated training data as a distinct attack surface: a model trained on insecure code reproduces those patterns at scale, not because a user prompted it badly, but because those patterns are embedded in the learned weights.

The same CSET analysis identifies backdoor attacks as a separate concern. A trigger phrase in a prompt can reliably elicit a specific, attacker-chosen output. The model behaves correctly in nearly every context and dangerously in one crafted case. Standard testing provides false assurance here because the attacker designed the failure mode to evade it. That is worth sitting with: a security posture built on testing can appear healthy right up until it isn't.

Beneath both issues sits the problem of pattern reproduction without contextual reasoning. Models recombine learned patterns; they do not reason about the trust boundary of the code they are generating, the privilege level at which it will execute, or the deployment environment it will enter. A function that is safe in one context can be catastrophic in another. The model does not distinguish between these contexts because safety in deployment was never the signal it was trained to optimize for.

Checkmarx research adds a behavioral dimension that is easy to overlook: developers often do not carefully review AI-generated code. Automation creates a psychological license to reduce scrutiny at exactly the moment scrutiny is most needed. The oversight gap is not purely technical.

Better prompts and code review do catch surface issues. They do not touch the underlying generation mechanics. If the defect is upstream of the review step, the fix must also be.

How the Threat Surface Expands When AI Agents Execute Code Autonomously

An LLM generating code for a human to review is a meaningfully different threat model from an agent that generates and immediately executes code against live systems, databases, and APIs. The security literature has been slow to reflect this distinction, and the gap shows.

OWASP released a Top 10 list specifically for agentic AI systems in late 2025, a framework distinct from its earlier LLM application list because it addresses threats that simply do not exist in static chatbot deployments: uncontrolled autonomy, delegated identity abuse, cross-agent prompt injection. Prompt injection ranked as the top risk in both frameworks. In agentic contexts, a single injected instruction can chain across multiple tool calls before any human sees the output.

The Anthropic Claude Opus 4.5 System Card from November 2025 quantifies how quickly this compounds. Indirect prompt injection attack success in agentic coding environments was 4.7% at one attempt, 33.6% at ten attempts, and 63.0% at 100 attempts. An adversary does not need to be sophisticated. They need to be persistent, and automated systems are patient by design.

PromptArmor's early 2026 disclosure on Snowflake's Cortex Code CLI illustrated what this looks like in production. Indirect prompt injection combined with weak command validation bypassed human-in-the-loop approval mechanisms and enabled arbitrary code execution with access to cached credentials. The breach did not begin with a stolen password or a misconfigured firewall. It began with a crafted string fed into an agent's context window.

OWASP's 2025 additions, Excessive Agency and Unbounded Consumption, name the underlying failure precisely: agents granted too much permission, running without resource limits, become the exploit. When an agent can browse, execute, query databases, and call external APIs, a single compromised instruction does not produce a bad code snippet. It produces a chain of consequential actions on live infrastructure.

Why the Underlying Container Runtime Is Also an Attack Surface

Security discussions about AI-generated code tend to focus on what the code does. Rarely examined is what contains the code while it runs. That inattention has a cost.

CVE-2024-21626, disclosed under the name "Leaky Vessels," demonstrated the gap. A file descriptor leak in the runc container runtime enabled container escape and direct access to the host filesystem. The vulnerability was not in the code running inside the container; it was in the runtime itself. Standard containers share the host operating system kernel across workloads. A kernel vulnerability exploited in one container can expose other tenants on the same host. The isolation boundary is a software construct, not a hardware one, and software constructs fail.

Model capability compounds the exposure in a way that is easy to underestimate. Frontier models' success rates on apprentice-level cybersecurity tasks rose from under 10% in late 2023 to roughly 50% by 2025, with the first expert-level task completed during that year. Sandbox designs calibrated to 2023 model capability are now being evaluated by a meaningfully more capable adversary. The architecture that seemed adequate eighteen months ago may no longer be sufficient.

Retrofitting generic container infrastructure to address the combination of autonomous agents, increasingly capable models, and container runtimes with known escape vectors is a category error. Purpose-built cloud infrastructure for running untrusted AI-generated code is a different class of solution from adapted dev tooling. It is not a configuration problem.

The Three Tiers of Sandbox Isolation and the Trade-offs That Decide Which Is Adequate

The marketing language around "sandboxing" elides distinctions that carry real security consequences.

Standard containers, including Docker, share the host kernel. They are well suited to development workflows and internal tooling with known, trusted code. For multi-tenant execution of untrusted AI-generated code, the isolation boundary is a software syscall filter. CVE-2024-21626 illustrated how that boundary fails.

gVisor interposes on syscalls using a user-space kernel, blocking a large class of potentially malicious system calls without incurring the full overhead of a virtual machine. It provides meaningful additional protection for compute-heavy workloads with limited I/O requirements; it does not provide a hardware-enforced boundary.

MicroVMs, including Firecracker and Kata Containers, run a separate guest kernel per workload enforced at the CPU hardware virtualization layer. An exploit inside one microVM is contained at the hypervisor boundary. Northflank processes over 2 million isolated workloads monthly using Kata Containers and gVisor, with customers including Writer, Sentry, and cto.new, the last of which handled thousands of daily deployments at a 30,000-user launch.

The practical trade-off among these tiers is a triangle: isolation strength, cold-start latency, and operational complexity. Retrofitted containers optimize for simplicity at the expense of the other two.

Startup speed is not a user experience detail. An agent waiting seconds for a sandbox to provision accumulates that latency across every tool call in a multi-step workflow. At scale, slow provisioning either degrades agent responsiveness or pushes teams to reuse sandboxes across workloads, which defeats isolation entirely. Blaxel's sub-25ms resume for paused microVMs illustrates where the field is heading: durable, snapshotted state that resumes instantly rather than cold-provisioning on every invocation.

What Purpose-Built AI Agent Runtimes Provide That Retrofitted Infrastructure Does Not

The infrastructure layer for AI agent execution has converged around a recognized requirement set: hardware-enforced isolation, sub-second provisioning, stateful persistence across agent interactions, and compliance boundaries that satisfy enterprise data residency requirements. Generic container platforms were not designed to satisfy all four simultaneously.

Several platforms have approached this problem from different directions. Northflank's Kata Containers and gVisor architecture supports multi-tenant deployments at production scale. Blaxel's microVM approach targets the resume latency problem. Microsoft released its Agent Governance Toolkit in April 2026 as open-source runtime security tooling for AI agents, treating runtime governance as a distinct infrastructure layer rather than an extension of SAST tooling.

Some platforms are built specifically for AI agent workloads rather than adapted from general-purpose container infrastructure, providing stateful sandboxes in which filesystem state, environment variables, and process memory persist across agent interactions, with sub-90ms provisioning, built-in language server protocol support for computer-use agents, and SOC 2, HIPAA, and GDPR compliance. Open-source execution environments make the runtime auditable, which matters when the compliance question is not just "did the code pass review?" but "what did the agent actually do, and where?"

The questions worth pressing when evaluating options: What is the isolation tier? How does provisioning speed interact with multi-step agent workflows? Does state persist or reset between calls? Does compute run in your cloud or a vendor's? Is the platform auditable? For enterprises with data residency requirements, the compute location question is not a preference; it is often the compliance boundary itself.

Why Static Analysis and Code Review Alone Cannot Close the Gap That Execution-Level Isolation Closes

Static analysis, dynamic analysis, and human review are filters applied to the output of code generation. They catch known vulnerability patterns before execution. That is valuable work, and the argument here is not against doing it.

But consider the strongest version of the counterargument: if review pipelines were sufficiently rigorous, could they compensate for weaker runtime isolation? It is a reasonable position, and I held something close to it longer than I should have. What changed my thinking was not the theory but the failure modes review tools actually cannot see. They do not intercept indirect prompt injection delivered at runtime through external content the agent retrieves during execution. They cannot account for model capability escalation, because a model capable of finding novel exploits defeats signature-based detection by definition. And they cannot account for an agent invoking the review tool itself and manipulating its output before a human sees it.

The volume problem alone makes review-as-primary-control untenable. A tenfold increase in new security findings per month from December 2024 to June 2025 outpaces any manual review process. No team scales linearly against that curve.

Execution-level isolation addresses the failure mode that review cannot: it contains damage that slips through. An agent executing malicious code inside a hardware-isolated microVM with no network egress and no access to host credentials produces a bounded blast radius regardless of what the code attempts. The perimeter holds at the hardware layer.

Review tools and runtime isolation are complementary controls. Treating them as substitutes, specifically omitting execution isolation because review exists, is the kind of decision that looks defensible in a budget meeting and looks different after an incident. These controls occupy different positions in the failure chain; each catches what the other cannot reach. Execution environments are security controls, not infrastructure conveniences. They belong in AppSec scope, evaluated with the same rigor applied to any other control in the stack.