MicroVM vs Container vs gVisor: Which Isolation Should AI Agents Run In?

Short answer: a container isolates processes but shares the host's kernel. gVisor puts a user-space kernel between the container and the host, so most system calls never reach the real kernel. A microVM (Firecracker, Kata Containers, Cloud Hypervisor) gives each workload its own kernel behind hardware virtualization. For AI agents running untrusted or self-written code, microVMs are the default choice, gVisor is a strong alternative when you need container ergonomics or GPUs, and plain containers are for code you already trust.

This matters more for agents than for normal software. A web server runs code you wrote. An agent runs code it wrote, often after reading instructions from a web page you've never seen.

At a glance

Containers: fast, familiar, shared kernel

A container is just processes with blinders on. Linux namespaces give them their own view of the filesystem, network and process list. cgroups cap their CPU and memory. seccomp filters can block dangerous system calls. Docker and Podman package all of that nicely.

The catch is that every container on a host shares one kernel. The Linux kernel is huge, and a single exploitable bug in it can let code inside a container reach the host and every other container. For your own trusted services that risk is often acceptable. For code an AI agent just wrote, or downloaded from a stranger's repository, it's a thin wall.

Use containers when: the code is trusted, you control the image, and you want maximum speed and compatibility.

gVisor: a kernel in the middle

gVisor, released by Google in 2018, is an "application kernel" written in Go. It implements the Linux system call interface itself. When code in a gVisor sandbox makes a system call, gVisor handles it, and only a small, filtered set of operations ever reaches the host kernel. It plugs in as a container runtime called runsc, so it works with Docker and Kubernetes.

The benefit is a much smaller attack surface without leaving the container world. The costs are performance on workloads that make lots of system calls or do heavy I/O, and the occasional system call gVisor doesn't implement. Modal's sandboxes run on gVisor, with VMs as an option, and Google uses it for GKE Sandbox.

Is gVisor a microVM? No. It's a user-space kernel, not a virtual machine. It can use hardware virtualization features internally on some platforms, but each sandbox doesn't get its own guest kernel the way a microVM does.

Use gVisor when: you want much stronger isolation than containers, need Kubernetes-native tooling or GPU access, and can live with some overhead.

MicroVMs: their own kernel, almost no weight

A microVM is a real virtual machine with nearly everything removed. Firecracker, written in Rust and built by AWS for Lambda, emulates only five devices. Its documentation lists boot times under 125 milliseconds, under 5 MiB of overhead per VM, and up to 150 new microVMs per second on one host. A separate "jailer" process adds another layer of containment around the VMM itself.

Each microVM runs its own Linux kernel. Code inside can do anything it likes to that kernel and still has to get past the hypervisor to reach the host, which is a much smaller and better-studied surface. That's why most agent sandbox providers use them. E2B and Vercel Sandbox both run each sandbox as a Firecracker microVM.

Kata Containers give you microVM isolation with a container interface: each container or pod runs inside a lightweight VM, using Firecracker, Cloud Hypervisor or QEMU underneath.

The trade-offs: microVMs need hardware virtualization (KVM), which means bare-metal servers or cloud instances with nested virtualization. Firecracker was designed without GPU passthrough. And each VM boots a kernel, which costs a little memory.

Use microVMs when: the code is untrusted or agent-generated, many users share the hardware, or the agent needs a full Linux machine, including running Docker itself.

Lighter options worth knowing

Two other approaches show up in agent products:

• Process sandboxes (macOS Seatbelt, Linux Landlock, seccomp, bubblewrap) restrict a single process on your own computer. Coding agents like Codex CLI and Claude Code use them to keep the agent inside a project folder and off the network. Great on a laptop, not meant for multi-tenant servers.
• Language isolates and WebAssembly (V8 isolates as in Cloudflare Workers, Wasm runtimes) start in milliseconds and are very cheap, but they only run code written for that runtime, not arbitrary Linux programs.

Which should you choose for AI agents?

Kubernetes users should also look at the agent-sandbox project, which manages isolated, stateful agent environments in a cluster and supports runtimes like gVisor and Kata.

The part isolation doesn't solve

Here's the uncomfortable lesson of 2026. The two most-reported AI "sandbox escapes," OpenAI's in September and Google Gemini's disclosed the same month, didn't break a container, gVisor or a hypervisor. Both went out through the network: a DNS resolver that could reach the internet, and internet access left open by mistake.

So whichever isolation you pick, pair it with:

• Deny-by-default network egress, including DNS
• No secrets inside the environment, with credentials brokered from a vault
• Limits on CPU, memory, time and actions
• Monitoring that can stop a run on its own
• Approval for anything irreversible

We go deeper on those in what is an AI agent sandbox and what is an agent VM.

Sources

• Firecracker and Firecracker on GitHub
• gVisor documentation
• Kata Containers
• Vercel Sandbox documentation, Modal Sandboxes documentation
• Kubernetes agent-sandbox
• Anthropic, Making Claude Code more secure and autonomous with sandboxing (Oct. 20, 2025)
• AWS, Introducing Strands Box (Oct. 7, 2026)