Micro-VM vs Container Isolation for Agent Sandboxing
Micro-VMs address agent threat models that containers were never designed to handle.
The tool that handles untrusted user-uploaded code has always needed strong isolation, and most teams accept that without arguing about it. Fewer teams have made the parallel connection: code an LLM generates at runtime, from a prompt it did not write and cannot fully audit, deserves the same posture. This article argues that the gap between container isolation and micro-VM isolation is not a matter of degree but a structural mismatch with the threat model agents actually present, and it lays out how to reason about which isolation tier a given agent workload requires.
The standard container threat model does not fit agents that execute LLM-generated code
Container isolation was built for a specific kind of workload: code a developer wrote, a CI/CD pipeline reviewed, and an operations team shipped with some confidence about what it would and would not do. For code a language model generated from input that may be hostile or manipulated, it does not.
The agent threat model diverges from the container threat model in three concrete ways. The agent can escape the sandbox it is already sitting inside. And indirect prompt injection, arriving through tool outputs, fetched web pages, or pasted documents, can override an agent's instructions and trigger unsafe tool use without either the developer or the model intending it. Once that injection has already succeeded, a container does nothing to limit what a command can reach.
Sandbox tiers exist to address five concrete threats: filesystem read and write outside the intended scope, network egress to arbitrary domains, exposure of the host kernel's syscall surface, cross-tenant data leakage, and secret exfiltration through environment variables or /proc. Platforms like Maritime deploy agents in per-agent micro-VMs specifically because of this pattern: if an agent is granted shell access by design, the deployment needs to guarantee it cannot escalate that access to the host kernel or to a neighboring agent's environment.
The isolation spectrum's structure and tier boundaries
Five distinct isolation tiers exist in production today, and none of them substitutes for another. Each addresses a different slice of the attack surface, so choosing the wrong one means defending against the wrong threat while leaving the real one open.
Tier 1 is the OCI container, the Docker and Podman model most teams already run. It gives you process-level separation through Linux namespaces and cgroups, and you can spin it up fast and light. Tier 2 moves to user-space kernels, with gVisor as the representative implementation. This is stronger than a plain container and lighter than a full virtual machine, but the tradeoff shows up in syscall compatibility: not every piece of Linux software runs correctly under an intercepted syscall layer.
Tier 3 is the micro-VM tier, with Firecracker and Kata Containers as the production implementations. Each workload here gets its own kernel, running on hardware virtualization through KVM, so a kernel exploit inside one VM cannot reach the host or any other VM on the same machine. Tier 4 is the library OS model, exemplified by Microsoft's LiteBox, where the application runs inside a minimal OS library that reduces the host interface to a small set of controlled primitives. It's theoretically the thinnest attack surface available, but as of early 2026 it remains experimental, with no production SDK a team could adopt today. Tier 5 is confidential computing, built on AMD SEV-SNP and Intel TDX, where memory is encrypted at the hardware level so that even the host OS and the hypervisor cannot read what's inside the sandbox. That tier matters most for regulated industries handling PII, financial records, or healthcare data, because there the threat model has to include the infrastructure operator itself.
Their finding is that no single metric settles the comparison; it's the reading across axes together, attack surface, leakage, patch cadence, that carries the analytical weight.
Firecracker's architecture and its escape surface for agent workloads
Firecracker's hardware virtualization boundary doesn't just stack another software layer on top of container namespaces. It changes the category of exploit an attacker needs to reach the host, which is a structural distinction and not a cosmetic one for agent threat models where code execution inside the sandbox is already granted by design.
Firecracker runs in user space and uses KVM to create its micro-VMs. Intel VT-x and AMD-V split host operation (VMX root mode) from guest operation (VMX non-root mode) at the processor level, and ARM's virtualization extensions do something similar through discrete Exception Levels, where EL2 is reserved for the hypervisor and EL1/EL0 for guests. Under normal operation, code running in the guest cannot directly touch host memory, host devices, or host kernel interfaces. But a container escape only has to defeat the container boundary wrapped around a kernel every guest on that host already shares.
Firecracker's minimalist VMM design supports this further. Firecracker also ships with built-in rate limiters, and you control them through its RESTful API, so you get granular control over the network and storage resources that thousands of micro-VMs draw on the same physical machine, and that matters if you're running a multi-tenant agent fleet.
None of this amounts to an absolute boundary, and the honest claim is layered risk reduction rather than impenetrability. Hypervisor-layer escapes have occurred historically, VENOM being the canonical case, and nothing rules out a comparable vulnerability surfacing again. The argument for Firecracker is that the exploit chain required to cross from guest to host becomes categorically more expensive to construct, not that the chain becomes impossible. Because each agent runs inside its own kernel with hardware-backed isolation, Firecracker eliminates the shared-kernel assumption that containers depend on: a kernel vulnerability or privilege escalation inside one agent's VM cannot cascade to the host or to a sibling agent's environment. That structural guarantee is what makes agent workloads safe to isolate at this tier.
SANDBOXESCAPEBENCH quantifies the gap between container isolation's promises and what frontier agents can do to it
The capacity of frontier models to break out of a container sandbox is no longer a question to speculate about. It's measurable, it's benchmarked, and the measured capability is scaling with model capability in ways that make container-only sandboxes a worsening match for production agent deployments.
Marchand et al. introduced SANDBOXESCAPEBENCH (arXiv:2603.02277) as an open benchmark that safely measures an LLM's ability to break out of Docker and OCI container sandboxes. Container sandbox encapsulation cannot be assumed to hold against an agent that is capable and motivated, which is precisely the agent most production deployments are now running.
What matters for teams currently relying on Docker-based sandboxes for agent execution is the framing SANDBOXESCAPEBENCH makes explicit: in an agentic deployment, code execution inside the container is granted by design. Adversarial improvement of offensive capability can happen cheaply and quickly, independent of any particular model provider's release schedule. The bar an isolation layer needs to clear keeps rising whether or not a team has changed anything about its own deployment.
Micro-VM boot latency is no longer a valid objection to VM-per-agent deployment
The objection that micro-VMs are too slow for an agent's inner loop was a fair one when cold boot was the only available path. Snapshot-restore turns that objection into a category error: restoring a micro-VM from a snapshot means resuming a process from a saved memory and CPU state, a mechanically different operation with a mechanically different cost.
When Firecracker restores from a snapshot, it does not boot a kernel and it does not start the agent from scratch. It memory-maps the snapshot file, loads the saved CPU state, and resumes execution right where that state left off, and that behaves more like a process fork than like starting a virtual machine. One practitioner demonstrated snapshot-restore running at roughly 28 milliseconds per subsequent spawn, against roughly one second for a cold boot, and that gap is precisely what made VMs feel incompatible with agent latency requirements. SmolVM, published April 21, 2026 under Apache 2.0 by Aniket Maurya and the Celesto AI team, reports roughly 500 milliseconds for a cold boot of a fully isolated Firecracker-backed micro-VM on an AMD Ryzen 7 7800X3D, putting that cold-boot figure in the same order of magnitude as a Docker container start.
Snapshot-restore also opens a working pattern that container-only deployments can't offer as cleanly: copy-on-write fork as an agent primitive. A team can boot a VM once, freeze it, and branch from that frozen state per request, trying several fixes from the same starting point and keeping whichever one passes, without paying the full boot cost for each branch attempted. Andronchik and Lokhmakov's study identifies product pin policy, not engine-side boot speed, as the dominant operator-facing variable affecting patch latency, which signals that the performance conversation in this space has already moved past cold boot and onto patch discipline as the thing worth scrutinizing.
Snapshot-restore scheduling and the economics of per-user VM-isolated agents at scale
Snapshot-restore doesn't only solve the latency problem. It restructures the cost model underneath agent deployment entirely, because an idle agent that can be snapshotted releases its compute allocation completely and pays only for storage while it waits. That shift changes per-user VM isolation from a cost most teams would consider prohibitive to one that's straightforwardly viable.
Most agents spend most of their time idle. If a container-based deployment keeps agents warm to avoid restart latency, it pays for that idle compute continuously, whether or not the agent is doing anything. A snapshot-restore scheduler converts idle time from a compute cost into a storage cost instead. The scheduling pattern works like this: an in-VM wrapper detects idleness and signals the controller that it's safe to snapshot, the controller snapshots the VM and releases its compute resources, and the agent resumes from that snapshot on the next incoming request. Wake latency becomes the restore time instead, and that runs sub-second, not a cold-boot delay or a pod-scheduling wait.
Each user's agent can live in its own isolated VM, persist its files, credentials, memory, and open sessions, and pay for storage between sessions, which is what makes the per-user agent model economically sane. The DeltaBox preprint (Dong et al., Shanghai Jiao Tong University, arXiv:2605.22781) demonstrates that stateful agent sandboxes can checkpoint and roll back at millisecond-level granularity, which confirms this pattern as architecturally general rather than a one-off trick, directly supporting the same multi-branch exploration this section describes. Maritime's flat-rate, storage-at-idle model is one concrete implementation of this principle: the isolation tier a team picks should work with idle-cost optimization from the start, not get bolted on after the fact.
Reasoning about which isolation tier a specific agent workload requires
Isolation tier selection is a function of four things: the trust level of the code being executed, the tenancy model the product runs under, any compliance requirements attached to the data involved, and the origin of that code. It is not a binary choice between container and VM, and it does not have the same answer for every agent deployment a team might build.
The reasoning starts with trust level. If internally authored code has passed through CI/CD review, you can still defend it inside ordinary container isolation, because the threat model containers were built for still applies. LLM-generated code that installs packages, gets shell access, or writes to the filesystem, along with any code supplied directly by a user, should be treated as hostile by default, and a micro-VM with a hardware virtualization boundary is the tier that actually matches that threat.
Tenancy adds a second axis to the same decision. Multi-tenant SaaS products and compliance-sensitive deployments are a different matter: the micro-VM has become the industry standard for cross-tenant isolation, because container namespace isolation was never designed to hold up against that particular threat class. Andronchik and Lokhmakov's point about engine classes separating cleanly on every architectural axis applies directly here, and the cross-axis reading, attack surface, CVE history, patch cadence, stackability together, should drive the decision over any single number in isolation.
Two threats sit outside what any isolation tier can fix on its own. Network egress remains a live risk in any tier that allows outbound connections, since sandboxing shrinks the blast radius of a compromise without eliminating the possibility of exfiltration, so egress controls like an outbound proxy, domain allowlists, and a kill switch need to operate alongside the isolation tier. Prompt injection sits outside any sandbox's scope entirely, because a compromised system prompt reaches the model before the sandbox ever gets involved; the sandbox limits what an injected command can accomplish once issued, but input validation, tool call allowlists, and output auditing have to function as separate, necessary layers of their own. And Andronchik and Lokhmakov's finding on product pin policy deserves weight here too: engine-side patch latency converges near zero for coordinated disclosures, but downstream lag across products can run from zero days to 471 or more, or become opaque, or never resolve. Choosing an isolation primitive with strong upstream patch discipline matters as much as choosing the right tier. For teams building per-user agent products at scale, the constraint is economic as well as architectural: the tier chosen needs to be compatible with idle-cost optimization, and a micro-VM paired with snapshot-restore scheduling is one of the few configurations that satisfies the security requirement and the cost requirement at the same time. None of this is a decision made once and left alone. Teams routinely start with a higher-overhead isolation tier than they'll eventually need and optimize downward as real utilization patterns become visible, and at the outset you just need to make that first choice deliberately, with the threat model stated outright, instead of defaulting to containers because containers are the tool already sitting on hand.
