MicroVM and Sandbox Isolation Architecture

Running untrusted code (agent tool calls, user submissions, CI jobs) demands isolation strong enough that an escape cannot reach the host or neighboring tenants, yet light enough to start in milliseconds and pack densely. The microVM — a stripped-down hardware-virtualized guest — is the current sweet spot between container speed and VM security.

The isolation spectrum runs from weakest/fastest to strongest/slowest. The architectural choice is which point on it matches the threat model and the start-latency/density budget. Source: compiled from Firecracker, NSDI 2020

The isolation spectrum

A microVM gives each sandbox its own guest kernel (so a kernel exploit cannot cross the boundary) while dropping the heavy device emulation of full VMs, which is what gets the start time down to milliseconds and the per-instance memory overhead low enough to pack thousands per host. Source: Firecracker, NSDI 2020

Why the boundary is worth the cost. A container escape gives an attacker root on the host (and every co-tenant's data); it requires only a bug in the shared kernel's 400–450+ syscalls, and such CVEs ship regularly. A microVM escape requires a hypervisor CVE — a bug class so rare it commands $250K–$500K bounties (Google's kvmCTF pays $250K for a KVM escape). The boundary moves from a software convention enforced by a ~30–40M-line C kernel to hardware virtualization enforced by the CPU, orchestrated by a VMM of only ~83K–106K lines of memory-safe Rust. The full argument and 2026 industry map are in Containers Are Not a Security Boundary. Source: emirb.github.io/blog/microvm-2026, 2026-06-21; X/@kylejeong, 2026-05-11

Architecture of a microVM sandbox

• VMM (Cloud Hypervisor / Firecracker) — a minimal user-space monitor: a few virtio devices, no BIOS/PCI bloat, one process per guest.
• Guest — a small kernel + minimal rootfs running the workload.
• Host agent — exposes a control API (start/stop, exec, resource hotplug) to the orchestrator.
• Snapshot/restore — pause a booted guest to memory + disk and resume it; warm pools + snapshots are how cold start is hidden. (Firecracker's snapshot path is the mechanism behind AWS Lambda SnapStart.)
• Resource control — cgroups + virtio-mem / vCPU hotplug for elastic sizing; per-guest network + block devices.

A reference VMM exposes the guest to as little as possible: Firecracker runs one microVM per process with three thread types (API / VMM / vCPU), exactly four devices (virtio-net, virtio-block, virtio-vsock, serial), and a defense onion of jailer (chroot + PID namespace + unprivileged uid + cgroups) plus per-thread seccomp allowlists. Source: X/@kylejeong, 2026-05-11

Choosing a VMM: Firecracker vs Cloud Hypervisor

Both use KVM and share low-level code through the Rust VMM crate ecosystem; the choice is about feature surface vs attack surface. Source: emirb.github.io/blog/microvm-2026, 2026-06-21

Dedalus's VMM DHV is a Cloud Hypervisor fork — the heavier feature set (live migration, hotplug, virtio-fs over vhost-user) is what persistent agent machines need. Source: Dedalus Machines - How They Work

What the host wraps around the VM

The bare microVM is commodity (Apache-2.0 VMMs; container→rootfs is a ~200-line script). The product value is the host-side envelope: session observability/replay through a single collector, secrets brokered at the wire (guest sees placeholders; a host egress proxy substitutes real credentials against an allowlist), identity signed at the host before packets leave (key never enters the guest), and colocated compute (e.g. a browser on the same microVM, CDP over a Unix socket). Source: X/@kylejeong, 2026-05-11

Design implications

• Start latency vs isolation is the core tradeoff — and for stateful/agent workloads, resume time matters more than cold boot (Agent Sandboxes).
• Density drives economics. Per-guest memory overhead × thousands of tenants is the cost model; minimal VMMs win here.
• The filesystem is the state seam — copy-on-write/overlay layers let many guests share a base image and fork cheaply (Overlayfs Block-Copy (M10)).
• Strong isolation enables multi-tenancy — separate kernels are what make it safe to co-locate untrusted tenants.

This is the architecture under Kevin's Dedalus DCS/DM: workspaces run as Cloud Hypervisor microVMs, one process per workspace, with a ConnectRPC host-agent API, vCPU/memory hotplug, live migration, and per-minute billing — the same primitive durable agents persist their state inside. Source: compiled from Agent System, dcs-gauntlet-infrastructure.md

Architecture Position

---

Timeline

• 2026-07-01 | Architecture category refresh added this page to the Safety and observability family, linked it to Architecture System Map, and kept it standalone because it owns this boundary: Isolation boundary for untrusted code and agent tool execution. Source: User request, 2026-07-01

• 2026-06-21 | Enriched from a dual-source capture (Kyle Jeong's Firecracker explainer + emirb's microVM-isolation survey): added the security-economics rationale ($250K–$500K hypervisor-escape asymmetry), a reference-VMM internals note, a Firecracker-vs-Cloud-Hypervisor decision table, and the "what the host wraps around the VM" product surface. Linked new pages Containers Are Not a Security Boundary, Firecracker, Cloud Hypervisor, Rust VMM. Source: X/@kylejeong, 2026-05-11; emirb.github.io/blog/microvm-2026, 2026-06-21

• 2026-06-02 | Page created. Captured the isolation spectrum (process→container→gVisor→microVM→VM), why microVMs hit the speed/security sweet spot, the VMM/guest/host-agent/snapshot components, and implications (start-vs-resume, density economics, CoW filesystem, multi-tenancy), grounded in Dedalus DCS. Source: compiled from Firecracker (NSDI 2020), gVisor, Dedalus DCS