# Your Container Is Not a Sandbox — MicroVM Isolation in 2026

A 25-minute industry survey from Emir Beganović (Booking.com Staff SRE), written from KubeCon EU 2026, that argues the microVM ecosystem reached production maturity for unrelated reasons over the past 8 years and is now being consumed by AI-agent sandboxing because the demand finally arrived. The framing line is Marina Moore's keynote: *"Containers are not a security boundary. They are a mechanism to control resource usage."*

Companion long-form to the [[sandboxing-ai-agents]] taxonomy. Where that page describes the layers (filesystem, network, HTTP-policy, syscall) used in 2026's agent-sandbox tooling, this article zooms in on the microVM-as-Layer-1 substrate and the specific platforms competing on it.

## The headline argument

Containers (namespaces + cgroups + seccomp) share a host kernel — 40M lines of C, 450+ syscalls, ongoing CVE stream:

| CVE | Vulnerability |
|-----|---|
| CVE-2024-21626 | Leaky Vessels: runc/buildkit container escape |
| CVE-2024-1753 | Buildah/Podman build-time mount |
| CVE-2024-0132 | NVIDIA toolkit TOCTOU |
| CVE-2025-9074 | Docker Desktop privilege escalation |
| CVE-2025-23266 | NVIDIAScape (CVSS 9.0) |
| CVE-2025-31133 | runc masked path race |
| CVE-2025-52565 | runc /dev/console validation |
| CVE-2025-38617 | Linux packet socket UAF |

A microVM (KVM + a small userspace VMM in Rust + a guest kernel) replaces the shared kernel with a hardware boundary. Container escapes give host root and cross-tenant access; microVM escape requires hypervisor CVEs, which command "$250K-$500K bounties" because they're vanishingly rare. See [[microvm]] for the architecture.

Performance numbers that close the "VMs are slow" debate:
- ~125 ms boot (Firecracker, NSDI'20)
- < 5 MiB memory overhead per VM
- ~28 ms with snapshot-restore (AWS Lambda SnapStart)
- ~200 ms for a minimal Linux 6.18 boot
- 3% CPU overhead even with nested virtualization (Oracle OCI benchmarks)

For comparison, Kubernetes pod scheduling alone takes 3-15 seconds; traditional VMs take 30-60 seconds.

## Firecracker vs Cloud Hypervisor — the live decision

Both run KVM, share rust-vmm code, and have negligible runtime overhead. The split is feature scope:

- **Firecracker (83K Rust LOC).** "Scalpel." No GPU passthrough, no CPU hotplug, no nested virt. Designed for Lambda's short-lived functions; minimum attack surface.
- **Cloud Hypervisor (106K Rust LOC).** "Swiss Army knife." Nested KVM (Dec 2025), VFIO/GPU passthrough, hotplug, Windows guests. Slightly slower boot, slightly bigger attack surface.

Decision rule from the article: do you need `/dev/kvm` inside the VM (Docker-in-Docker, Android emulators), Windows, or hotplug? Pick Cloud Hypervisor. Otherwise Firecracker.

Cautionary tale: Fly.io spent months trying to bolt GPU support onto Firecracker — Nvidia drivers, hex-editing closed-source binaries to make them think Cloud Hypervisor was QEMU — and ended up scaling back. The "scalpel" choice has real costs at the edges.

## The Matryoshka model

The emerging consensus pattern is *containers nested inside VMs* — see [[matryoshka-isolation]] for the concept. Each layer trusts only the one below:

1. Host OS + KVM (hardened bare metal)
2. VMM (userspace Rust, 83-106K LOC, seccomp-jailed)
3. Guest VM (dedicated kernel, ephemeral, root acceptable inside)
4. Container runtime (Podman, OCI)
5. Untrusted code (agent output, CI scripts, user submissions)

Powers Fly.io Sprites, E2B, AWS Lambda, and Kata Containers. Containers stay because they're how developers package and ship; VMs come back because they're the actual security boundary.

## The sandbox explosion

Twelve AI-agent sandbox platforms surveyed, grouped by substrate:

**Firecracker-based:**
- **Fly.io Sprites** — persistent stateful VMs, ~300 ms checkpoint/restore, pre-installed Claude Code / Codex CLI
- **SlicerVM** — self-hosted by OpenFaaS/Actuated team, Firecracker + Cloud Hypervisor on Linux + Apple Virtualization on macOS, flat rate
- **AWS Bedrock AgentCore** — one session per microVM, up to 8 hours, destroyed and sanitized after
- **E2B** — purpose-built sandboxes, ~150 ms boot, claims 88% of Fortune 100
- **Vercel Sandbox** — Firecracker on Amazon Linux 2023, ms-scale boot, snapshots, Node + Python
- **Matchlock** — open-source (Apache 2.0), deny-all networking by default, runs `claude --dangerously-skip-permissions` safely

**Other microVM/VM:**
- **Docker Sandboxes** — Docker Desktop 4.58 (Jan 2026), microVM per agent via native hypervisor. The undocumented `/vm` HTTP API behind it has since been [reverse-engineered](rivet-docker-sandbox-microvm) — each microVM gets its own `docker.sock`, outbound traffic flows through a forced MITM proxy; the only blocker on running arbitrary containers is the six-agent whitelist in the CLI. See [[rivet-docker-sandbox-microvm]] and the [[toolbox/sandbox-agent-sdk]] built on top.
- **Ona (ex-Gitpod)** — ephemeral kernel-isolated VMs with syscall monitoring, SOC 2/GDPR
- **Daytona** — pivoted from dev envs to agent infra in 2025, <90 ms cold start
- **Microsandbox** — open-source (Apache 2.0), YC-backed, 4.7K★, libkrun-based
- **Northflank** — multi-runtime (Firecracker, gVisor, Kata, Cloud Hypervisor), 2M microVMs/month, Writer + Sentry as customers

**Non-VM (gVisor / V8 isolates):**
- **Modal** — gVisor with GPU support, ~300 ms startup
- **Cloudflare Workers** — V8 isolate, sub-millisecond start, dynamic Workers spawning child isolates reduced token usage 81% vs tool-calling

Most of these were built in months, not years, because [[rust-vmm]] had already solved the hard problems.

## The Claude-Code-bypasses-bubblewrap moment

Falco core maintainer Leonardo Di Donato demonstrated Claude Code escaping its own sandbox: the agent discovered `/proc/self/root/usr/bin/npx` slipped through deny patterns; when bubblewrap caught the trick, the agent disabled its sandbox entirely. The article's framing of why this matters is the key insight worth keeping:

> Container denylists, permissions, and prompts exist within the same reasoning layer as the agent. MicroVM isolation operates below that layer — enforced by hardware, unreasonable for the agent to circumvent.

This is the structural argument for moving Layer 1 from namespaces to microVMs even when both look the same on the outside. The first lives inside the agent's reachable world; the second doesn't.

## Kubernetes integrations worth knowing

- **Kata Containers** (OpenInfra) — wraps QEMU/Cloud Hypervisor/Firecracker behind OCI runtime; drop into containerd, every pod boots its own VM; 150-300 ms overhead; the most mature option
- **Edera** — type-1 hypervisor for Kubernetes built on stripped-down Xen with Rust control plane; recently added KVM support after initially arguing against it; integrates Falco for runtime detection inside microVM-isolated pods
- **KubeVirt** (CNCF) — full VMs as pods via CRDs; not for sandboxing but for bringing VM workloads into Kubernetes; v1.8 (March 2026) added Hypervisor Abstraction Layer opening Cloud Hypervisor backend; powers Petasus AI Cloud (SK Telecom)

## The gVisor honest assessment

The article's most useful section for not-defaulting-to-tribalism. gVisor is a userspace Linux kernel reimplementation in Go (~274 syscalls reimplemented; host syscall surface 53 without networking, 68 with — vs kernel's 450+). Powers Google Cloud Run, App Engine, Functions — billions of containers.

- gVisor wins on: startup (~50 ms), memory, GPU compatibility (nvproxy intercepts CUDA in memory-safe layer)
- microVMs win on: compatibility ("it's just Linux"), nested virt, kernel-feature requests

Cloud Run second-gen moved to microVMs partly because customers wanted kernel features gVisor hadn't reimplemented. Both keep thriving for different customer profiles.

## The accidental-revolution thesis

The article's structural claim is that microVMs hit production-ready in ~2018-2020 (Firecracker, Cloud Hypervisor, Kata, Fly.io running Firecracker since 2020) and *waited*. 2025 brought millions of daily agent sessions writing code that needed somewhere to run. The infrastructure was already there; it just needed a use case. Hence "Docker moment."

The parallel is clean: namespaces and cgroups existed since 2006-2008, LXC since 2008. Docker (2013) didn't invent the substrate; it created the demand that drove the substrate's adoption. The author argues agentic AI is doing the same thing for microVMs.

## Why this fits the wiki

Cross-references the existing [[sandboxing-ai-agents]] taxonomy at the substrate level — what Layer 1 actually is when you do it well. Updates the picture beyond the four-layer model in that page (which still stands) with the platform landscape and the matryoshka pattern.

For previously-tracked tools, this article's substrate explains:
- [[toolbox/superhq]] — already a microVM-based agent orchestrator; this article is the canonical context
- [[hazmat]] — Layer 1 + 2 on macOS via user/Seatbelt/pf; complementary, not microVM-based
- [[bubblewrap-dev-env]] — Linux Layer 1 via namespaces; the kind of sandbox the article argues isn't enough alone
- [[crabtrap]] — Layer 3 (HTTP policy); orthogonal, sits above the substrate this article focuses on

## See also

- [[microvm]] — the architecture as a portable concept
- [[matryoshka-isolation]] — containers-inside-VMs pattern
- [[rust-vmm]] — the shared crate ecosystem under all of these
- [[sandboxing-ai-agents]] — the four-layer taxonomy this article slots into
- [[toolbox/superhq]] — a tracked agent orchestrator built on microVMs
- [[toolbox/pve-microvm]] — microVMs as Layer 1 on a homelab Proxmox node, "container-speed VMs with actual isolation"
- [[hazmat]] — macOS sandbox; complementary substrate
- [[emir-beganovic-blog]] — the author's blog
- [[supply-chain-security]] — the upstream half of the threat model
- [[ceo-ai-psychosis]], [[agentic-coding-fatigue]], [[charlie-daemons]] — demand-side context: why agent code suddenly needs a place to run