VM Isolation vs Container Isolation for AI Agent Security

An agent that writes a Python script, installs a dependency it decided it needed, and calls a shell command, all inside a single turn, is running code that no human reviewed before it executed. That single fact separates AI agent workloads from the class of software containers were built to isolate, and it is a difference in kind, not degree.

Containers are not designed for the threat model that AI agents create

A conventional web service runs code that a platform team wrote, reviewed, and shipped. The threat model for that service points outward: the danger is an attacker probing the service from the network, not the code running inside the container, which the team already trusts. An AI agent flips that arrangement. The code itself is the unknown quantity, generated at runtime from a prompt, and recent evaluations report 13% success rates on exploiting real-world web application vulnerabilities, so that unknown is a live operational risk, not a theoretical one.

Three factors stack on top of each other to make this worse inside a shared container host. Agents turn natural language into executable code, so a prompt-injected instruction buried in a document or a web page an agent reads can become a shell command the agent runs. Agents call tools and install packages on their own, and no human approves each step, so the attack surface grows with every turn of the conversation instead of staying fixed at deploy time. On a multi-tenant platform, many agents share the same host, so when one escape succeeds, it does not stay contained to one customer's workload. It reaches every tenant on that host at once.

Container escape guidance published in January 2026 states this directly: for single-tenant, trusted-code environments, containers provide adequate isolation, but the calculus changes once untrusted code from multiple tenants enters the picture. AI agent platforms are exactly that scenario: they run code nobody wrote and nobody reviewed, for however many customers share the same physical machine.

How container isolation works

Container isolation rests on three Linux kernel mechanisms, and all three run inside one shared kernel. That single fact is the entire story: the isolation boundary is software, enforced by the kernel itself, not a hardware wall between workloads.

Namespaces give each container its own view of process IDs, network interfaces, and filesystem mounts, but the kernel that maintains those separate views is the same kernel serving every other container on the box. Cgroups cap how much CPU, memory, and I/O a container can consume, which stops one workload from starving its neighbors of resources, but a cgroup limit has nothing to do with whether a process can escape its container. Capabilities break root's full set of privileges into smaller named units a container can hold or drop, so a compromised process can do less, but it still reaches the kernel's code.

Put those three together: a kernel vulnerability reachable from inside one container is reachable from the host and from every other container on that host, because nothing hardware stands between them. NIST SP 800-190 makes the comparison directly, stating that containers "do not offer as clear and concrete of a security boundary as a VM." Agent platforms run into a specific version of this problem when an agent needs to launch its own execution environment inside a container, a pattern people commonly call Docker-in-Docker. Doing that safely usually requires running the outer container in --privileged mode, which gives the container most of the host's privileges back.

The surface being defended is not small. The Linux x86-64 syscall table runs to several hundred entries, and every container on a shared host can probe all of it. A micro-VM changes what sits on the other side of that probe.

What a kernel boundary enforced by hardware virtualization prevents

A micro-VM draws its isolation line somewhere else entirely: through hardware virtualization, using Intel VT-x or AMD-V by way of the KVM interface. Code running inside the guest, including code an agent wrote a second ago, reaches the guest kernel and stops there. It never touches the host kernel directly.

Breaking out of that boundary means exploiting a bug in the hypervisor, the virtual machine monitor, or the virtualized device model itself, a target that is far smaller than the full Linux syscall surface a container exposes. Firecracker, the micro-VM technology originally built at AWS, is designed around keeping that target small on purpose. A conventional VM monitor like QEMU emulates a full hardware environment, including USB controllers, PCI buses, and sound cards, and every one of those emulated devices is a piece of code an attacker could try to exploit. Firecracker keeps only the handful of devices Linux needs so it can boot and run. Its codebase runs to roughly 100,000 lines of Rust, a small fraction of QEMU's footprint, and when the trusted computing base is smaller, an attacker simply has fewer places to look for a bug. Two Firecracker guests share no kernel code paths at all, so a kernel-level compromise inside one agent's sandbox has no lateral path into another agent's sandbox on the same host.

The container escape record shows why that boundary matters in practice, not just in theory. CVE-2024-21626 and CVE-2022-0185 both produced real host access starting from inside a container. More recently, another round of container-runtime disclosures allowed container escape through write access to critical host kernel interfaces. No single one of these is the point. This category of vulnerability keeps producing new entries, year after year, because the shared kernel keeps offering the same kind of target.

A coding-agent constraints paper from the 2026 ICML workshop frames the underlying logic well: hardware-isolated VMs, filtered network egress, and an inference proxy that intercepts traffic enforce a baseline that no instruction at the prompt level can grant or take away. Where this architecture gets deployed, a single compromised agent cannot move sideways into another tenant's workload, because there is no shared kernel path for it to move through. That is the specific problem Maritime's architecture is built to close: each agent gets its own Firecracker micro-VM, so a breach of one guest kernel has nowhere to spread.

The performance case against micro-VMs

The standard objection to micro-VMs is that they are too slow for an interactive agent session, and the comparison usually offered to prove it measures cold boots that do not resemble how production agent infrastructure actually runs.

The raw boot numbers are closer than the objection assumes. Firecracker's published specification puts userspace boot at 125ms or less, with a 99th-percentile boot of 146ms measured across 1,000 concurrent micro-VMs in the NSDI 2020 paper. Docker's cold-start numbers, when they include pulling the image, are dominated by image distribution rather than by the isolation mechanism itself. A USENIX FAST study found that pulling the image accounts for more than three-quarters of total container startup time. Strip that out and compare warm starts with pre-pulled images and caches already loaded: Docker on Azure Premium SSD measured 554 to 568ms for Alpine and Python images, a number higher than Firecracker's published boot figure.

None of that is the number that matters for an agent workload. Agents run multi-turn sessions, and the first boot is not the one that counts. A hypervisor can snapshot a running micro-VM's memory and device state once, then restore from that snapshot on every subsequent session, so only the first session ever pays the boot cost. Docker has no equivalent production-grade primitive for this. Experimental CRIU checkpoint support exists, but it does not match what a hypervisor memory snapshot does, restoring memory and processes in milliseconds using copy-on-write semantics. The resume gap that remains for micro-VMs, measured at roughly 179ms at the median on a modern workstation, adds up across a long multi-turn session, but the snapshot-and-fork pattern pushes the effective cost of creating a new VM toward zero for every session after the first.

What matters is not whether micro-VMs are fast enough, but whether they are affordable at the scale an agent platform needs.

The economics of running one micro-VM per user

One idea makes per-user micro-VMs economically workable rather than just architecturally clean: most agents sit idle most of the time, and if an idle VM only costs money for the storage holding its snapshot, not for compute, the whole cost structure flips.

A published analysis of AWS Lambda MicroVMs at tenant scale puts a number on that flip: a suspended VM running on-demand costs 93.8% less than the same VM kept always-on. That is the size of saving that turns a per-user VM fleet from an elegant idea into a workable budget line. A thousand dormant tenants add up to a modest monthly storage bill, which is what "near-zero idle cost" means once real units get attached to it. If a tenth of those thousand tenants happen to be active at the same moment, the fleet only runs that fraction of VMs an always-on design would have required, and the bill scales with that same fraction. The ratio holds whether the fleet has a hundred tenants or a hundred thousand.

A September 2026 survey of agent sandbox providers found that per-slot pricing across the market has converged near a common floor, that snapshots are the one part of the stack that comes close to free, and that the math between renting capacity and owning it flips once utilization crosses a fairly low threshold. A separate arxiv analysis of agentic serving systems surfaced a real tension inside snapshot management: tearing a tool sandbox down after every single tool call cuts its per-call cost, but doing that repeatedly, with a fresh snapshot created and restored each time, pushes total customer cost to several times the persistent baseline. The better design is a persistent VM that sleeps between turns, not one rebuilt from scratch on every turn.

This does not remove the multi-tenancy risk. If tenant confinement is enforced only inside the VM, for instance through a shared root sidecar, root-level code execution can still bypass it. Enforce tenant separation on the storage side instead, with one access point and one IAM role per tenant, and you survive that failure mode, but cold-start time comes back into the picture, a real architectural tradeoff, not a settled, solved problem. What makes the whole model legible to a product team that does not think in infrastructure terms is simpler than any of that: the bill tracks concurrency, not headcount. A fleet of thousands of tenants costs the same as a fleet of a few hundred, as long as only a few hundred are active at any given moment.

Where gVisor fits

gVisor sits in a real middle position between a bare container and a full micro-VM. It interposes a user-space kernel between agent code and the host, intercepting syscalls before they reach the real Linux kernel, which meaningfully shrinks the kernel attack surface without the provisioning overhead a full micro-VM carries.

That makes it a reasonable choice on multi-tenant container platforms where the risk of a kernel escape is real but the extra latency of provisioning a micro-VM for every workload is not acceptable, a pattern reportedly used inside Google Cloud Run sandboxes. It does not close the gap containers leave open. A bug in gVisor's user-space kernel still has a path to the host, where a bug in a Firecracker guest kernel does not reach the host unless it also finds a way through the VMM. One 2026 sandbox implementation described in an arxiv preprint made this tradeoff explicit, running two runtimes behind a single egress gate: containers when both the user and the agent need GPU access, and a VM when full isolation is the requirement, treating the container path as the weaker boundary used only when GPU passthrough makes the VM path impractical. AI agent sandboxing guidance published in May 2026 organizes the choice the same way, as a tier decision: gVisor where reducing kernel surface matters but hardware isolation isn't mandatory, micro-VM wherever the workload involves compliance-sensitive multi-tenancy or untrusted code execution.

Firecracker's small trusted computing base and its per-agent isolation model shrink the attack surface down to what each agent can reach, rather than merely reducing the number of exposed syscalls. Infrastructure platforms including Maritime build on micro-VM isolation as the default for agent workloads because the hypervisor boundary is enforced in hardware, not negotiated through kernel policy. The isolation tier a workload needs is determined by who wrote the code running inside it. Code a platform team wrote and reviewed can live safely in a container or behind gVisor. Code an agent generated on the fly, from a prompt, with no human review, belongs behind a hardware boundary.

AWS Lambda MicroVMs as a signal that the industry has settled on Firecracker for agent workloads

AWS shipped Lambda MicroVMs on June 22, 2026, a stateful serverless primitive that gives every session its own dedicated Firecracker micro-VM, suspends and resumes that VM with memory and disk intact for up to eight hours, and charges zero compute cost while it sleeps, aside from the storage cost of keeping its snapshot around. At launch, a session could run for multiple hours, with tens of gigabytes of memory and disk and multiple vCPUs available to it, and startup worked from a Firecracker snapshot of a pre-initialized environment rather than from a cold boot.

AWS described the use case without hedging in its launch copy, calling Lambda MicroVMs "a new serverless compute primitive within AWS Lambda that lets you run code generated by users or AI in isolated, stateful execution environments." Amazon Bedrock AgentCore Runtime runs the same pattern under its own name: one session maps to one Firecracker micro-VM, used to run agent tools like Code Interpreter and Browser inside their own isolated environment. None of this is an untested idea. Firecracker already runs AWS Lambda and AWS Fargate at more than 15 trillion monthly Lambda invocations, a scale that puts its reliability and performance profile well past the theoretical.

When the largest cloud provider in the world ships a named primitive built on Firecracker and states the isolation rationale outright in its own launch documentation, the architectural debate between containers and VMs for agent workloads has effectively been settled at the infrastructure layer. What is left for a developer or a platform team to decide is not whether to use a hardware-enforced boundary for agent-generated code, but which platform to build that boundary on.