Sandboxing Untrusted Code Execution in Agent Pipelines

Sandboxing untrusted code execution in agent pipelines requires more than choosing a strong isolation engine. Agents turn untrusted inputs into executable instructions at runtime, so production defenses must combine threat-matched isolation with resource limits, network controls, and deterministic privilege scoping. Security depends on both what code can do inside a sandbox and what the surrounding system trusts outside it.

Why the security controls built for static application code cannot contain AI-generated code

Traditional application security assumes that the instruction set is fixed and can be audited before the application is deployed. Agents break that assumption at the point of execution. They write new code from prompts, documents, and API responses whose contents may be untrusted. Yet the execution environment can give that code the same authority as application code that has been reviewed. An audit of the application therefore cannot fully describe the instructions it will eventually run.

Standard containers do not resolve this mismatch. Linux namespaces and cgroups separate processes and resources, but containers share the host kernel, leaving kernel vulnerabilities and misconfiguration as potential escape paths. MCP adds another interface without adding isolation. A local stdio MCP server is a host-spawned subprocess that inherits the host’s working directory, file permissions, and environment secrets. The MCP specification, revised 2026-07-28, states that “MCP itself cannot enforce these security principles at the protocol level” and that tools “represent arbitrary code execution and must be treated with appropriate caution.”

What the recent CVE record shows about the actual blast radius

The 2025–2026 vulnerability record spans developer interfaces and execution infrastructure. CVE-2025-58372 in Roo Code linked prompt injection to workspace file writes and arbitrary code execution, with CVSS 9.8. CVE-2025-59528 in Flowise exposed thousands of instances to remote code execution through JavaScript injection, with CVSS 10.0.

OX Security’s April 2026 disclosure identified a systemic host-execution route in Anthropic’s MCP SDK across Python, TypeScript, Java, and Rust. Any process command passed to its STDIO interface executed on the host regardless of whether it initialized a valid MCP server. Cursor IDE’s CVE-2025-54136, known as MCPoison, exposed a different trust failure. Approval was tied to a server name, so a malicious configuration could replace the approved contents without re-approval. Patched vulnerabilities in MCP Inspector, LiteLLM, and Windsurf further broadened the protocol-interface record.

OpenAI stated that it “now requires stronger isolation ('sandboxes') for workloads that execute model-generated or otherwise untrusted code” and introduced more controls separating higher-risk workloads from the internet. That response addresses a present execution risk. However, frontier model capability on security tasks is rising, so designs calibrated to earlier capabilities may not provide an adequate boundary going forward.

How the four main isolation primitives actually work and what each one can and cannot contain

Standard Docker containers, gVisor, Firecracker microVMs, and Kata Containers provide distinct forms of separation. They are not interchangeable security guarantees. Containers use Linux namespaces and cgroups for process-level isolation, delivering millisecond startup, minimal overhead, and high density while retaining a shared kernel. gVisor intercepts system calls through its user-space Sentry process, substantially reducing the host-kernel attack surface. Its syscall-level boundary is stronger than ordinary containers but weaker than hardware-enforced VMs, with startup from milliseconds to approximately 100ms.

Firecracker runs a separate Linux kernel inside KVM with minimal device emulation. An attacker must break out of both the guest kernel and the hypervisor. Its approximately 125ms startup and approximately 5MB memory overhead make that hardware boundary available without a conventional VM’s larger footprint. Kata exposes VM isolation through standard container APIs and orchestrates VMMs including Firecracker, Cloud Hypervisor, and QEMU. Kubernetes sees a container, while the workload runs inside a full VM, with approximately 200ms startup.

WebAssembly with WASI is an emerging option beyond those four. Per-call Wasm sandboxes offer a fresh execution surface with sub-millisecond startup, but only for compatible language runtimes that compile to Wasm. They are not a general-purpose replacement for VM isolation. Andronchik & Lokhmakov’s 2026 study also distinguishes engine architecture from product implementation. Products in the same engine class have different patch policies, so the architecture’s name alone cannot show how secure a product is in use.

Matching isolation mechanisms to threat models rather than defaulting to the strongest option

Use containers when the code is trusted, fully audited, and single-tenant. For multi-tenant SaaS or CI/CD workloads whose code is not adversarially crafted, user-space syscall interception reduces kernel exposure without requiring a full VM. For production execution of AI-generated code from untrusted inputs, use hardware-enforced VM isolation as the baseline because its behavior cannot be predicted or audited before execution. These are different requirements.

Operational constraints then narrow the choice within that baseline. Regulated and zero-trust deployments may need VM isolation through Kubernetes-native container workflows. Per-invocation tools may instead fit Wasm when startup latency is the binding constraint and their runtime is compatible. Check how updates are handled when making either choice. The same study finds that product pin policy matters most to operators, with downstream patch lag that ranges from zero days to 471+ days, opaque policies, or infinity. Even a well-matched engine remains insufficient when execution crosses a trust boundary above it, as CBSE and MCP incidents demonstrate.

Why isolation alone fails and where the real gap sits — the trust boundary above the sandbox

The CBSE vulnerability class bypasses hardware isolation without attacking the operating system or container runtime. An attacker changes trusted files or execution paths inside a sandbox that are later processed outside it. On the next startup, the attacker’s code runs on the host with the user’s privileges. The runtime boundary may have worked exactly as designed.

MCPoison exposes the same broader problem through name-based approval that persists when the approved contents change. The STDIO disclosure exposes an earlier boundary failure, with host commands executing before any sandbox is invoked. Neither route requires breaking a hypervisor. Isolation cannot itself validate the provenance or integrity of configuration, startup artifacts, and protocol inputs accepted as trusted. Those decisions belong to the system surrounding the execution perimeter.

An agent’s task intent narrows and evolves, but its capabilities may remain fixed from session start. A mid-session prompt injection can then act with the full session-level grant. That authority stays the same even with stronger runtime separation. Defense-in-depth therefore requires an explicit account of what crosses the sandbox boundary and under what trust conditions.

How privilege scoping above the isolation layer addresses what the sandbox perimeter cannot

Progent, research from UC Berkeley and UC Santa Barbara updated in May 2026, addresses this gap with symbolic policies over tool names and arguments. An SMT solver checks its “monotonic confinement” property. What the agent is allowed to do can narrow as a task proceeds, but it can widen only with explicit approval. This prevents policy-layer privilege escalation even when adversarial inputs manipulate the LLM. The check does not depend on the model refusing an instruction.

The architectural separation is the important result here. No individual prompt, tool description, or MCP annotation can unilaterally define a complete capability, because the policy layer is separate from the LLM. The specification supports this distinction by treating tool annotations as untrusted unless obtained from a trusted server. A 2026 supply-chain poisoning paper documents attacks on coding-agent skill ecosystems, extending the concern to skill and tool registration before execution. The practical implication is to make grants task-scoped, revocable, and subject to deterministic enforcement, while treating Progent as research establishing a direction.

Assembling a coherent defense-in-depth stack for production agent pipelines

The production design should compose five interlocking layers, beginning with a threat-matched isolation boundary. Resource limits must cap CPU, memory, and execution time so that unpredictable workloads cannot exhaust them. Network controls must restrict outbound traffic to declared endpoints because an agent can exfiltrate data without escaping its VM. Permission scoping must govern tool calls and arguments above the runtime boundary. Monitoring must keep an audit trail for each sandbox’s tool calls, filesystem writes, and network attempts.

The earlier failures show where these layers must connect. CBSE makes the handling of sandbox-modified artifacts part of boundary design. With MCP STDIO, the permission review must cover commands that run on the host before isolation begins. MCPoison makes approval of configuration contents distinct from recognition of a server name. Observability must cover those transitions as well as what happens while code is contained.

Modal provides automatic CPU and memory bursting above a requested baseline, with per-second billing on the greater of requested and actual usage, addressing the idle capacity and burst failures associated with fixed reservations. Northflank provides managed sandbox infrastructure that removes the need to operate microVMs directly. Neither operational convenience substitutes for the remaining controls. Patch cadence cuts across the entire stack, since delayed or opaque updates can undermine the chosen engine’s protection.

What the available sandbox platforms actually provide across these layers, and where each fits

Modal provides VM sandboxes and gVisor, with full Docker functionality in its VM sandboxes. It supports sub-second starts at high concurrency, including large custom images, while Memory Snapshots, currently alpha, can reduce initialization-heavy startup time. Its bursting and billing model lets teams size for what they usually use while supporting the most they might need. The SDK supports dynamic environment definitions at runtime for task-specific environments. GPU access includes more than ten types, including T4, L4, A10, L40S, A100 variants, H100, H200, B200, and B300, without quotas or reservations.

Modal also provides SOC 2 Type II compliance, region-pinning, and HIPAA-compliant workloads on Enterprise plans through a BAA. Its production users illustrate the breadth of execution workloads. Quora runs millions of untrusted code snippets daily, while Imbue runs hundreds of isolated coding agents. Other users include Ramp, Cognition, and Suno.

E2B uses Firecracker microVMs and is purpose-built for agent workflows, with approximately 150ms cold starts. Its lifecycle has explicit session limits. Hobby sessions last at most one hour, while Pro sessions last at most 24 hours, so longer tasks require pause/resume or checkpointing. E2B has no GPU support and defaults to its managed cloud, with enterprise BYOC on AWS and GCP and self-hosted options available. Hobby comes with a one-time credit, while Pro costs $150/month. Perplexity shipped advanced data analysis in one week using its sandboxes.

Deno Sandbox was announced in beta on February 3, 2026 as a managed cloud service for untrusted or AI-generated code. The supplied details do not specify its isolation primitive, resource model, or session lifecycle. Northflank offers Kata Containers and gVisor for isolated workloads at production scale, providing a managed operational layer around those engines. Vercel Sandbox is generally available and uses Firecracker microVMs. Its Hobby plan comes with a free monthly allotment, while Pro and Enterprise charge based on usage, with Pro usage drawing on the plan’s monthly credit first. The available descriptions do not establish comparable lifecycle limits or complete permission and monitoring coverage for these services.

Where the defense stack is still dangerously under-specified and what to watch

The study found that the “strongest combination — microVM × continuous public fuzzer — is unoccupied” in its study set. That leaves residual risk structurally unmeasured. Product update discipline adds uncertainty when downstream patch schedules are delayed or opaque. Practitioner evaluation therefore needs both architectural evidence and a clear account of how that architecture is maintained.

Poisoned skills and tool registrations can cross a trust boundary before code runs, while deterministic task-level enforcement is still not standard practice in production. As models become more capable, sandbox designs must be checked again because they cannot guarantee safety forever. As isolation primitives commoditize, the meaningful security work shifts toward per-task audit trails, egress controls, credential injection proxies, and independently enforced least privilege.