Containerized Agents vs Micro-VM Agents in Production

Production agent runtimes have converged on a common shape: a long-lived session with a persistent workspace, a shell, and a narrow action protocol between the agent loop and the machine. The isolation boundary underneath that shape, however, still defaults to containers, a decision carried over from when these were research tools run by their own authors. That default is now the wrong one for any platform where agents execute model-chosen code against untrusted input and multiple tenants share hardware. The choice between containers and micro-VMs determines whether an agent can safely persist state, execute untrusted code, and serve multiple tenants, and micro-VM isolation resolves the tradeoffs containers were never designed to handle.

What containers actually enforce and what they do not

A container is a filter and a budget on a shared kernel, not an isolation boundary. Namespaces give the process inside a private view of process IDs, mounts, and networks. Cgroups limit its resources. Seccomp restricts which syscalls it may call. But all of this is enforced by the same host kernel that every other tenant on the machine uses. The wall, such as it is, is a set of checks in one kernel, not a second machine boundary between the workload and the hardware.

The attack surface behind that kernel is large. X86-64 Linux exposes hundreds of syscalls, and the reachable surface behind them covers filesystem drivers, the network stack, the eBPF verifier, and the cgroup interface. A single flaw anywhere in that surface is a path from inside the container to the host. This is not a theoretical weakness. CVE-2024-21626, part of the Leaky Vessels disclosure, let a malicious image reach the host filesystem through runc before version 1.1.12. Three additional runc flaws disclosed in November 2025 allowed container escapes through race conditions, symlink abuse, and procfs write redirection. CVE-2025-23266 in the NVIDIA Container Toolkit is a further live example of container hardening failing at the OCI hook layer.

The blast radius of a container escape is the host kernel and every other tenant on the box. For a multi-tenant agent platform, that means one compromised session threatens all others. NIST SP 800-190 advised as early as 2017 that only containers of the same purpose, sensitivity, and threat posture should share a host kernel. The agent deployment model structurally violates that principle when multiple tenants share a host. Containers were built for a world where the code inside them was operator-authored and reviewed. That world has ended for agent workloads.

Why the agent execution model makes the shared-kernel risk concrete

The agent use case is the worst-case scenario for shared-kernel isolation. The code running inside the container is not operator-authored but model-generated, and the model's choices are shaped by whatever text it processed, including attacker-controlled text. The agent's job description is to run commands, so no jailbreak is needed. OWASP's Top 10 for Agentic Applications, published December 2025, names this risk ASI05: Unexpected Code Execution, and advises treating every execution as a stranger's script that may try to read secrets, reach the network, or leave something behind.

The threat categories this introduces follow directly from the architecture. Underlying all three is the confused deputy problem. When model-generated code runs inside shared containers, a single prompt injection attack can cascade into lateral movement, but with micro-VM isolation each agent's kernel is sandboxed from others, so privilege escalation inside one agent cannot reach another tenant's data or the host kernel itself.

How micro-VM isolation changes the blast radius

A micro-VM places a separate guest kernel behind hardware virtualization with a narrow virtual device surface. A kernel exploit inside the guest reaches only that guest. Breaking out further requires defeating the hypervisor, a surface that is orders of magnitude smaller than the host kernel's syscall table. The difference is visible in the layer stack. The container path runs from agent process to the host Linux kernel, with its 350-plus syscalls and every driver, to hardware. One hop, wide surface. The micro-VM path runs from agent process to a guest kernel, then through virtio queues, a VMM device model handling block, net, vsock, and serial, then the KVM ioctl surface, the host kernel, and hardware. More steps, each one narrower. Firecracker states boot times under 125 ms and under 5 MiB of memory overhead per microVM.

The escape blast radius comparison is decisive. A container escape compromises the host and all tenants on the box. A micro-VM escape is contained to one ephemeral guest, which was likely destroyed after the session anyway. For multi-tenant agent workloads, the micro-VM boundary is the more defensible choice.

The startup-latency objection and why snapshot-restore collapses it

The historical case against micro-VMs for agent runtimes was boot latency. Cold-starting a VM measured in seconds, and interactive agent sessions made the user see every delay. That objection was real in its time, but it is no longer a live constraint. Snapshot-restore changes the economics of creation. Boot a micro-VM to a ready state once, snapshot its memory and block device state to local NVMe, then restore subsequent sandboxes from that snapshot instead of booting from scratch. Firecracker's snapshot-restore API enables sub-30 ms sandbox creation at scale. Once creates are snapshot restores, the startup-latency advantage containers held largely disappears. What remains is only the isolation-strength differential, and micro-VMs have a decisive advantage there.

Warm pools hide any residual latency at the fleet level. For agent workloads specifically, snapshot-restore does additional work. Expensive startup costs, loading a large toolset, warming a memory index, establishing MCP server connections, are paid once at snapshot time and amortized across every subsequent cold start rather than paid at every session open.

How idle-time economics flip in favor of micro-VMs for agent fleets

Agent sessions spend most of their wall-clock time waiting on model responses. The runtime executes a command for a few seconds, then sits idle while the model processes output and writes the next action. A container holding its memory reservation while it waits is paying for RAM that is doing nothing but remembering. The standard container-fleet mitigation, reaping idle sessions aggressively, is worse than the problem. It causes agents to lose their workspace mid-task, which shows up as quality regressions rather than clean errors.

Micro-VMs can hibernate to a snapshot while waiting and restore when the next action arrives. The host then counts active concurrency rather than total retained sessions. The autoscaler can remove empty hosts, sizing for active work rather than every retained session. Copy-on-write economics make this fleet density viable. The insight that most agents are idle most of the time inverts the pricing logic. Instead of paying for idle compute across a fleet of running containers, operators pay for storage on hibernated snapshots. A cost structure like that makes per-user agent deployment viable at scale.

Maritime's snapshot-and-restore scheduler is built on exactly this model. Maritime charges $20 per machine per month as an add-on to keep a machine always-on, while hibernated machines cost nothing extra. The architecture the pricing depends on is the micro-VM's ability to hibernate and restore, which containers cannot replicate without losing warm state.

Per-user agent isolation and the multi-tenant fleet problem

The per-user agent model, one persistent agent instance per end user with its own state, credentials, and memory, is only safe at scale if the isolation between users is structural rather than policy-enforced. A shared kernel means one user's compromised session is a path to every other user's data. Multi-tenant agent fleets also introduce a quota-sharing problem. When multiple sub-agents in the same tenant run concurrently, they compete for shared rate limits. Each agent can stay within its own limit while together they use the shared limit up. The fix is a shared ledger per tenant where each agent registers a soft reservation at task start and idle agents donate unused capacity back to the pool.

The isolation requirement runs through every layer. Compute means one micro-VM per user session, never reused across users, with separate pools per tenant. Identity means tenant context propagated through all layers via a signed JWT claim, with per-tenant IAM role assumption for tool execution. Memory means user-scoped persistence. Microsoft Foundry, in public preview as of December 2025 and January 2026, introduced user-scoped persistent memory where each user's memory store is scoped to their identity via a scope parameter resolved from Microsoft Entra credentials, so agents access only the memory belonging to the authenticated principal. Observability means cost allocation and audit logs keyed by tenant identifier, so operators can attribute spend and actions per user. A micro-VM per user session is the only primitive that gives the compute layer the same structural guarantee that cryptographic scoping gives the memory layer. The isolation is not a policy that can be misconfigured. It is a hardware boundary.

What the isolation boundary determines beyond security: state, GPU access, and session forking

The isolation boundary is not only a security property. It determines what the agent can do. A micro-VM with its own kernel gives the agent package installation privileges, browser sessions, real file I/O, and the ability to break and rebuild its own environment freely, because a broken guest affects only that guest. Persistent state across sessions is a direct product of the VM model. Files, credentials, installed packages, and memory survive sleep and redeploy because the snapshot captures the full disk state. A container's volume mount approximates this but does not survive the session lifecycle the same way under a snapshot-restore scheduler. The convergence on long-lived sessions with persistent workspaces is real, but the isolation boundary underneath matters more than the abstraction on top. Agent workloads execute model-chosen code shaped by untrusted input, a threat model that requires per-agent VM isolation rather than shared-kernel namespaces.

GPU access is a meaningful differentiator at the boundary level. GVisor's user-space kernel intercepts GPU calls via ioctl passthrough, its nvproxy driver, rather than direct PCIe passthrough, and it does not support VFIO device assignment. Firecracker's hardware virtualization path does not support VFIO device passthrough to the micro-VM as of v1.16.1, with VFIO support an unmerged work-in-progress. The sandbox still gets near-native GPU performance, which matters for agents running local inference or vision workloads. Session forking, branching an agent workflow from an exact point to explore multiple execution paths, is structurally possible with micro-VMs via copy-on-write fork. Containers can only approximate it with a second container or a directory copy, each of which loses the warm in-memory state the agent had accumulated.

Where containers remain the appropriate choice and how to read the decision

The micro-VM argument is strongest where the threat model is strongest: customer-facing code interpreters with many tenants, any workload where the agent executes third-party packages or processes attacker-reachable input, and any multi-tenant platform where one user's session failure must not affect another's. Containers remain appropriate where the code is operator-authored and reviewed, the deployment is single-tenant or trusted-user-only, and operational simplicity and ecosystem familiarity outweigh the isolation requirement. A developer running an agent against their own repository on their own machine is a different threat model than a SaaS platform serving thousands of end users.

A practical tier framework follows from what the agent does. For calculations on data the user can already see, with no network, gVisor or a micro-VM with egress blocked is sufficient. For installing packages, building, or testing code, a micro-VM with egress only to internal mirrors is the right floor. For multi-tenant platforms, one sandbox per session, never reused across users, with separate pools per tenant, makes the micro-VM the minimum sensible boundary. For actions that change production systems, this is not a sandbox problem at all. Scoped tool permissions and a human approval step for irreversible actions are the answer there.

On Kubernetes, RuntimeClass lets a single cluster run standard containers for platform services and gVisor or Kata for agent workloads. The boundary choice does not have to be all-or-nothing at the infrastructure level. The SIG Apps agent-sandbox project, which reached v1.0 in August 2026, adds Sandbox, SandboxTemplate, SandboxClaim, and SandboxWarmPool resources on top of existing runtimes and leaves the isolation itself to those runtimes. Operators can adopt the orchestration layer without committing to one isolation technology. The decision criterion is not which approach is more secure in the abstract. It is what the blast radius of a session compromise is, and who bears it. When the answer is paying customers on a shared host, the micro-VM boundary is the structurally correct answer regardless of ops preference.