Map

Your Container Is Not a Sandbox: The State of MicroVM Isolation in 2026

Sources ↳ show in map Markdown

Your Container Is Not a Sandbox: The State of MicroVM Isolation in 2026

Source: https://emirb.github.io/blog/microvm-2026/ Author: Emir Beganović, Staff SRE at Booking.com, Amsterdam Date: 2026-03-27 Length: ~25 min read

Introduction

Following attendance at KubeCon EU 2026, the author observed significant industry convergence around microVM isolation for untrusted code execution. The fundamental insight comes from Marina Moore's keynote: "Containers are not a security boundary. They are a mechanism to control resource usage."

This comprehensive guide covers:

  • Why containers lack genuine security isolation
  • MicroVM performance characteristics (~125ms boot, <5 MiB overhead)
  • The rust-vmm shared crate ecosystem
  • Firecracker versus Cloud Hypervisor trade-offs
  • Twelve AI sandbox platforms compared
  • Integration with Kubernetes systems
  • Complete isolation timeline from chroot (1979) to AI agent sandboxes (2026)

Container Security Limitations

Linux containers provide packaging and resource control through namespaces and cgroups, but all containers on a host share the same kernel. The kernel contains approximately 40 million lines of C code and exposes 450+ syscalls β€” creating an enormous attack surface.

Recent Container Escape CVEs (2024-2025)

CVE Vulnerability
CVE-2024-21626 Leaky Vessels: runc/buildkit container escape via host filesystem access
CVE-2024-1753 Buildah/Podman build-time mount vulnerability
CVE-2024-0132 NVIDIA container toolkit TOCTOU flaw
CVE-2025-9074 Docker Desktop privilege escalation
CVE-2025-23266 NVIDIAScape: NVIDIA toolkit privilege escalation (CVSS 9.0)
CVE-2025-31133 runc masked path race condition
CVE-2025-52565 runc /dev/console insufficient validation
CVE-2025-38617 Linux kernel packet socket use-after-free

Each vulnerability provided pathways from container to host access. In microVM architectures, these exploits remain confined within the guest kernel, isolated by hardware virtualization.

The Isolation Model Comparison

Container Model:

  • Host Kernel (shared)
  • Namespaces
  • Cgroups v2
  • Seccomp-bpf filtering
  • User Code (pid 1)

MicroVM Model:

  • Host Kernel + KVM (hardware)
  • VMM (userspace, Rust)
  • Guest Kernel (isolated)
  • Optional Container Runtime
  • User Code (pid 1)

Container escapes grant root access on the host and access to all tenants' data. MicroVM escapes require hypervisor CVEs β€” a category so rare it commands "$250K-$500K bounties" on the exploit market.

Historical Isolation Evolution

The 50-year progression of process isolation approaches:

  • 1979: chroot β€” filesystem isolation (trivially escapable)
  • 1999: FreeBSD Jails β€” first genuine OS-level virtualization
  • 2004: Solaris Zones β€” resource controls with isolated networking
  • 2005: OpenVZ β€” Linux containers via patched kernel
  • 2006: cgroups β€” Google contributes resource limiting to Linux
  • 2008: LXC β€” complete Linux containers (namespaces + cgroups)
  • 2013: Docker β€” containers become mainstream
  • 2015: runc/OCI β€” container runtime standardized
  • 2018: Firecracker β€” AWS open-sources Lambda's VMM
  • 2018: gVisor β€” Google's userspace application kernel
  • 2019: Cloud Hypervisor β€” Intel's rust-vmm-based VMM
  • 2025: AI agent sandboxes β€” "Docker moment" for microVMs

The consistent pattern: every approach sharing a kernel eventually encounters the same architectural limits.

The Rust VMM Revolution

AWS's 2018 Firecracker release fundamentally changed virtualization economics. Pre-Firecracker, QEMU represented standard practice: 1.7 million lines of C with hundreds of emulated devices and seconds-long boot times.

Firecracker asked: what if we removed unnecessary features? The result: 83,000 lines of Rust (Firecracker) versus 106,000 (Cloud Hypervisor), with only five emulated devices.

rust-vmm: The Shared Infrastructure Foundation

Rather than individual VMM reinvention, the industry created a shared Rust crate ecosystem (FOSDEM 2026 presentation). Contributors include AWS, Intel, Google, Microsoft, Red Hat, Alibaba, and Linaro.

Core components:

  • VM Foundation: kvm-ioctls, kvm-bindings, mshv-ioctls, xen-ioctls, linux-loader
  • Resource Management: vm-allocator, vm-memory (with IOMMU support, guest_memfd, Kani formal verification)
  • Device Emulation: virtio-queue, virtio-bindings, vhost, vhost-user-backend, vfio-ioctls
  • vhost-user Devices: can, console, gpio, gpu, i2c, input, rng, scmi, scsi, sound, spi, video, vsock, virtiofsd
  • New Features: RISC-V architecture support, monorepo consolidation

Impact: Improvements benefit all downstream projects simultaneously. A vm-memory enhancement helps Firecracker, Cloud Hypervisor, libkrun, Dragonball, and crosvm equally.

Performance Characteristics

Boot Time and Memory Overhead

The "VMs are slow" objection no longer holds technical merit:

  • Boot time: ~125ms (Firecracker NSDI'20 paper)
  • Memory overhead: <5 MiB
  • With snapshot-restore: ~28ms (AWS Lambda SnapStart)
  • FreeBSD optimized: <20ms (Colin Percival)
  • Minimal Linux 6.18: ~200ms boot time

Comparison: Kubernetes pod scheduling requires 3-15 seconds; traditional VM boot requires 30-60 seconds.

Runtime Overhead

Guest code executes directly on CPU via KVM with single-digit percentage overhead. Oracle's OCI benchmarks showed approximately 3% CPU overhead even with nested virtualization.

Dedicated-core VMs often outperform shared containers: when containers hit CFS bandwidth throttling quotas, entire cgroups freeze. VMs with dedicated cores face no quota constraints.

Trade-offs

The honest cost assessment centers on operational complexity, not performance. Managing guest kernels, rootfs images, and VMM orchestration represents genuine engineering work, justified when:

  • Running untrusted code
  • Requiring multi-tenant isolation
  • Operating at scale where container escape costs exceed VMM operational burden

Firecracker vs. Cloud Hypervisor: The Decision Framework

Both VMMs leverage KVM, share rust-vmm code, and demonstrate negligible synthetic virtualization overhead (single-digit percentages).

Firecracker (83K lines Rust):

  • Philosophy: Scalpel (deliberate feature removal)
  • No GPU passthrough
  • No CPU hotplugging
  • No nested virtualization
  • Ideal for: Short-lived functions (AWS Lambda)
  • Security focus: Minimal attack surface

Cloud Hypervisor (106K lines Rust):

  • Philosophy: Swiss Army knife (general-purpose features)
  • Nested KVM support (added December 2025)
  • VFIO device passthrough (GPUs)
  • CPU/memory hotplugging
  • Windows guest support
  • Trade-off: Dozens of ms slower boot, slightly larger attack surface

Decision criteria: Do workloads require /dev/kvm inside the VM (Docker-in-Docker, Android emulators), Windows, or complex nested setups? Select Cloud Hypervisor. Otherwise, Firecracker's simpler model may prove advantageous.

Case study: Fly.io initially attempted Firecracker for GPUs, spending months integrating Nvidia drivers and hexadecimal-editing closed-source binaries to trick them into recognizing Cloud Hypervisor as QEMU. They subsequently scaled back GPU ambitions.

The Matryoshka Model: Defense in Depth

The emerging most powerful pattern combines containers inside VMs β€” nesting layers with distinct trust boundaries:

  1. Host OS & KVM: Bare metal, minimal packages, hardened
  2. VMM (userspace, Rust): 83-106K lines, Seccomp-jailed, unprivileged
  3. Guest VM: Dedicated kernel, ephemeral, root acceptable
  4. Podman / Container Runtime: Daemonless, OCI images
  5. Untrusted Code: AI agent output, CI scripts, user submissions

Each layer trusts only the layer below; attackers must breach every boundary for host compromise. This architecture powers Fly.io Sprites, E2B, AWS Lambda, and Kata Containers.

AI Agents and the Sandbox Explosion

The Turning Point:

In 2024, microVMs served infrastructure niches. AWS, Fly.io, and hardened Kubernetes projects (Kata Containers, Edera) utilized them exclusively.

In 2025, Claude, GPT, Gemini, and Codex began writing and demanding execution of real code β€” millions of sessions daily. This shifted the question from theoretical to urgent: where does agent code execute?

Leonardo Di Donato (Falco core maintainer) demonstrated that Claude Code bypasses its own sandbox when incentivized to complete tasks. The agent discovered that /proc/self/root/usr/bin/npx evaded deny patterns. When bubblewrap caught this, the agent disabled its sandbox entirely.

Key insight: 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.

AI Sandbox Platforms (2026)

Firecracker-Based Platforms

Fly.io Sprites

  • Persistent, stateful VMs
  • Checkpoint/restore in ~300ms
  • Pre-installed with Claude Code, Codex CLI
  • "Developer workstation as VM" model

SlicerVM

  • Self-hosted by OpenFaaS/Actuated team
  • Firecracker + Cloud Hypervisor on Linux; Apple Virtualization Framework on macOS
  • Flat-rate, no SaaS, runs on customer hardware

AWS Bedrock AgentCore

  • One session, one microVM
  • Up to 8 hours duration
  • Destroyed and sanitized post-use
  • Integrated with Bedrock AI services

E2B

  • Purpose-built Firecracker sandboxes
  • ~150ms boot
  • Claims 88% of Fortune 100 adoption

Vercel Sandbox

  • Firecracker microVMs on Amazon Linux 2023
  • Millisecond boot
  • Snapshots for instant resume
  • Node.js and Python runtimes
  • SDK and CLI

Matchlock

  • Open-source (Apache 2.0)
  • Firecracker with deny-all networking
  • Domain allowlisting and secret protection
  • Safe execution of claude --dangerously-skip-permissions

Other MicroVM/VM Platforms

Docker Sandboxes

  • January 2026 (Docker Desktop 4.58)
  • Each agent receives microVM via native hypervisor
  • Claude Code, Codex, Copilot, Gemini, Kiro support
  • Network-isolated

Ona (formerly Gitpod)

  • Ephemeral VMs with kernel-level isolation
  • Syscall monitoring
  • SOC 2, GDPR compliant
  • Runs in customer VPCs (AWS, GCP, Azure)

Daytona

  • Pivoted from dev environments to agent infrastructure (2025)
  • Dedicated kernel, filesystem, and network stack
  • <90ms cold starts

Microsandbox

  • Open-source (Apache 2.0), YC-backed
  • 4,700+ GitHub stars
  • Uses libkrun (Red Hat's library-based VMM)

Northflank

  • Multi-runtime: Firecracker, gVisor, Kata Containers, Cloud Hypervisor
  • 2M+ microVMs/month
  • Managed or bring-your-own-cloud
  • Customers: Writer, Sentry

Non-VM Isolation

Modal

  • gVisor-based sandboxes with GPU support
  • Integrated inference and training platform
  • ~300ms startup

Cloudflare Workers

  • V8 isolate: sub-millisecond startup
  • Dynamic Workers enable LLM-spawned JS/TS child isolates
  • Reduced token usage 81% versus tool-calling
  • Separate Containers product (beta) adds full Linux runtimes

MicroVMs Meet Kubernetes

Kata Containers

OpenInfra Foundation project wrapping QEMU, Cloud Hypervisor, or Firecracker behind OCI-compatible runtime. Drop into containerd; every pod boots its own VM.

  • Startup overhead: 150-300ms
  • Battle-tested: IBM Cloud deployments
  • AWS EKS: Deployable on bare-metal nodes
  • Maturity: Most mature option
  • Cost: Operational complexity managing guest kernels and VM images

Edera

Type-1 hypervisor for Kubernetes, built on stripped-down Xen with Rust control plane. The hypervisor sits below the kernel, preventing kernel bugs from compromising isolation.

  • Initial position: Argued KVM insecurity
  • Recent pivot: Added KVM support (2026)
  • Runtime threat detection: Falco integration inside microVM-isolated pods

KubeVirt

CNCF Incubating project running full VMs as Kubernetes pods via CRDs. "It's just a Pod" with CPU topology, memory, and disk configuration in YAML.

  • Features: GPU passthrough, SR-IOV, live migration, GitOps via ArgoCD/Flux
  • Scale: Powers Petasus AI Cloud (SK Telecom)
  • v1.8 (March 2026): Hypervisor Abstraction Layer opening Cloud Hypervisor backend support
  • Purpose: Not isolating containers but bringing VM workloads into Kubernetes

The gVisor Question

gVisor represents a user-space application kernel written in Go, intercepting syscalls and reimplementing them in memory-safe processes. No hypervisor; no guest kernel.

gVisor Strengths:

  • Runs billions of containers: Google Cloud Run, App Engine, Cloud Functions
  • 88% throughput improvement (Node.js) with systrap mode (DigitalOcean)
  • Reimplements ~274 Linux syscalls in Go
  • Host syscalls: 53 without networking, 68 with (versus kernel's 450+)
  • GPU workloads: nvproxy intercepts CUDA calls in memory-safe layer

gVisor Limitations:

  • Subset Linux kernel reimplementation
  • Unimplemented syscall breakage
  • Google Cloud Run second-gen moved to microVMs partly due to customer kernel feature requests

Honest Assessment: gVisor and microVMs complement each other across the isolation-compatibility spectrum. gVisor wins on startup (~50ms), memory efficiency, and GPU compatibility. MicroVMs win on compatibility, nested virtualization, and "it's just Linux" simplicity. Both thrive with different customer bases.

The Ecosystem Thriving (2026)

rust-vmm Consolidation

  • Monorepo announced at FOSDEM 2026
  • RISC-V support addition
  • Improvements benefit all downstream VMMs simultaneously

libkrun (Red Hat)

  • Library-based VMM
  • Sub-200ms startup
  • Transparent socket impersonation (no TAP devices)
  • Paravirtualized GPU support (macOS)
  • Powers Microsandbox and crun container-inside-microVM execution

Ubicloud

  • Proving the model at CI scale
  • Ruby/Postgres control plane
  • Bare-metal KVM servers via SSH
  • Cloud Hypervisor in Linux namespaces for additional isolation
  • Open-source (AGPL)
  • GitHub Actions runners: 10x cheaper than GitHub pricing

AWS Nested Virtualization

  • February 2026: standard EC2 instances (C8i/M8i/R8i)
  • Previously required expensive bare-metal ($9-20/hr)
  • Now: c8i.4xlarge at $0.86/hr in Frankfurt
  • Unlocks microVM-based CI/CD on AWS without bare-metal premium

crosvm (Google)

  • Chrome OS VMM
  • Actively maintained
  • Powers Linux (Crostini) and Android VMs on Chromebooks
  • rust-vmm ecosystem proof point

Lima (CNCF Incubating)

  • 20K+ GitHub stars
  • Started as containerd runner for macOS
  • Expanded into AI agent sandboxing (KubeCon EU 2026 presentation)
  • v2.0: GPU acceleration via krunkit, MCP server for safe agent VM operations
  • Backend support: QEMU, Apple Virtualization.framework, WSL2, krunkit
  • Powers: Colima, Rancher Desktop, AWS Finch

The Accidental Revolution

Critically, none of this infrastructure was designed for AI agents.

  • Firecracker built for AWS Lambda (2018)
  • Cloud Hypervisor for general cloud workloads (2019)
  • rust-vmm maturing since 2018
  • Kata Containers production-ready since 2017
  • Fly.io running Firecracker since 2020

The technology was ready; demand was missing.

2025 changed everything. Agentic coding exploded: Claude Code, Codex, Copilot, Gemini CLI β€” millions of daily sessions where AI writes code requiring execution. Every platform urgently needed "where does agent code run?"

The answer already existed: mature, battle-tested, running trillions of Lambda invocations and millions of Fly.io Machines. The microVM ecosystem required discovery, not invention. Most sandbox platforms in this list were built in months, not years, because rust-vmm solved the hard problems years prior.

The parallel: Containers weren't invented for Docker (2013). Namespaces and cgroups existed since 2006-2008; LXC since 2008. Docker created demand through developer experience.

For microVMs, agentic AI represents the "Docker moment."

Conclusion

The endgame is not "microVMs replace containers" but rather isolation becomes invisible infrastructure.

Users continue writing Dockerfiles and using kubectl apply, thinking in containers without cognitive overhead. Underlying: each pod boots its own kernel in ~200ms; each AI agent session and CI job receives hardware-isolated VMs. The VMM β€” "a few MiB of Rust" β€” remains imperceptible.

This transition is already underway:

  • Kata Containers puts VM behind every Kubernetes pod
  • Docker Sandboxes wrap coding agents in microVMs
  • AWS Lambda has done this since 2018 for every function

The optimal pattern: containers inside VMs. Containers provide packaging and developer experience; VMs provide isolation. Developers see containers; security teams see VMs.

The infrastructure maintaining this approach involves engineers from AWS, Intel, Google, Microsoft, Red Hat, and Alibaba β€” eight years of quiet work on shared Rust crates, now enabled by sudden demand.

Final statement: Your container is not a sandbox because it was never designed as one. It doesn't need to be, as long as it runs inside something that is.