Code Execution Sandbox Security for Agent-Generated Code

The mismatch between 2023 sandbox designs and what agents can do now

Traditional application code ships with a fixed instruction set, audited before it ever touches a runtime. AI agents break that model. They write new code from plain-language prompts, run it immediately, and do so on inputs that may be partly or fully under an attacker's control. Cursor alone produces close to a billion lines of accepted code every day, and 83% of companies now say they plan to run AI agents in production. Code with no fixed shape, running at that scale, is why sandbox security for agents has stopped being a research curiosity and become an operational emergency.

Three structural gaps separate this problem from anything conventional sandboxing was built to solve, and the industry has been slow to admit it. First, the code an agent produces gets treated as trusted the moment the model outputs it, even though the prompt and the context feeding that model may already be compromised. Second, agents decide at runtime which APIs to call and how much compute to spend, decisions a static security policy written months earlier has no way to predict. Third, agents increasingly carry memory across sessions, so a manipulation planted today appears in behavior weeks later, once nobody is looking, because that stored memory sits there and gets acted on without fresh scrutiny.

Model capability on cybersecurity tasks has moved fast enough to make last year's assumptions look almost quaint. Frontier models scored below 10% on apprentice-level cybersecurity benchmarks in late 2023 and early 2024. By 2025, that number sat around 50%, and the first expert-level task got completed sometime that year. A sandbox designed around what a model could do in 2023 is now being asked to hold against what a model can do in 2026, and anyone who thinks those are close fights hasn't looked at the curve.

Security teams have noticed, too. Heading into 2026, 48% of cybersecurity professionals name agentic AI as the top attack vector they're worried about, ahead of deepfakes, ransomware, and supply chain compromise. The people whose job is ranking threats have put agents ahead of every attack category that dominated headlines for the past decade. That should tell you something.

Prompt injection sits at the center of nearly every major AI vulnerability list, and the indirect kind, instructions smuggled in through content the agent retrieves rather than typed by a user, has become the harder problem to defend against. Google researchers tracking the open web reported a 32% jump in malicious prompt injection payloads embedded in ordinary web content between November 2025 and February 2026, sitting in pages that agents are already crawling as part of their normal job. It's already out there, not a lab result. It's already out there.

Real-world cases show how plain the delivery mechanism can be. A Google Docs file triggered an AI IDE agent, through a Google Docs MCP server, to fetch and run a malicious payload: a Python script that harvested secrets with zero user interaction. Separately, comments left in a code repository were enough to push AI coding assistants with shell access into running recursive file deletion commands. Neither case needed a sophisticated exploit chain. Both needed only an agent that trusted its inputs by default, which is most of them.

Two CVEs made the pattern official. CVE-2025-53773 confirmed hidden prompt injection buried in pull request descriptions as an active exploitation path. CVE-2025-58372, affecting Roo Code, chained prompt injection into a workspace file write and from there into arbitrary code execution, with a CNA-assigned CVSS of 8.1 (third-party aggregators list it at 9.8 critical, and NVD's own assessment was still pending as of this writing).

Sandbox escape has its own paper trail, and it keeps growing. CVE-2024-21626 was a file descriptor leak in runc: a leaked fd let container processes walk host filesystem paths through their own working directory, even though the mount namespace itself was never breached. The escape happened one level below where anyone was watching. Additional runc CVEs surfaced in 2025, exploiting mount race conditions that let a process inside a container write to protected paths on the host.

Then came DuneSlide. Cato Networks disclosed CVE-2026-50548 and CVE-2026-50549, both scored 9.8, affecting Cursor's sandbox. Prompt-injected commands manipulated working-directory and symlink-validation logic to overwrite the sandbox helper itself, the exact component meant to keep the sandbox intact. Cursor first rejected the reports as out of scope, then reopened the case and shipped a fix in version 3.0, with CVE numbers assigned in June 2026. Microsoft disclosed its own CVEs showing how prompt injection in Semantic Kernel achieved host-level remote code execution. And CVE-2025-59528, in Flowise, turned unsafe config handling into JavaScript injection across an estimated 12,000 to 15,000 exposed instances.

The industry framework that names what can go wrong when agents execute code

None of this had a shared vocabulary until recently. On December 9, 2025, the OWASP GenAI Security Project published the OWASP Top 10 for Agentic Applications, released under a Creative Commons Attribution-ShareAlike 4.0 license and reviewed by more than 100 security researchers and practitioners before publication. It's the first industry-standard framework built specifically for autonomous agents, systems that don't just generate text but call APIs, run code, move files, and make decisions with limited human oversight.

The framework lists ten risk categories, numbered ASI01 through ASI10. ASI01 covers goal hijacking through prompt injection and indirect manipulation, the entry point behind most documented sandbox escapes to date. ASI02 covers tool misuse through unsafe delegation and parameter injection. ASI03 addresses identity and privilege abuse across multi-agent delegation chains. ASI04 covers runtime supply chain risk introduced by dynamic tool and plugin composition. ASI05, unexpected remote code execution from sandboxing failures, sits closest to the subject at hand: agent-generated or externally influenced code running on hosts, containers, or runtimes in ways nobody intended, whether that means escalation, persistence, a full sandbox escape, or remote compromise. The examples OWASP gives read like a checklist of what's already happened: shell commands embedded in a prompt and executed as code, generated code that deletes or overwrites data in an environment with no safety margin, unvalidated scripts that run automatically during normal operation.

The rest of the categories round out the picture. ASI06 covers memory and context poisoning in persistent or shared knowledge stores. ASI07 addresses insecure communication between agents. ASI08 covers cascading failures, one compromised agent's blast radius spreading into others. ASI09 names human-agent trust exploitation and decision-fatigue attacks. ASI10 covers rogue agent misalignment. ASI05 anchors the sandbox conversation, but the framework's real value is in showing that sandbox design can't be solved apart from the rest of the stack. Privilege abuse, supply chain exposure, and blast radius all shape what a sandbox actually has to contain.

Why no single isolation boundary is enough, and how the isolation spectrum works

Isolation runs on a spectrum, and where a workload sits on it should follow the threat model, not habit, and not whatever the team already happens to have running. Most teams get this backwards: they pick the isolation layer they're used to and hope it's enough, instead of starting from what the agent is allowed to touch and working outward.

Standard containers, the Docker and OCI world most engineering teams already know, use Linux namespaces and cgroups to separate processes while every one of them still shares the same host kernel. gVisor's own documentation names the risk directly: a standard container workload is "only one system call away from host compromise." Cgroups limit and account for resource use, but they were never built as a security boundary. They stop one tenant from starving another of processing power or memory. They do nothing to stop an escape. CVE-2024-21626 and the follow-on runc CVEs in 2025 never touched a container's network rules or filesystem permissions, they broke the runtime itself. Hardened profiles (seccomp, AppArmor, SELinux, dropped capabilities, a read-only root filesystem, no-new-privileges) shrink the attack surface meaningfully, and in some configurations, SELinux enforcing mode among them, they can block exploitation. That protection isn't universal across setups, though, and no team should treat it as guaranteed. Standard containers make sense for development environments. For production agent execution running untrusted, model-generated code, they fall short, and their roughly 500ms startup time and density advantage don't buy back the risk they carry.

gVisor takes a different approach: it reimplements Linux syscalls inside a user-space application kernel called the Sentry, written in Go. Instead of letting hundreds of syscalls reach the host kernel directly, gVisor intercepts them and passes through only a minimal, vetted subset. Escaping gVisor means finding a bug in the Sentry's reimplementation and a separate bug in the host, which raises the bar well above what standard containers offer. The cost is visible in startup time, roughly 100 milliseconds, and in overhead on I/O-heavy workloads, plus compatibility friction for build tools that depend on syscall behavior gVisor doesn't replicate exactly. GPU workloads hit a hard wall: gVisor's interception point sits in a place that blocks direct PCIe passthrough, ruling it out for most ML-heavy agent tasks. V8, the JavaScript engine underlying isolate-based sandboxes, carries a substantial bug history, which argues for treating isolate-based approaches as one layer among several rather than a full answer on their own.

MicroVMs go further still, and this is where production agent workloads belong, full stop. Firecracker and Kata Containers run a genuinely separate kernel per workload, hardware-level isolation rather than process-level, so an attacker has to break both the guest kernel and the hypervisor to reach the host. Firecracker boots in well under 200 milliseconds, adds less than 5 MiB of overhead per VM, and scales to around 150 VMs on a single host. Because it uses real hardware virtualization, Firecracker can support GPU workloads in ways that gVisor structurally cannot offer. Kata Containers takes a slightly different route: it orchestrates Firecracker, Cloud Hypervisor, or QEMU to run a full VM behind a standard container API, so a Kubernetes cluster sees an ordinary container while that VM handles the actual execution, booting in around 200 milliseconds. AWS AgentCore builds on this idea directly: every session gets its own dedicated Firecracker microVM, providing strong per-session isolation. For multi-tenant AI agent execution handling code nobody vetted in advance, microVMs offer the strongest isolation available without moving to specialized hardware. Anything less is a bet that the model won't do the one thing it was built to do: write code nobody reviewed first.

The other four layers that isolation alone cannot replace: network, filesystem, resources, and runtime monitoring

Isolation answers one question: can the code escape the box? It says nothing about what the code does while it's still inside the box, legitimately, with permission, following the rules exactly as written. The other four layers exist to close that gap, and the sheer breadth of the OWASP framework, ten categories, not one, is itself evidence that a single perimeter was never going to be enough.

Start with network policy. Even a correctly isolated microVM can dial out to an external server and hand over whatever data it can read, or pick up fresh instructions from an attacker mid-execution. Isolation stops the code from touching the host. It does nothing to stop the code from talking to the internet. The fix is a default-deny egress policy: no outbound connection unless it's explicitly allowlisted, with tunnels or authenticated proxies set up for the handful of legitimate destinations, a production database, say, that genuinely need reaching. The Postmark MCP incident shows what happens without that control in place. A rogue MCP server impersonating Postmark quietly injected a BCC field into outgoing email tool calls, exfiltrating every email sent through it, without ever touching a filesystem or a kernel. Network controls must be configured on their own terms because isolation technology alone does not secure them, no matter which isolation technology sits underneath them.

Filesystem policy works the same way. The DuneSlide CVEs in Cursor didn't need to break out of the sandbox. They exploited working-directory and symlink-validation logic from inside the sandbox's own execution context, then used that access to overwrite the sandbox helper itself. A default-deny filesystem policy, paired with a read-only root, limits what an agent can touch even when it's operating exactly where it's supposed to be. OpenAI's Codex CLI shows the same class of problem from another angle: when the .codex directory doesn't exist yet, the default state for a fresh install, the tool's handling of that missing directory became the source of its own documented vulnerability. Isolation didn't fail in either case. It was never the layer meant to catch it.

Resource controls matter for a simpler reason. An agent that spins up unbounded processes, grabs unlimited memory, or forks without limit can degrade or take down a shared host without ever touching another tenant's data. That's a denial-of-service risk, not a confidentiality breach, but at scale, with agents running thousands of concurrent sessions, this kind of failure takes down an entire platform rather than one workload.

Runtime monitoring catches what the first three miss by design: behavior that's technically allowed but obviously wrong. A container operating inside its network allowlist, its filesystem restrictions, and its resource limits can still do something no policy anticipated, because policies get written in advance and agents, by definition, make decisions no static policy can fully predict. Watching for that gap, instead of assuming the other three layers already closed it, is what turns four separate controls into something that actually resembles defense in depth.