Sandbox Code Execution Models Across Runtimes

Security researcher Johann Rehberger demonstrated the failure mode that makes this entire conversation necessary: Claude, running directly on a host machine with no sandbox, navigated to a malicious webpage, downloaded a binary, ran chmod +x, executed it, and connected to a command-and-control server, and the whole chain worked on the first try. That incident is the reason the rest of this piece exists. The choice of execution model for AI-generated code, whether that model is a shared-kernel container, a microVM, a user-space kernel, or a WebAssembly isolate, comes down to a tradeoff between isolation strength, latency, statefulness, and operational cost, and the right answer depends on specifics that most teams haven't actually named out loud. This piece maps that spectrum directly: the five isolation levels available in 2026, where each step up from containers trades a measurable performance or compatibility cost for a meaningfully stronger security boundary.

Why shared-kernel containers are structurally insufficient for AI-generated code

The Rehberger chain matters because it skipped every safeguard a sandboxed environment would have provided, and it did so without needing a novel exploit, just a prompt, a browser, and a shell. Standard Docker and runc containers separate processes with Linux namespaces and cgroups, but every container on a host still shares one kernel, so a kernel vulnerability exploited inside a single container can reach every other container and the host underneath them. That architecture was built for a world of trusted, reviewed code, and it works fine there. AI-generated code breaks that assumption at the root, because it is untrusted by construction rather than by exception, and an agent can install packages on its own, open and manipulate file descriptors, and run arbitrary shell commands, each of which widens what a shared kernel exposes.

But why does a kernel vulnerability matter more for agent code than for code a human engineer wrote and that passed CI/CD? You could argue the kernel attack surface has always been there, container or no container, so singling out AI-generated code looks like misdirected blame. What triggers the exploit path is different for human-written code and agent-generated code. Code a human wrote and cleared through review rarely tries to download and execute an unknown binary mid-session. An agent acting on a poisoned web page or a manipulated prompt can decide to do exactly that, autonomously, in the middle of a task it was never asked to perform, which is the exact shape of the Rehberger demonstration.

Supply-chain exposure compounds the problem rather than sitting beside it. A meaningful share of the packages an AI model recommends are hallucinated names that don't correspond to anything real, and a consistent subset of those invented names repeats across separate queries. An attacker can register a package under a name the model is likely to suggest repeatedly and wait for an agent to install it. Inside a shared-kernel container, if a dependency-squatting attack succeeds, it isn't contained to the workload that triggered it. It has a path to the kernel the rest of the host depends on.

The response from the largest cloud operators settles the argument about whether this is a real engineering concern or a vendor talking point. AWS built Firecracker for Lambda, Google built gVisor for App Engine, Cloud Run, and Cloud Functions, and Azure runs Hyper-V-isolated dynamic sessions alongside hardware-isolated microVMs in Container Apps Sandboxes for exactly this kind of ephemeral, agent-driven execution. None of the three reached for a standard container when isolation for AI workloads was the design goal. That is a strong, converging signal from three separate engineering organizations solving the same problem independently.

None of this means containers are obsolete. Containers stay fast, familiar, and perfectly adequate for code written internally and verified through CI/CD, and that doesn't make the case that containers are useless in general. It's that code generated by a language model occupies a different trust tier than code a team wrote and reviewed, and containers were never designed to hold that tier safely. Treating LLM output like reviewed internal code is a category error, not a judgment about containers as a technology.

The five isolation primitives and their tradeoffs

Five isolation levels make up the spectrum available in 2026, and each step up from plain containers buys a stronger security boundary at a cost that shows up somewhere specific, whether in latency, compatibility, or operational weight.

Level 1 is the container, Docker or Podman, where processes share the host kernel and are kept apart only by namespaces and cgroups. This is fast and lightweight, and a kernel vulnerability discovered inside one container can still spread to every other container on the host. It remains the right choice for trusted, internally-written code, but it is the wrong choice for anything a language model produced on its own.

Level 2 is the user-space kernel, best represented by gVisor. Instead of letting a sandboxed program talk to the real kernel, gVisor intercepts and re-implements the syscalls itself in user space, which gives it a stronger boundary than a container while avoiding the overhead of running a full virtual machine. The incomplete syscall emulation causes the cost: not every syscall is emulated perfectly, so teams running unusual system dependencies can hit real friction here. Google built gVisor to isolate its own production workloads at scale, and when you evaluate how the technology holds up under sustained load, that production history carries real weight.

Level 3 is the microVM, the category that includes Firecracker, Kata Containers, and libkrun. Each workload here gets its own kernel running on hardware virtualization through KVM, so a kernel exploit inside one VM has no path to the host or to any neighboring VM. This is the current gold standard for executing code nobody trusts, and Firecracker in particular boots in roughly 125 milliseconds with about 5MB of memory overhead. Kata Containers takes a slightly different route to the same place: it wraps each container in its own microVM while still presenting a standard OCI-compatible interface, so teams get microVM-grade isolation without throwing out their existing container tooling. The honest cost here is latency. Cold starts range from that roughly 125ms Firecracker boot-to-init baseline up to multiple seconds in practice, depending on image size and networking setup, and warm pools reduce that latency but don't change its upper bound. For any interactive agent workload, that cold-start number is the central engineering constraint the rest of the architecture has to work around.

Level 4 is the library OS, represented right now by Microsoft's LiteBox. Rather than filtering hundreds of individual syscalls the way gVisor does, the application links directly against a minimal OS library that exposes only a small, controlled set of primitives. In theory this produces the thinnest isolation layer and the smallest attack surface of any option on this list, but as of February 2026 it remains experimental, with no stable SDK and no production usage to point to. Not yet a deployable option for anything in production.

Level 5 is confidential computing: AMD SEV-SNP, Intel TDX, OP-TEE. Memory here is encrypted at the hardware level, so even the host operating system and the hypervisor sitting above it cannot read what the sandbox is doing. LiteBox is currently the only open-source tool in this comparison that ships a confidential computing runner built on SEV-SNP, and the category matters most for regulated industries handling PII, financial records, or healthcare data, where the threat model includes the infrastructure operator itself.

A cross-cutting category sits alongside this progression: WebAssembly and V8 Isolates. They don't fit neatly into the linear progression, because their tradeoff runs along a different axis entirely: you trade isolation strength for startup speed and accept real restrictions on what code can run inside them.

Laid out together, the tradeoff is straightforward to state. Containers win on speed and compatibility and lose on isolation. MicroVMs win on isolation and carry real production credibility, and pay for both in cold-start latency. gVisor splits the difference on both axes at once. WASM wins on startup speed in exchange for restricting what the agent can actually execute. Confidential computing adds a layer of memory-level privacy no other option provides, but you pay for it in availability and real operational complexity.

Matching trust level, session duration, and latency budget to a primitive

Here is the question the spectrum above doesn't answer on its own: given five options, which one actually fits a specific workload? The right primitive is a function of three axes that need to be evaluated independently before they're combined: how hostile the code is (trust level), how long the session needs to stay alive, and how much latency the use case can tolerate.

The first axis is trust level. Code an engineering team wrote internally and pushed through CI/CD sits at the low end of risk, and standard containers are probably fine for it. Code a language model generates on the fly, an agent writing Python to solve a problem or reformat a file, is at meaningfully higher risk, and that tier calls for gVisor or a microVM. User-uploaded binaries or arbitrary packages pulled from PyPI are at the far end: the only sound posture is to assume the code is hostile and isolate it with hardware virtualization through microVMs, or with an air-gapped primitive entirely. You could argue that this classification should track the model being used, on the theory that a more capable model produces safer code. It doesn't work that way. The classification tracks who controls what actually gets executed, not which model wrote it. A coding agent that lets an end user feed it arbitrary instructions behaves, for sandboxing purposes, much closer to "user-uploaded binary" than to "internal logic," regardless of how good the underlying model is.

The second axis is session duration. A one-shot script, generating a chart, formatting a spreadsheet, running a single calculation, has no state that needs to survive past that single execution, so an ephemeral sandbox fits without complaint. A multi-step workflow is a different animal: cloning a repository, installing dependencies, editing files across several turns, running a build, reading the errors, and iterating again. Forcing that workflow into an ephemeral runtime makes the agent re-clone the repo and reinstall every dependency on every single step, which is wasteful at best and brittle at worst. That kind of workload needs a stateful sandbox, one that keeps files, installed packages, running processes, and environment variables alive between executions.

The third axis is the latency budget available to the use case. For an agent answering a user in real time, cold-start latency is a user-experience constraint, not just a performance detail. A two-second cold start on a microVM reads as broken in a conversational coding assistant, where a user is sitting and watching, and reads as entirely acceptable in a background batch job that nobody is staring at. Warm pools and snapshot-or-restore techniques exist specifically to close that gap for microVMs: Fly.io's Sprites product reports roughly 300ms for checkpoint and restore on Firecracker, and Vercel Sandbox leans on Firecracker filesystem snapshots to get a comparable result. The snapshot-or-fork pattern pushes this further still, branching a copy-on-write image for each new task from a parent image that already has its dependencies installed and its caches warm, so the expensive setup work happens exactly once and every subsequent task shares that base. If even those numbers are too slow for a workload, V8 Isolates and WASM runtimes offer sub-50ms startup, but you pay for that speed with the language and compatibility ceiling noted on the trust axis above.

The interesting case is where all three axes point toward difficulty at once: code that is genuinely hostile, a session that needs to run long, and a latency budget tight enough that users will notice delay. That combination pushes toward microVMs running with warm pools and a stateful design, which is also the most operationally demanding configuration on this entire spectrum to build and maintain.

In practice, the decision collapses into three paths. Teams that need maximum control and customization for compliance reasons should pick Layer 1 primitives directly: Firecracker, gVisor, or LiteBox. If you already run Kubernetes and want open-source sandboxing with warm pools and no new vendor dependency, you should look at hybrid approaches such as Google's Agent Sandbox. Teams that need GPUs, data-local execution, or zero-ops scaling should look to managed platforms, while weighing vendor lock-in, language constraints, and BYOC support carefully before committing.

The 2026 sandbox ecosystem mapped to those primitives

The market by 2026 has settled into three layers, primitives, embeddable runtimes, and managed platforms, and knowing which layer a given tool occupies tells you immediately what it can and cannot do for an agent workload.

At the OS level sit the lowest-overhead, weakest-boundary tools: macOS Seatbelt and sandbox-exec, built on an OS-level mandatory access control framework; Linux Landlock, an unprivileged filesystem and network security module; Linux seccomp-bpf for syscall filtering; bubblewrap, the unprivileged namespace sandbox that backs Flatpak; and nsjail, Google's combined namespace-and-seccomp jail, which Windmill uses for Python and Go execution. Anthropic's own Sandbox Runtime, srt, lives at this layer too: it uses Seatbelt on macOS and bubblewrap on Linux, paired with a network-filtering proxy, with no container involved at all. These tools fit coding agent CLIs running locally on a developer's own machine well, and they are not built for multi-tenant production workloads, where the isolation guarantees they offer aren't strong enough to hold multiple untrusted customers apart.

At the microVM layer, several platforms translate Level 3 isolation into a usable product. Docker Sandboxes, marketed as sbx, is Docker's purpose-built microVM-backed sandbox CLI, designed to work with Claude Code, Codex, Gemini CLI, Copilot CLI, OpenCode, Kiro, and other agent tools. Fly.io's Sprites product runs Firecracker microVMs with persistent 100GB NVMe storage, checkpoint and restore around 300ms, and scale-to-zero when idle. Vercel Sandbox, now generally available, also runs on Firecracker microVMs, uses filesystem snapshots, and integrates directly with the AI SDK and the OpenAI Agents SDK. Northflank Sandboxes takes the Kata Containers route on top of Kubernetes, supports bring-your-own-cloud deployment, and positions itself as full-stack agent infrastructure. An independent benchmark run by ComputeSDK reported a 97ms median time-to-interactive with a 100% success rate for Northflank's setup. Blaxel runs microVMs as well and claims roughly 25ms resume from standby, which is a distinct measurement from a traditional cold start, aimed squarely at agent-grade workloads where every millisecond of perceived delay matters.

Mapped back onto the three-axis framework from the previous section, the pattern holds together cleanly. OS-level tools provide isolation for single-developer, single-machine use, and they stop there, because they were never built to separate multiple untrusted tenants from one another. MicroVM platforms answer the harder combination: genuine isolation for hostile code, persistence for multi-step sessions, and, increasingly, latency numbers low enough for interactive use. Which of those products fits a specific team depends on exactly the three axes laid out above, trust, duration, and latency budget, evaluated honestly rather than assumed, before a single line of infrastructure gets written.