When AI Agents Require Sandbox Isolation
The numbers are already large enough to be uncomfortable. Industry surveys put the share of companies planning to deploy AI agents at 83%. Roughly half of Fortune 500 companies are running agent workloads today. Gartner, cited in EY's 2025 enterprise AI risk report, projects that 33% of enterprise software will feature agentic AI by 2028, and that 25% of enterprise cybersecurity incidents will be attributable to AI agent misuse by that year.
Published session volume data illustrates the velocity more concretely than any projection. Approximately 40,000 sandbox sessions ran per month in March 2024. By March 2025, that figure had reached roughly 15 million. Twelve months, three orders of magnitude.
The scale itself is not what troubles me. What troubles me is who is making the architectural decisions inside it, and under what conditions. Isolation choices are being made by default, under delivery pressure, by teams whose primary mandate is shipping features. Defaults calcify, not because anyone chose poorly, but because nobody stops to ask whether the default was designed for the workload it is now carrying. I have watched this pattern repeat across every infrastructure transition I have lived through: the teams reasoning carefully about the right constraints during the growth phase end up with materially better posture than those who adopted blanket policies in either direction. That window is narrowing, and the closing is not theoretical.
What standard containers actually protect against, and where their boundary ends
Containers were designed for process isolation and reproducible deployments. That is a meaningful guarantee in a specific context: trusted code, written and reviewed before deployment, running in a stable environment. The guarantee frays considerably when the code being executed was generated at runtime by a model responding to user input.
The architectural constraint is precise. All containers on a host share the same Linux kernel. A kernel vulnerability is a direct path to the host. In November 2025, three simultaneous runc vulnerabilities, CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881, each affected Docker, Kubernetes, containerd, and CRI-O. Any of the three could have been reached from within a container running agent-generated code. Whether this class of vulnerability recurs is not the interesting question; the interesting question is whether your architecture has assumed it won't.
Oxford and the UK AI Security Institute's SandboxEscapeBench research, presented as an oral at ICML 2026, tested frontier LLM agents against 18 real-world vulnerability scenarios across Docker and Kubernetes environments. Successful escapes cost roughly one dollar each. More instructive than the escape rate was the method: models did not only exploit the planted vulnerabilities. They discovered unintended paths, opportunistically searching for any route to goal completion when the obvious ones were unavailable. A known-patched environment is not, on that evidence, a secured one.
Containers are the right tool for what they were built to handle. The problem is treating them as a default for workloads they were never designed to contain.
Runtime code execution as the clearest trigger for sandbox isolation
The condition is precise: an agent receives a user request, generates code in response, and executes that code within the same session. The code did not exist before deployment. No engineer reviewed it. This is categorically different from calling a pre-written function, and that distinction matters more than most deployment checklists acknowledge.
OWASP's Agentic AI Top 10, published in December 2025, classifies this as ASI05, Unexpected Code Execution, and states without qualification: "Never execute agent-generated code without strict sandboxing, input validation, and allowlisting." The framework specifies isolated containers with no network access and minimal system privileges, and notes directly that Docker alone does not satisfy this requirement.
The production record reinforces the framework. At least eight critical remote code execution CVEs published against LangFlow, LangChain, and n8n between 2024 and early 2026 share the same root cause: agent-generated or agent-influenced code executing outside a proper isolation boundary. CVE-2025-3455 against n8n, carrying a CVSS score of 9.8, enabled unauthenticated host-level code execution on Docker-only deployments. The same exploit against microVM isolation becomes a contained incident.
A 2025 Veracode report found that 45% of AI-generated code fails security tests. For agents executing that code at runtime, the implication is structural. The threat surface is definitional to the architecture, present by design rather than by accident, which is why providers like Daytona build sandboxes specifically for AI-generated code rather than repurposing generic containers.
Prompt injection and indirect injection as a trigger that scales beyond obvious attack surfaces
OWASP's 2025 Top 10 for LLM Applications ranks prompt injection as the number one critical vulnerability, and acknowledges explicitly that it cannot be fully eliminated. That acknowledgment is what makes the defensive posture interesting. If you cannot prevent injection, you design to contain it. The question shifts from "how do we keep this out?" to "what happens when it gets in?"
Indirect injection is the form that scales most aggressively in enterprise environments. The payload doesn't arrive in a user-crafted prompt; it arrives inside content the agent was explicitly asked to read. Documents, emails, support tickets, search results, any source the agent treats as implicitly trusted. The Alan Turing Institute's CETaS research, published in November 2024, notes that documents allow a broad range of injection attacks precisely because they contain far more data than typical prompts and carry that implicit trust. Research on RAG pipelines found that five carefully crafted poisoned documents among millions of legitimate ones achieved a 90% attack success rate.
Five documents, among millions. The attack requires no access to the model, no access to the underlying infrastructure. It requires only that the agent read something the attacker could touch. The friction is nearly zero, which means the economics of mounting it are too.
Production incidents make the mechanism concrete. CVE-2025-53773, with a CVSS score of 9.6, demonstrated GitHub Copilot RCE via prompt injection: a payload embedded in source code caused the agent to execute arbitrary terminal commands. CurXecute, tracked as CVE-2025-54135 with a CVSS of 9.8, placed a malicious prompt inside a README file; when a developer opened the project in Cursor IDE, the agent executed arbitrary commands. Three CVEs against Anthropic's official Git MCP server in January 2026 chained path traversal, argument injection, and repository scoping bypass to achieve remote code execution through prompt injection alone.
The trigger condition follows from these cases. Any agent reading content from sources it does not fully control, including user uploads, third-party APIs, web content, and knowledge bases with external contributions, is exposed to indirect injection. An isolation boundary does not prevent the injection. It is the mechanism by which a successful injection remains a contained incident rather than a breach.
MCP and tool-chain integrations as a trigger distinct from prompt injection
The Model Context Protocol became the dominant standard for connecting agents to external tools and data sources, and in doing so created an attack surface with its own distinct threat model. It is worth separating from prompt injection because the structural problem is different. The concern is not what a malicious payload tells the agent to do; it is what authority the protocol itself conveys, and what that authority enables before anyone can intervene.
CVE-2025-49596, with a CVSS score of 9.4, demonstrated that unauthenticated MCP Inspector instances allowed arbitrary command execution. The first confirmed malicious MCP package appeared in September 2025, moving the threat ecosystem past proof-of-concept into active exploitation.
Two attack patterns documented by security researchers clarify the structural issue. AIM Security's documentation of CurXecute showed that prompt injection through any external content, Slack messages, GitHub issues, search results, could instruct Cursor to modify mcp.json, with the malicious configuration executing before the user could reject it. Check Point Research's MCPoison documented a rug pull: an attacker commits a benign MCP configuration, gets it approved, then substitutes a malicious payload. Cursor trusted the approved key name, not the command content. The approval process itself became the attack vector.
MCP connects agents to systems with real authority: file systems, databases, APIs with write access. Tool-chain compromise is lateral movement risk, not data exfiltration in isolation. Agents connecting to external tools via MCP or equivalent protocols, particularly where those tools carry write or execution authority, require network-level isolation between the agent runtime and the broader environment. This is a separate architectural decision from how you handle prompt injection, and conflating the two tends to leave one of them underaddressed.
Multi-agent systems and the blast radius problem that comes with chained delegation
Single-agent threat models do not transfer cleanly to multi-agent architectures. An orchestrator LLM decomposes tasks and dispatches them to specialized sub-agents, each carrying its own tool access and permissions. The blast radius of a compromise is not the individual agent's permissions; it is the union of all permissions held across every agent in the chain.
Most teams aren't making that calculation explicitly. They scope the orchestrator's permissions, audit the orchestrator's inputs, and treat the sub-agents as implementation details. The sub-agents, meanwhile, may hold credentials to entirely different systems.
OWASP LLM06:2025, Excessive Agency, names overly broad permissions and autonomy across multi-agent pipelines as a top-tier risk. The Agentic AI framework classifies Tool Misuse (ASI02), Identity and Privilege Abuse (ASI03), and Rogue Agents (ASI10) as partially mitigated by runtime isolation boundaries, suggesting that isolation is doing meaningful work across multiple distinct failure modes simultaneously, not just one.
A production incident from mid-2025 illustrates the pattern plainly. A Cursor agent with privileged service-role access to Supabase was processing support tickets containing user-supplied SQL instructions. Integration tokens were exfiltrated into a public thread. No single component was exotic; the vulnerability was architectural. Privileged access, untrusted input, and an external output channel in combination were sufficient. The sophistication of the attack was essentially zero.
Sub-agents receiving instructions from an orchestrator that may itself have been compromised represent one exposure. Any agent holding credentials beyond what a single task requires represents another. Pipelines where an intermediate agent's output becomes another agent's executable input represent a third. Isolation per agent, not per pipeline, is what actually limits blast radius; a pipeline-level boundary leaves the interior of the chain unprotected from lateral movement between sub-agents.
How capable frontier models have become at actively probing for escape paths
The SandboxEscapeBench findings carry an implication that gets less attention than the escape rate itself. Frontier models didn't simply respond to presented vulnerabilities; when obvious paths were unavailable, they searched for unintended ones. Opportunistic goal-seeking behavior means the threat surface isn't fixed by the vulnerabilities an operator knows about at deployment time. It expands with the model's capability to find new ones.
METR's 2025 research, cited by the UK AI Security Institute, found that the length of tasks frontier models can complete autonomously has been doubling roughly every seven months. An isolation architecture calibrated to 2025-era capabilities, running on infrastructure that will serve 2027-era models, may simply not hold. This is a different kind of architectural risk than most security teams are accustomed to reasoning about. The threat is improving on a documented schedule, and the infrastructure decisions made now will meet a more capable version of it. Architects who have spent careers designing against fixed adversaries tend to underweight that dynamic, in my experience significantly so.
Production signals reflect the trajectory. Detections of long malicious prompt-injection payloads rose roughly fivefold between March and May 2026. High-risk AI interactions per organization roughly doubled year-over-year. Isolation decisions made against a static threat model degrade as the models improve. The model does not stay at the capability level it had when you made your architectural choices.
The three isolation technologies and which trigger conditions each is designed to address
Three technologies dominate serious isolation deployments in 2026, and they are not interchangeable. Deploying the wrong one for a given workload either leaves meaningful exposure or imposes overhead that erodes adoption. Both failure modes are real, and I have seen teams stumble on each of them.
Firecracker microVMs give each workload a dedicated kernel and network namespace. A guest kernel vulnerability cannot reach the host. This is the strongest isolation available without physical separation; it underpins AWS Lambda. The appropriate use cases are deployments involving regulated data, agents holding significant cross-system privileges, or any scenario where a kernel-level escape would constitute a serious breach.
gVisor intercepts system calls in userspace without provisioning a full virtual machine, producing lower overhead than microVMs at stronger isolation than containers. It suits compute-heavy multi-tenant workloads where full VM overhead is prohibitive but container-level isolation has been assessed as insufficient. It is a genuine middle option, not a compromise dressed up as one.
V8 Isolates operate in JavaScript only, carry very low latency, and are appropriate solely for lightweight, latency-critical tasks where the agent has no system-level access and the code scope is tightly and verifiably bounded. They are not a general-purpose answer.
Research on HTTP-layer sandboxing for browser agents, from ceLLMate testing published in 2025, found accuracy in the mid-90s for policy prediction and blocked all emulated prompt injection attacks evaluated, at a latency overhead of roughly 7 to 15%. Whether that tradeoff is acceptable depends entirely on the workload.
The mapping to trigger conditions follows from the CVE record rather than from theory. Runtime code execution from untrusted input warrants microVM or gVisor; the documented failures on container-only deployments make the case. Indirect injection via documents or external APIs requires network namespace isolation regardless of compute layer. MCP tool-chain integrations with write authority require strict allowlisting plus network isolation. Multi-agent pipelines with broad permissions require per-agent isolation. Containers remain appropriate for trusted, pre-reviewed code running in a stable environment, which is the context they were built for.
The conditions that actually determine whether a given deployment needs sandbox isolation
The more useful question is not "is this an AI agent?" It is "does this deployment include any of the conditions that create the threat surface isolation addresses?"
Five conditions make isolation necessary. First, the agent executes LLM-generated code at runtime: any path where model output becomes executable input. Second, the agent reads content from sources it does not control, including user uploads, third-party feeds, web content, and knowledge bases with external contributions. Third, the agent connects to tools via MCP or equivalent protocols carrying write or execution authority. Fourth, the agent operates within a multi-agent pipeline where it sends or receives instructions from other agents. Fifth, the agent holds credentials or permissions that, if compromised, would affect systems beyond the immediate task scope.
Three conditions suggest lighter controls may be sufficient. The agent reads from and writes to fully controlled, trusted sources only. The code it executes was written and reviewed before deployment. The agent's permissions are scoped to a single system with no lateral movement path.
Most of the agents running in 2028 are being architected now, largely by teams under delivery pressure who are making isolation decisions by intuition or default. The Gartner projection that a quarter of enterprise cybersecurity incidents will be attributable to AI agent misuse by that year is not primarily a prediction about novel attacks. It is a prediction about the cumulative cost of architectural choices made without a clear framework for when isolation is necessary and when it isn't. The trigger conditions above won't prevent every breach. They are, however, the mechanism by which an organization can distinguish a deployment that warrants microVM isolation from one where containers are adequate. That distinction is worth making explicitly, before the architecture hardens and revisiting it becomes expensive.
