MicroVM sandboxes for tool use, in three diagrams

If your agent runs a shell, opens a browser, or executes generated code, the isolation boundary is the most consequential infra decision you make. Three options dominate, and they are not interchangeable.

Containers (Linux namespaces)

Cheap, fast to boot, leaky. Your kernel is shared. A kernel CVE in 2024 means your "sandbox" is your whole host. Fine for trusted code, wrong for code an LLM just wrote.

gVisor (user-space kernel)

Strong isolation via a user-mode Linux ABI; intercepts every syscall. Slower than containers, faster than VMs to start. Some syscalls are partially emulated, which surprises real workloads. A reasonable default for "untrusted but well-behaved" code.

MicroVMs (Firecracker, Cloud Hypervisor)

Real virtual machines, just very small ones (kernel + minimal device set). Sub-second boot. Hardware isolation, full Linux ABI. The right choice when the code might be hostile or when you need predictable performance.

How to pick

Map this to L4 of the runtime taxonomy:

• Code from a trusted human author? Container is fine.
• Code generated by an LLM, executed once? gVisor is the sweet spot.
• Code generated by an LLM that holds secrets, or runs a browser session? MicroVM. The boot cost is amortized over the session.

We are publishing a benchmark suite that runs the same agent harness across all three boundaries with identical observability — the goal is to make the tradeoff a number you can put in a spreadsheet, not a vibe.