Google Described Its Agent Sandbox. I Built One with Firecracker and Measured It

A Go prototype recreates key parts of Google’s proposed agent-sandbox design using Firecracker microVMs, then measures startup and memory use on bare metal and a Mac mini running nested virtualization. The design assumes agent code may be hostile, so it gives each session a separate guest kernel rather than relying on container isolation. Guests have no network card: they communicate over vsock with an orchestrator and an egress proxy, which applies policy and adds credentials outside the sandbox. This keeps real tokens out of reach even if an agent is compromised. Warm snapshots let many VMs share unchanged memory copy-on-write; virtio-pmem with DAX can also share read-only root filesystem pages.

The prototype checkpoints sessions when tool calls finish and no user processes remain, using the agent harness’s knowledge of activity rather than inferring idleness from CPU use. It supports pausing a VM or hibernating it to a disk snapshot. On bare metal, restoring a snapshot took 25 ms - 26 times faster than a cold boot - and 64 forks became ready in about 150 ms. Each idle fork of a 512 MiB guest used roughly 3 MiB of host memory. Nested virtualization proved a major caveat: twelve simultaneous forks on the Mac mini never became ready. The results show that open-source components can deliver fast, dense isolation on suitable hardware, but that performance and even successful startup depend on the virtualization environment.