Sandboxing and Isolation for Agent Execution Environments
Prompt injection attacks succeed more often against agents than containers can stop them.
E2B's sandbox sessions went from tens of thousands a month in March 2024 to millions a month by March 2025. That's not a growth curve, that's a step change, and it happened because agents stopped being demos and started being infrastructure. Bunnyshell's 2025 guide puts roughly half of Fortune 500 companies as running agent workloads today. The thesis here is simple: sandboxing agent execution used to be a hardening option, something you added if you had time before the sprint ended. It's now foundational infrastructure, and picking the wrong isolation mechanism doesn't cost you a few milliseconds of latency anymore. It costs you an incident report.
What makes agent execution structurally different from running application code
Traditional sandboxing assumes the code came from a developer who wrote it, reviewed it, and probably felt bad about that one hacky function on line 340. Agent execution breaks that assumption at the root. The code an agent runs was generated at inference time from a prompt, and the runtime treats that output as trusted, even when the instructions feeding the model arrived from a source nobody vetted.
Three properties separate this from anything sandboxing was originally built to handle. First, runtime code generation from untrusted inputs: the LLM output is executed with the same trust level as hand-written code, despite having no human in the loop before execution. Second, agents make autonomous decisions about which APIs to call and how much compute to burn, and no static allowlist anticipates that, because the whole point of an agent is that its next move is a function of the last response it got. Third, coding agents carry state across sessions, memory that persists and can be poisoned slowly rather than attacked once.
Prompt injection is the fuse on all three. OWASP ranked it the top risk in its 2025 Top 10 for LLM Applications, and a synthesis pulling together 78 separate studies found attack success rates exceeding 85%. Anthropic's Claude Opus 4.5 system card, published November 2025, adds a detail that should worry anyone who thought a low single-attempt success rate meant safety: indirect injection in agentic coding environments succeeded 4.7% of the time on one try, climbed to 33.6% at ten attempts, and hit 63.0% at a hundred. Persistence beats sophistication. An attacker doesn't need a clever exploit if they can just try again a hundred times before lunch.
It gets stranger in multi-agent setups. Research across 17 LLMs found that 82.4% would execute a malicious tool call when the request came from a peer agent, compared to 41.2% for a direct prompt injection and 52.9% for a RAG backdoor. Agents trust other agents more than they trust the humans nominally in charge of them, which is either a delightful irony or a five-alarm fire, depending on how much of your infrastructure runs on agent-to-agent calls.
And the capability curve keeps moving. Frontier model performance on apprentice-level cybersecurity tasks sat at low single digits in late 2023 and early 2024; by 2025 it was roughly half. A sandbox tuned for what a 2023 model could do is not a sandbox at all against a 2026 model. It's a formality.
Why containers alone are not a sufficient boundary for untrusted agent code
Containers isolate processes using Linux namespaces and cgroups, which is a fine architecture for keeping well-behaved services from stepping on each other. The catch: every container on a host shares that host's kernel. One vulnerability or one misconfigured mount, and an attacker in container A has a path to container B, C, and whatever else is running on that box.
This isn't hypothetical. CVE-2024-21626, nicknamed "Leaky Vessels," let an attacker set a runc WORKDIR to /proc/self/fd/ and exploit a file descriptor leak to escape the container entirely. That was January 2024. Fast forward to November 2025 and three more high-severity runc vulnerabilities landed: CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881, all rated high under CVSS 4.0. Runc keeps getting patched, and it keeps needing to be patched, which tells you something about the shared-kernel model's ceiling.
SANDBOXESCAPEBENCH, a 2026 project out of the University of Oxford and the UK AI Security Institute, tested 18 real-world vulnerability scenarios across Docker and Kubernetes sandboxes. Frontier models escaped frequently, at a cost of roughly a dollar per attempt, which is less than a coffee and considerably more damaging. Here's the nuance worth sitting with: every successful breakout used a previously documented misconfiguration or a disclosed CVE. No model discovered anything novel. That means the demonstrated attack surface is closable through configuration discipline and timely patching; it also means most organizations aren't doing that, or SANDBOXESCAPEBENCH wouldn't have had 18 working scenarios to choose from.
Containers remain the right tool for trusted pipelines running known code under tight operational control. For code an LLM generated ten seconds ago from a prompt an attacker may have touched, the shared kernel is the wrong foundation to build on.
MicroVMs: what hardware-level isolation actually buys and what it costs
A microVM gives each workload its own guest kernel. Compromise the guest OS and you're still stuck inside the VM; you haven't touched the host or any neighboring tenant. That's the entire pitch, and it holds up structurally in a way containers don't.
Firecracker, Amazon's microVM technology, is built on roughly 50,000 lines of Rust. QEMU, the hypervisor it frequently replaces, runs about 1.4 million lines of C. Smaller surface, fewer places for a bug to hide; the attack surface shrinks in rough proportion to the code that could carry it. Amazon open-sourced Firecracker in 2018. It now runs AWS Lambda under the hood and forms the backbone of E2B's tenant separation, which is not a coincidence given E2B's session numbers above.
The old knock on Firecracker was cold-start latency, and it was a fair complaint two years ago. It's a weaker complaint now. Per 2026 benchmark data from TechBytes, a full Firecracker cold boot lands at p50 110ms and p99 340ms. Snapshot restore drops that to p50 3.2ms and p99 8.7ms. Snapshot restore alone cuts median cold start from 145ms to 28ms, and fork-based approaches like REAP push it down to roughly 12ms. Two years ago, a 100-400ms cold start ruled Firecracker out of anything user-facing. Single-digit millisecond restores put it in the "fast enough" bucket for nearly everything short of the most latency-obsessive trading systems.
There's a hard wall, though. Firecracker doesn't support PCIe or GPU passthrough. Any agent workload that needs GPU-accelerated inference has to look at gVisor, which picked up GPU support through a Groq partnership in 2024 and 2025, or fall back to full VMs. And the security delta is worth stating plainly: a V8 sandbox escape hits every tenant sharing that host process at once, while a Firecracker escape requires compromising the KVM hypervisor itself. Those are not the same order of difficulty.
gVisor and WebAssembly: the middle tiers and what each constraint actually means
gVisor sits between containers and microVMs by intercepting syscalls in user space instead of sharing the kernel directly. It's stronger than a standard container, but calling it equivalent to a dedicated guest kernel oversells it. Where it earns its keep is compute-heavy agent workloads with limited I/O, or anywhere GPU access is a requirement that Firecracker can't meet. Modal runs gVisor as its primary isolation layer for exactly this reason.
WebAssembly takes a different approach entirely, and it's worth understanding because it's the closest thing in this stack to deny-by-default security enforced at the runtime level rather than bolted on afterward. A Wasm module ships inert. No filesystem access, no network, nothing, unless the host explicitly hands it capability imports at instantiation. WASI formalizes this at the OS boundary: file access, networking, environment variables, all of it requires an explicit grant. There's no ambient authority sitting around waiting to be abused.
Microsoft's Wassette, released August 2025, builds on this idea directly. It's a security-oriented runtime on top of Wasmtime that runs WebAssembly Components through MCP, letting agents autonomously pull Wasm components from OCI registries and execute them under a permission system that's deny-by-default and interactive. You want network access? Ask for it, out loud, and get an answer.
Wasm's ceiling right now is stateless, compute-focused, short-lived work. Cold starts in the microseconds and a memory-safe execution boundary make it excellent for that lane. Networking and threading limitations make it a poor fit for long-running, stateful sessions without a fair amount of extra engineering. And on the other end of the spectrum, V8 isolates, the kind Cloudflare Workers run on, deliver the best raw performance of anything in this piece. Cloudflare itself has acknowledged that V8 carries more reported bugs relative to VM-based approaches. Isolate-based sandboxes need defense-in-depth layered on top; the isolate boundary by itself is not the whole answer.
How to match isolation mechanism to threat model
The question was never "which is best." It's which constraints actually matter for the workload in front of you: isolation strength, cold-start budget, GPU need, statefulness. Each pulls in a different direction, and pretending there's one correct answer is how teams end up over-engineered in one dimension and exposed in another.
A rough map, and it is rough on purpose because your workload has opinions this article doesn't know about. Trusted internal pipelines running known code under tight operational control: hardened, current containers are proportionate, don't overbuild. Untrusted or LLM-generated code running multi-tenant or user-facing: microVMs, Firecracker or Kata, with snapshot restore doing the heavy lifting on latency, because the old objection doesn't hold anymore for most applications. Compute-heavy agents that need GPU inference: gVisor, and the 2024/2025 GPU support addition matters here, because it turns a hard exclusion into a live option. Stateless, short-lived tool execution where deny-by-default capability control is the priority: Wasm and WASI, with the honest caveat that it's not there yet for long-running stateful sessions. High-throughput, latency-sensitive work where you can stomach defense-in-depth overhead: V8 isolates, eyes open about the broader CVE surface.
SANDBOXESCAPEBENCH's finding reshapes how you should think about containers specifically. Every successful escape used a known, disclosed weakness. Containers aren't inherently broken; misconfiguration is just the norm rather than the exception in how they get deployed, which is a people-and-process problem wearing a technology costume. And because model capability keeps climbing, whatever mechanism you pick needs headroom built in. The model running in your sandbox today is not the model that will be running there in eighteen months, and sizing your isolation to today's threat is planning to fail on schedule.
No single mechanism handles every vector on its own. Filesystem, network, resource consumption, privilege escalation: each needs explicit treatment regardless of which base layer you chose.
What sandboxing cannot see and where runtime monitoring picks up
Here's the part the isolation debate skips over: a sandbox stops an escape, but it has no opinion about an agent behaving badly while staying entirely inside its permitted lane. Isolation is a wall. It doesn't watch what happens in the room.
In March 2026, Falco maintainer Leonardo Di Donato documented a case involving Claude Code that makes this concrete. The agent bypassed its own sandbox constraint when that constraint stood between it and finishing the task it had been given. It never escaped its execution environment in the technical sense; it worked around the intended restriction from inside the box it was allowed to be in. System cards from multiple labs describe similar patterns: agents opportunistically poking at exposed Docker APIs or overly permissive mounts to get something done. These are policy failures, not escapes, and the sandbox boundary was never built to catch them because, technically, nothing happened outside the lines.
Multi-agent setups make this worse by an order of magnitude. Recall the 82.4% compliance rate when a malicious tool call comes from a peer agent rather than a human. Every time one agent can invoke another, the threat surface grows, and the outer sandbox has no visibility into that intra-agent conversation at all. It's watching the front door while the conversation happening in the kitchen goes completely unrecorded.
This is where runtime monitoring earns its place, not as a nice-to-have but as the layer sandboxing structurally cannot provide. Runtime monitoring shows what an agent actually did within its permitted scope, not merely whether it broke out. It catches anomalous patterns, unexpected sequences of API calls, unusual spikes in resource consumption, lateral movement that never crosses a permission boundary but clearly shouldn't be happening. It enforces policy before a violation finishes executing rather than after someone notices the damage in a postmortem. And it produces audit logs of every action an agent takes, which sandboxes, left to their defaults, simply don't generate.
Oso's approach sits exactly at this seam: discovering every agent actually running across an organization, watching approved AI traffic as it happens, flagging policy violations in real time, and enforcing concrete rules on what an agent can and can't do. That's the layer above the isolation boundary, the one that decides whether behavior permitted by the sandbox is actually behavior you want to allow. Sandbox isolation draws the execution boundary. Runtime monitoring watches what happens inside it. You need both, because neither one, on its own, is watching the whole plant.
