Chapter · microvms

MicroVMs: a real kernel at container speed

A microVM is a virtual machine with almost everything removed: a small device model, a purpose-built monitor, and a boot time measured in tens of milliseconds. It is the strongest isolation you can get on a Linux laptop, and the most fiddly to assemble.

Anatomy of a microVM

What makes a microVM different from a container is a single fact: the workload gets its own Linux kernel. To reach your machine, code has to get through its own kernel, then through the virtual machine monitor, then through whatever the hypervisor exposes to the host. That is a fundamentally different problem from escaping a namespace, and it is why the security literature keeps landing on microVMs as the credible answer for hostile code.

What makes it different from a full VM is subtraction. Firecracker emulates six devices; QEMU emulates hundreds. Firecracker is roughly fifty thousand lines of Rust; QEMU is measured in millions of lines of C. Every emulated device is a potential bug, so a smaller device model is a smaller attack surface — and, more importantly, a boot path short enough to be measured in hundreds of milliseconds.

The four things you have to assemble

A kernel. Firecracker needs an uncompressed vmlinux with the right virtio drivers built in, so you cannot point it at your distro's default image.
A root filesystem. An ext4, xfs or erofs image containing your toolchain — usually produced by flattening an OCI image or by debootstrap plus mkfs.ext4.
A way to get your project in. This is where Firecracker and Cloud Hypervisor diverge sharply: Cloud Hypervisor has virtio-fs, Firecracker does not.
A way to get output out. Usually vsock, which is fast enough for real work (hundreds of megabytes per second) whereas serial is not.

The stack. Note the two details people miss: the VMM itself is a host process that needs its own seccomp filter, and virtio-fs is not universal — the choice of VMM decides whether you can mount a directory at all.

The independent evidence

There is one genuinely useful comparative study of AI sandbox engines: AI Code Sandboxes: A Comparative Security Study (arXiv 2606.08433, June 2026), which measured five products across six engine-level axes with the same harness on the same host. Its most valuable contribution is not a ranking — it explicitly refuses to produce one — but the per-axis observations. The table below is a summary of its findings, not a substitute for reading it.

Summary of the arXiv study's per-product readings. ▲ best · ◆ middle · ▼ worst on that axis; the authors forbid combining them into a score.
Product	Engine	Host attack surface	Info leakage	CVE history (24 mo)	Patch cadence	Fuzzing
gVisor (runsc)	User-space kernel	▲ 5/14 primitives	◆ 2 leaks	0 escape-class	Rolling main, silent fixes	▲ Continuous syzkaller dashboard
E2B	Firecracker microVM	◆ 7/14 primitives	▲ 0 leaks	2 escape-class (first ever)	▼ 399-day pin freeze	▼ No upstream fuzzer
Cloud Hypervisor (as "arrakis")	Cloud Hypervisor microVM	▼ 12/14, live /dev/kvm exposure	◆ 1 leak	1 escape-class + 1 leak	▼ 471-day pin freeze	▲ 18-target in-tree harness
Microsandbox	libkrun microVM	▼ 11/14, no engine seccomp	▲ 0 leaks	0 (undefined exposure)	◆ 1–3 month cadence	▼ No fuzzer, no study
Daytona (default)	runc container	▼ 11/14, full host kernel	▼ 10 leaks	4 escape-class	▲ via Docker-CE's bundled runc	◆ Narrow OSS-Fuzz targets

The finding that should change your defaults

Engine class is the dominant signal, but the product's pin policy is close behind. In the study, two products sat on a frozen engine version — one for 471 days across twelve upstream releases — and missed published escape-class fixes. Engine-side patch latency was effectively zero for coordinated disclosures; the entire delay came from downstream pinning. Whatever you build, decide how you receive engine updates, because that is the axis where your choices are the whole story.

The finding that should temper your confidence

"Zero CVEs" is not a safety signal. The engine with the cleanest CVE record in the study also had no upstream fuzzer, no published study, and no engine-side seccomp filter — the authors describe that intersection as structurally unmeasured and place the residual-bug risk highest there. Meanwhile both of the previously pristine microVM engines (Firecracker and Cloud Hypervisor) published their first escape-class advisories within a four-month window. Read the absence of advisories as an absence of search.

The runtime landscape

Firecracker

RECOMMENDED / MATURE AWS · Apache-2.0

Six emulated devices, ~50k lines of Rust, the tightest seccomp ceiling measured (55 syscalls), and Lambda-scale production history. The gold standard for isolation-per-line-of-code.

But: no virtio-fs, no hotplug, no GPU, no confidential computing, resources sized at boot, and a cold start closer to one second than the datasheet's 125 ms unless you maintain a snapshot pool. One assessment put a Docker-to-Firecracker migration at four to six engineer-months and concluded Firecracker was disqualified for its workload purely on the file-sharing gap.

Full assessment →

Cloud Hypervisor

RECOMMENDED / MATURE Intel · Linux Foundation

The VMM to pick when you need microVM isolation and developer conveniences: virtio-fs, hotplug, vhost-user offload, snapshot and restore, live migration, a typed Rust API, and per-thread seccomp on its worker threads.

Evidence: Microsoft chose it for Kata-based Pod Sandboxing on AKS; Fly.io uses it for GPU machines; it is a supported Kata backend and the primary VMM in Spectrum OS; 52 major releases since 2019; every in-window CVE shipped with a same-day advisory and patch.

Full assessment →

crosvm

GOOD, BUT TEST IT FIRST Google · BSD-3-Clause

The Rust VMM that ChromeOS uses to run its Linux (Crostini) and Android (ARCVM) guests, and which the project describes as now used across multiple products and platforms — Android's Terminal app, Cuttlefish and Windows. It supports several hypervisor backends, including the vendor hypervisors used as backends of Android's virtualization framework: Qualcomm's Gunyah, MediaTek's GenieZone and Samsung's Halla. Each virtual device can run in its own jailed process with per-device seccomp filters via Minijail, and the security-first design is documented rather than implied. Broadest device support of the three.

The adoption signal, stated carefully: being the shipped VMM inside ChromeOS and Android is real evidence that the VMM is exercised under adversarial conditions across many products, and it is why crosvm belongs in this chapter at all. It is not a security guarantee, and it is not evidence that crosvm is an easy drop-in agent sandbox. "Used by ChromeOS" tells you about the quality of a device model that other people wired into products; it tells you nothing about your afternoon, because crosvm is a low-level VMM with a Chromium-shaped build process, a read-only GitHub mirror whose contributions go through Chromium Gerrit, and no turnkey OCI or desktop workflow. If you want a microVM you can drive today, the tooling on top of a VMM is the part you actually adopt.

But: weaker IPC and hotplug than Cloud Hypervisor; snapshot/restore exists but the project's own documentation calls it "a highly experimental feature currently under development", "100% not supported", limited to a very limited set of devices, with a snapshot format that is explicitly not stable; and directory sharing is the awkward part — microvm.nix marks crosvm's 9p shares as broken and its virtiofs shares as unsupported, so on that platform you share data as block volumes. It wins in embedded and platform integration, not in developer laptops. github.com/google/crosvm

libkrun

GOOD, BUT TEST IT FIRST Red Hat

"Process isolation as a library": link libkrun.so, call a C API, get a microVM with a bundled guest kernel and no daemon. That embeddability is why so much of the new agent tooling is built on it — podman --runtime krun, krunkit with GPU support, SmolVM, BoxLite and Microsandbox all sit on it.

But: the study measured no engine-side seccomp at all (seccomp mode-0 across every thread) and 11 of 14 reachable host primitives, and it contains a fork in several of those products. Practitioner reports mention TSI bypassing nftables, always starting as root regardless of the Dockerfile's USER, and a virtio-fs readdir path that could OOM-kill small guests.

Kata Containers

GOOD, BUT TEST IT FIRST OpenInfra

OCI-compatible containers that each get their own VM, which means every tool that speaks containers suddenly gets a hypervisor boundary. In production at IBM Cloud across ~400 nodes and 10,000+ vCPUs, and the basis of Northflank's and Microsoft's managed sandboxes.

But: it is infrastructure, not a laptop tool. Installation is a privileged DaemonSet that restarts the container runtime and bounces every pod. You have to keep a host kernel, a VMM, a runtime shim, a guest kernel and the in-guest agent mutually compatible, and host kernel updates can force lockstep upgrades. One operational study measured 3.4× more on-call pages than plain containerd, and practitioner estimates for time-to-first-production-workload run to two to four months.

Hyperlight and NanVix

EXPERIMENTAL / EARLY Microsoft

Hyperlight is a hypervisor for function-shaped code — no guest OS, microsecond entry — and NanVix is a purpose-built VM and OS with the same shape. Both are Microsoft Research projects, both are wired into MXC as its microVM backends, and both are a real answer to "I want a hardware boundary but my unit of work is a function, not a machine". Neither is what you want if your agent needs a shell.

Application kernels: the middle path

gVisor deserves its own explanation because it is so often mislabelled as a microVM, and because it is arguably the best-evidenced security product in the guide.

Instead of virtualising hardware or sharing the kernel wholesale, gVisor interposes a user-space Linux implementation — called the Sentry — between the workload and the host. Your program's syscalls go to Go code, which decides what to do about them, and a tight seccomp filter limits what the Sentry itself can ask the real kernel. There is no second kernel and no hypervisor; there is a reimplementation of the kernel interface.

The measured record is strong: the fewest reachable host primitives of any product in the independent study, four hardening layers applied by default, no escape-class CVEs in the window, the only continuous public fuzzing dashboard, and a silent-fix-first disclosure model that delivers fixes before the CVE exists. It runs at enormous scale in Google Cloud Run, Cloud Functions and App Engine.

The cost is compatibility, and it is not theoretical. io_uring is disabled by default and deliberately so — it "bypassed the seccomp gate entirely for async work", which is why Android, ChromeOS and gVisor all restrict it. Unimplemented syscalls return ENOSYS and the failure looks like a broken application rather than a sandbox limitation. One audit found roughly half of tested MCP servers would not start under it. A production migration at one large company hit a 500× virtual-memory-area explosion and an ELF-loader bug before tuning. Real deployments report 10–30% syscall-heavy overhead, with I/O-heavy paths worse.

Use gVisor when You are on a Linux host, you cannot or will not run a hypervisor per workload, and you have verified that your toolchain works under it. It is also the right answer on VPSs where nested virtualisation is unavailable and microVMs therefore cannot boot at all.

Do not use gVisor when Your workload needs io_uring, exotic ioctl paths, GPU access, kernel introspection, or performance profiling tools. Also skip it if your toolchain includes binaries you cannot test — because the failure mode is a mysterious crash, not a clear error message.

Test it properly Run your real agent's full command sequence under runsc before you commit, not a hello world. The relevant failures only appear on particular binaries: a debugger, a native module, a database client, an image library.

The agent-specific microVM projects

These are the projects trying to hand you the four things you must assemble, usually with branching and snapshots added because agents want disposable copies.

Project	Engine	What it promises	The catch
Microsandbox	forked libkrun	Local microVMs with branching, snapshots, OCI images, SDKs in four languages, no daemon, allowlisted networking.	Explicitly beta. Documented boot failures on AMD Windows hardware, snapshot-integrity breaks, a virtio-fs leak under npm loads, and a 2026 CVE where secrets passed on the command line were readable via `/proc`. Needs KVM, so it is unusable on most VPSs.
Microsoft Quicksand	QEMU	An async Python API for agent VMs with network isolated by default, explicit mounts, checkpoint/revert, persistent saves, multiple Linux users, and desktop VMs with screenshot and input control.	Fifty-two stars and a young project, so the ecosystem evidence is thin even though the engineering signals (MIT, security policy, CI, tests) are good.
Docker Sandboxes	Docker's own VMM	A microVM per agent with a private Docker daemon, a host-side credential proxy, and network policy presets. Works with the big agent CLIs out of the box.	Closed source, early access, an immature licence story, and a fast-moving issue tracker — including Copilot auth breakage, daemon hangs, and Windows setups failing without nested virtualisation. macOS requires Apple Silicon.
BoxLite OSS	embedded libkrun (KVM · Hypervisor.framework)	BoxLite OSS is a local KVM/Hypervisor.framework microVM runtime that runs OCI workloads inside a VM: you embed it as a library (Python, Node.js, Go, Rust, C) or run the `boxlite` binary, any Docker image runs unchanged, and each box gets a Linux kernel of its own through libkrun — with no daemon and no root requirement. It is not a container-only backend: the container runs inside the guest kernel, and the outer boundary is the hypervisor. Persistent boxes with a per-box QCOW2 copy-on-write disk, clone/branch from a snapshot, `allow_net` egress allowlisting, environment sanitisation, and placeholder-based secret injection in which the real value never enters the guest. Its architecture document also describes a Firecracker-style "jailer" around the VMM process (seccomp BPF, namespace and `pivot_root` isolation, privilege dropping, cgroups v2; `sandbox-exec` on macOS) — a design claim from its own documentation, not an independent measurement. Agent frameworks name it as an available sandbox backend (Databricks' Omnigent, Alibaba's AgentScope Runtime and ByteDance's deer-flow), which shows integration work happened; it is not evidence of production use, scale or security outcomes.	Its own documentation sets the boundaries: Linux needs `/dev/kvm`; macOS is Apple Silicon (Intel is "coming soon"); Windows is supported only through WSL2 with KVM and the user in the `kvm` group — native Windows is explicitly not supported. On this machine the Python SDK installed and imported, then refused to start with "unsupported: KVM is not available on this host", which is the documented prerequisite being enforced (see Field Notes). Its own FAQ answers "is it production-ready?" with "yes, stable and used in production" — that is the vendor's claim, and the guide has no independent measurement to support or contradict it, because BoxLite is not in the comparative security study. What is checkable: a repository created in December 2025, still moving quickly, no independent security review, and ecosystem integrations that are statements by the consuming projects. Treat it as a promising runtime to evaluate, with the isolation documented rather than proven. github.com/boxlite-ai/boxlite
SmolVM / K7	libkrun / Kubernetes-shaped	Embeddable or self-hosted microVM sandboxes with snapshots, branching, or a cluster API.	Both young, with star counts driven by launch attention rather than years of use. Note also that two unrelated projects share the SmolVM name and both install a `smolvm` binary — `smol-machines/smolvm` (libkrun-only Rust CLI) and `CelestoAI/SmolVM` (Python, Firecracker/QEMU/libkrun) — so issues and benchmarks get conflated across them. Fine to prototype with; not things to make your architecture depend on.
Gondolin	QEMU (+ experimental libkrun)	Local microVMs driven by a TypeScript policy layer, with a written security design that states its own trust assumptions.	Experimental, a few thousand stars, and the last substantive commit is months old at the time of writing.
Buildkite Cleanroom	microVM	Deny-by-default egress plus a credential proxy, which is exactly the right shape.	Sixty-seven stars. Worth reading for the design, not worth depending on yet.

Should you use one?

Choose a microVM when

You are on Linux with /dev/kvm available.
You need per-workload kernels for untrusted or multi-tenant code.
You want container-like start times with a hypervisor boundary.
You are willing to build a kernel, a rootfs and a snapshot pool — or adopt a project that does it for you and accept its maturity level.

Choose something else when

You have no KVM. MicroVMs will not boot, and no amount of configuration fixes that.
You need a bind-mounted working directory and you picked a VMM without virtio-fs.
You need a GPU, snapshot-free simplicity, or Windows guests.
You want one answer for Windows, macOS and Linux — that answer is a normal VM, which the next chapter covers.

The pragmatic staging Start with rootless containers. When you find yourself wanting a real boundary on Linux, Cloud Hypervisor is the VMM with the best combination of features and security response, Firecracker is the one with the smallest device model, and Kata is how you get either of them under an existing container workflow. If you would rather not assemble that stack yourself, BoxLite OSS and Microsandbox are the agent-facing runtimes that wrap an OCI-image workflow and a per-box kernel in a library — treat both as accelerators for prototyping, and keep the ability to swap them out.