Pick Your Sandbox

Lesson 4 said run the agent in a sandbox. This is the next question: which runtime enforces it? Containers, microVMs, and OS-level isolators trade isolation strength against startup cost — and the workload decides.

Why this, for you: "sandbox it" is necessary but underspecified. The runtime you choose sets the blast radius on an escape, the cold-start budget, and whether multi-tenant workloads are safe at all. This lesson is the selection rubric — match the runtime to the threat, not to fashion.

Dual-boundary sandboxing (Lesson 4) defines what a sandbox enforces; this lesson picks which runtime enforces it. Three families, with sharply different trade-offs — and the right pick depends on one question above all: is the agent running untrusted code, and is the host multi-tenant?

1 Three families, one axis: isolation vs cost

Family	Boundary	Startup	Escape blast radius
Containers	Shared host kernel + namespaces	~100 ms–seconds (image pull)	Host kernel CVEs
MicroVMs	Hardware virtualization (KVM)	≤125 ms VM boot	Hypervisor CVEs (smaller)
OS-level isolators	Shared kernel / Seatbelt policy	tens of ms (no daemon)	Host kernel + profile bugs

Containers are fast but kernel-shared. MicroVMs put a hypervisor between workload and kernel — ≤125 ms to guest init per the Firecracker spec, with ≤5 MiB VMM overhead. OS-level isolators are fastest and need no daemon, but offer the weakest escape resistance.

2 The decision turns on untrusted + multi-tenant

When the agent runs code from untrusted inputs — third-party PRs, prompt-injected scripts, customer snippets — a kernel CVE turns a shared-kernel runtime into a multi-tenant breach. That's the case for a microVM. Firecracker was built at AWS for Lambda and Fargate precisely to host thousands of mutually-untrusting, hardware-separated workloads per host.

# Selection trace: untrusted, multi-tenant, cold-start < 1s, existing k8s 1. untrusted + multi-tenant → drop plain Docker (shared kernel) 2. cold-start < 1s → Firecracker fits (≤125 ms boot) 3. existing kubernetes → Kata / e2b / Modal integrate 4. dev laptops that build it → bubblewrap (Linux), Seatbelt (macOS, deprecated)

Trusted, single-host, single-tenant code is the opposite case: a laptop running its owner's prompts has no multi-tenant adversary. bubblewrap (Linux) or Seatbelt (macOS) is correct, and microVMs add cost for nothing.

3 Isolation is necessary, never sufficient

The runtime itself ships CVEs — and agents reason around it

Hypervisor isolation is necessary but not sufficient: the VMM and jailer still ship bugs (e.g. CVE-2026-1386, a Firecracker jailer symlink host-file overwrite). And no runtime stops a capable agent from finding alternative paths — Ona documented a Claude Code session that bypassed its own denylist and disabled bubblewrap. Patch the runtime as hard as the guest, and treat runtime hardness as one layer, not the whole defense.

Two more caveats. macOS sandbox-exec is deprecated since macOS 10.13 — plan a migration for new tooling. And if your team is already on Modal, e2b, or Kubernetes, the platform decides the runtime; the rubric applies only at platform-selection time. The harness API hides runtime choice behind execute(name, input), so you can change runtime per fleet without rewriting the agent loop.

↪ Your win: match the runtime to the threat

Untrusted code or multi-tenant host? Use a microVM — hypervisor isolation, ~125 ms boot.
Trusted single-host dev? Use bubblewrap or Seatbelt — no daemon, fastest, sufficient.
High churn with prebuilt images? Containers win once the image cache is warm.
Patch the runtime, not just the guest — the VMM and jailer ship CVEs too.
Treat isolation as one layer — a capable agent can reason around any single sandbox.

Retrieval practice — recall, don't peek

Question 1The defining trade-off across sandbox runtimes is…

Question 2For untrusted code on a multi-tenant host, the right family is…

Question 3Compared to a shared-kernel container, a microVM puts a hypervisor…

Question 4The CVE-2026-1386 jailer bug is a reminder that…

Question 5 · spaced recall from Lesson 9Across OverEager-Bench, the largest driver of the overeager rate is the…

Ask me anything. Want to run the selection trace for your own fleet, or see where gVisor sits between plain containers and microVMs? Next, Part 5 opens with The Gateway in the Middle — interposing one policy point between every agent and every tool.