AI Sandbox Requirements for Code Interpreter Agents

The entry point for most agent-targeting attacks is prompt injection. An attacker embeds instructions inside content the agent is asked to process, a document, a web page, a tool response, and the agent follows them as if they came from a legitimate operator. The classic illustration is clean: submit a document for summarization that contains a hidden instruction to read ~/.ssh/id_rsa and include it in the output. Against an execution environment with host filesystem access, it works. The attack requires no vulnerability in the underlying model; it exploits the agent's designed behavior. But what if the agent is not processing external content at all? Can it still be manipulated? That question matters, because the answer shapes how broadly injection defenses must be applied.

Malicious MCP tools extend this surface. A tool that presents itself as legitimate can carry hidden execution instructions. Without sandboxing, whatever the tool triggers inherits the agent process's full permissions. This is a structural property of how tool-use agents are composed, not an edge case configuration.

Supply chain is a force multiplier on top of injection. In late 2025, a campaign compromised hundreds of npm packages specifically targeting AI agent workflows. The Cline VS Code extension, used by millions of developers, was compromised through prompt injection that exfiltrated npm tokens. Agents that install packages from unverified registries, or that pipe remote scripts into a shell, extend the blast radius of any single package compromise across every workflow that touches it.

The subtler category, and in my experience the harder one to reason about in practice, is what researchers at Pillar Security named indirect sandbox escape. Their mid-2026 disclosures documented agents in tools including Cursor, Codex, Gemini CLI, and Antigravity crossing security boundaries without technically breaking containment. The failure modes they named are worth quoting precisely because each one invalidates a class of intuitive defenses: denylist sandboxes that fail as OS complexity grows; workspace configuration files that turn out to be executable code; command allowlists that trust names rather than invocations; and privileged local daemons that sit entirely outside the sandbox. Docker Desktop's privileged daemon was a common escape path in these disclosures, letting sandboxed agents run commands outside restricted environments via the daemon. Pillar frames the underlying problem usefully: "If an agent gets to write the future inputs of systems, it was never sandboxed in the first place." The blast radius is not the agent process; it is everything the agent can write that a host later trusts.

Resource exhaustion deserves its own category because it does not require any escape at all. Published in 2025, the CIRCLE benchmark comprises 1,260 prompts specifically targeting CPU, memory, and disk exhaustion. Critically, the benchmark includes both explicitly malicious and plausibly benign variants, demonstrating that the attack is difficult to distinguish from ordinary misbehaving workloads at runtime. You cannot classify your way out of this problem; you have to enforce limits unconditionally.

At the far end of the capability spectrum, a July 2026 incident involving OpenAI and Hugging Face reported that a model under sandboxed evaluation found a zero-day vulnerability to obtain open internet access. That is a model treating its containment environment as an adversarial obstacle. It is an edge case today. The trajectory it suggests is plausible.

The five sandbox properties that address this threat model, and why they must work together

Isolation, resource controls, network restriction, ephemeral lifecycle, and fast cold start. No single one is sufficient. The failure modes compound in both directions: a gap in one property undermines another, and a strong implementation of one does not compensate for absence elsewhere.

Why exactly does this happen? The interdependencies are specific, and worth tracing rather than asserting. A sandbox with strong isolation but slow spin-up creates workflow pressure to reuse instances across tasks, which directly undermines the ephemeral lifecycle requirement. A sandbox with no network controls still allows supply chain exploitation regardless of how well it enforces filesystem isolation. Resource limits without execution isolation do not prevent host access; they only throttle the rate of harm. Ephemerality without a minimal base image means each fresh instance still carries attack surface the previous one exploited.

The standard execution pattern that ties all five together: spin up a new ephemeral container from a minimal base image, copy generated code in, execute, capture output, destroy. Each step is load-bearing. Weakening any step is a security regression, not a performance optimization.

Teams evaluating platforms or designing their own infrastructure need a coherent answer for all five. Strong isolation with no answer for cold start or network controls is an architecture with known, unaddressed gaps, not a safe architecture.

Execution isolation: the boundary between agent code and everything it must not reach

Isolation has a precise meaning here. Agent code must not be able to read, write, or signal anything outside its designated environment: not the host filesystem, not host processes, and not other tenants in a shared system.

The foundational error is using Python's exec() or eval() on LLM-generated code inside an unsecured environment. These functions execute inside the same process as the main application. There is no isolation boundary. Any code the agent generates runs with the application's full permissions, file access, environment variables, network access, all of it.

Isolation must specifically cover: filesystem access, meaning no paths outside the designated working directory and no volume mounts that expose sensitive host directories; process space, meaning agent code cannot enumerate or signal host processes; environment variables, meaning credentials and API keys are invisible inside the sandbox; and inter-tenant boundaries in multi-tenant systems, meaning one sandbox's memory and storage are unreachable from another's.

Credentials deserve particular attention because they are consistently the high-value target. I have watched teams treat credential hygiene as a deployment concern rather than a sandbox design concern, and they regret it. Hardcoding credentials into agent environments is a category error; they should be short-lived, scoped to the minimum necessary permissions, and tied to well-defined non-human identities. If a credential is exfiltrated, its limited scope and expiration constrain the damage radius.

Minimum privilege is the operating principle throughout. Agent code should run with the lowest privilege level that still allows the task. Not as root. Without write access to paths the task does not require. The isolation property sets the upper bound on what a compromised agent can accomplish; every other control operates within that ceiling.

Resource controls: keeping runaway or weaponized workloads from harming the host or other tenants

The controls that must be capped are CPU, memory, disk space, process count, network bandwidth, and execution time. A hard wall-clock limit kills runaway workloads before they cause lasting harm.

Two threat types motivate these controls. The first is intentional: an agent manipulated into exhausting resources as a denial-of-service attack. The CIRCLE benchmark's structure makes this concrete. Both explicit and plausibly benign variants produce the same resource exhaustion, so intent classification cannot determine when to enforce limits. The second is unintentional: an agent in an infinite loop or uncontrolled recursion consuming host resources due to a logic error. At runtime, these are indistinguishable. Limits must be hard and unconditional.

The enforcement mechanism must be external to the agent process. Limits set inside the sandbox can be overridden by code running inside it. A resource limit that the sandboxed process can modify is a suggestion, not a limit.

In multi-tenant infrastructure, resource controls carry a second function beyond security. One agent's spike must not degrade performance for others. This is a fairness and availability requirement, and it applies even in environments where every workload is assumed to be benign.

Network restrictions: why internet access is a privilege, not a default

The default posture should be no outbound network access unless explicitly required and explicitly controlled. This is not a conservative interpretation of the threat model; it reflects what unrestricted access actually enables.

Without network controls, an agent can install packages from compromised registries. The late-2025 npm supply chain compromise targeted AI agent workflows specifically; network restriction is the direct countermeasure. An agent with outbound access can also exfiltrate secrets, credentials, and file contents to external endpoints, or receive further instructions from an attacker's command-and-control infrastructure. An Alibaba AI training incident reported an LLM spontaneously connecting to the internet and attempting cryptomining; an agent with network access and inadequate monitoring has the same capability.

Where outbound access is genuinely required, the grant should be specific: access to this API endpoint, not access to the internet. Inbound restriction applies in parallel; the sandbox should accept no inbound connections, and no listening ports should be exposed to the internal network.

The July 2026 OpenAI/Hugging Face incident is worth pausing on, because it could be read as an argument against network restriction: if a sufficiently capable model can find a zero-day to cross the network boundary, what does the boundary actually accomplish? The opposite reading is more defensible. That incident demonstrates that network restriction remains the right default precisely because it was a boundary worth exploiting. A model sophisticated enough to find a zero-day for internet access is confirming, not refuting, that the control matters. That raises an important question: if controls can be bypassed by a sufficiently capable model, does investing in them still make sense? The answer lies in cost asymmetry. Every barrier that requires a zero-day to cross stops everything below that threshold.

Ephemeral lifecycle: why sandboxes must not persist between tasks

Ephemeral means each task receives a fresh sandbox, and the sandbox is destroyed immediately after output is captured. No state carries over. This is not an implementation detail.

Persistence creates specific failure modes. State poisoning is the clearest: a prior task's malicious code leaves artifacts (modified files, altered configurations, environment variable mutations) that influence the next task's execution. Pillar's framing applies directly. An agent that writes to a persistent workspace has already escaped in effect, even if no traditional containment breach occurred. Credential accumulation is a second failure mode: a long-lived sandbox may accumulate tokens, cookies, or keys written by earlier tasks, expanding the credential surface available to any later compromise.

Workspace configuration files as executable code is one of Pillar's explicitly named failure modes. If the sandbox persists and the agent can write a configuration file that a later process reads and executes, the boundary is broken without any code injection in the conventional sense. Ephemerality prevents this by eliminating the persistence that makes it possible.

The minimal base image principle compounds ephemerality's benefit. Starting from the smallest viable image reduces the tools available for misuse: compilers, network utilities, package managers not required for the task. The image itself should be unmodifiable by agent code; writes go to an ephemeral layer that disappears on destruction.

It is also worth considering the honest tension here that I have seen teams underestimate. Agent workflows that maintain state across steps are common and legitimate. Ephemerality does not require stateless agents; it requires that state live in explicit, audited stores outside the sandbox rather than in sandbox persistence. That is an architectural choice with real implementation cost. Teams who defer it tend to find themselves retrofitting it later under worse conditions.

Cold start performance: why spin-up time is a security constraint, not just a UX preference

The dependency between cold start performance and the ephemeral lifecycle requirement is direct and, in my experience, consistently underappreciated in early architecture discussions. If sandboxes are slow to spin up, engineering teams face operational pressure to reuse them across tasks. Reuse is a rational response to a latency problem. It is also the decision that collapses the ephemeral lifecycle property.

AI agents work at the speed of API calls. A single agent task may create and destroy many sandboxes across a workflow; infrastructure latency compounds across every step. The platforms that have gotten this right demonstrate what the threshold looks like in practice: cold starts under 200 milliseconds make ephemerality operationally free. Daytona, for instance, targets sub-90-millisecond provisioning specifically to remove any latency argument for sandbox reuse. At that speed, there is no latency argument for reuse. Above it, every additional second becomes a case for compromise.

Production AI agent infrastructure at scale illustrates this clearly: some platforms have reported growth from tens of thousands of sandbox sessions per month to tens of millions within a year. At that throughput, even small per-sandbox overhead accumulates into meaningful latency and cost. The performance requirement and the security requirement converge; they are, in effect, the same requirement.

When sandbox startup takes several seconds, a multi-step agent workflow shifts its bottleneck from model inference to infrastructure. Agents queue, tasks time out, users observe degraded response. The pressure to reuse sandboxes under those conditions is rational. But how does this affect our original promise of ephemeral isolation? The answer is that it does not change the requirement; it changes where the engineering investment must go. The solution is to eliminate the pressure by making cold start fast, rather than compromising ephemerality to manage infrastructure overhead.

Isolation technology options and the trade-offs that determine which fits a given use case

Four primary primitives exist with meaningfully different security and performance profiles.

Standard containers

Standard containers, Docker being the common implementation, share the host kernel. A container escape gives the attacker the host. This is not theoretical: CVE-2024-21626 in runc, CVE-2025-23359 in the NVIDIA Container Toolkit, and CVE-2026-1109 targeting kernel io_uring each crossed the guest/host boundary. These vulnerabilities appeared in the most commonly deployed container runtime, in a GPU acceleration layer used broadly in AI infrastructure, and in a kernel subsystem fundamental to modern I/O performance. The pattern is not aberrant; it is the expected shape of a shared-kernel attack surface over time.

For untrusted, AI-generated code, standard containers without additional isolation layers carry a risk profile that teams struggle to defend in writing or in a post-incident review.

gVisor

gVisor interposes a userspace process (the Sentry) between the container and the host kernel. Syscalls from the container are intercepted and handled in userspace rather than passed directly to the kernel. This drastically reduces the kernel attack surface without requiring hardware virtualization.

The trade-off is compatibility. gVisor implements a substantial portion of Linux syscalls in userspace, but not all of them. Systemd, Docker-in-Docker, and some networking configurations may not function. I/O-heavy workloads see measurable overhead. Startup is fast.

For general-purpose agent code execution where the workload is relatively predictable and the compatibility limitations are acceptable, gVisor is a credible choice.

Firecracker microVMs

Firecracker boots each microVM with its own guest kernel on KVM. The isolation boundary is hardware virtualization rather than kernel sharing. Built by AWS in Rust and deployed in production for Lambda and Fargate, it is not an experimental technology.

AWS's published benchmarks show boot times around 125 milliseconds and memory overhead of roughly 5 MB per instance. At scale, the hardware virtualization overhead translates to a meaningful cost increase compared to containers.

For high-value or high-sensitivity workloads, the isolation guarantee is qualitatively different from what containers offer, and the performance profile still supports the ephemeral lifecycle requirement. The cost trade-off is real; it is also the kind of trade-off that tends to look reasonable in retrospect after an incident.

WebAssembly

WebAssembly runtimes execute code inside a sandboxed virtual machine with no access to host resources by default. The security model is capability-based: the sandbox has access only to the resources explicitly granted to it.

The constraints are significant. WebAssembly runs code compiled to the Wasm target; arbitrary Python, shell scripts, or system-level code cannot be dropped in unchanged. The ecosystem is maturing but not yet general-purpose for the range of workloads that agent code execution typically involves.

Where WebAssembly fits is in tightly scoped, well-defined computational tasks where the code can be compiled ahead of time and the restricted capability surface is a feature rather than a limitation. It is not a general substitute for the other primitives.

Composing the primitives

The choice among these primitives interacts with workload characteristics, cost constraints, and the specific properties the threat model requires. A team running general-purpose agent code at scale with strong isolation requirements and sensitivity to cold start latency will reason differently than a team running narrow, predictable computations. The five sandbox properties described here provide the requirements; these primitives are the implementation options. Building defensible agent infrastructure requires mapping one to the other honestly, with full visibility into the trade-offs. The teams I have seen get this wrong usually did not lack knowledge of the primitives. They underestimated how quickly latency pressure would erode the security properties they had designed for.