MicroVM Sandboxing for AI Agent Deployment

Every Agent Gets Its Own Machine

On June 22, 2026, AWS launched Lambda MicroVMs into general availability. Each MicroVM is a Firecracker virtual machine with its own kernel, filesystem, and network namespace. No shared kernel between tenants. No shared resources between sessions. Every agent gets a dedicated sandbox that boots from a pre-built snapshot, runs for up to eight hours, suspends when idle, and resumes on the next request with its full memory and disk state intact. [1]

The specs tell the story of what changed: up to 16 vCPUs, 32 GB of memory, and 32 GB of disk per MicroVM, available on ARM64 architecture. These are not the constrained, short-lived functions that defined early serverless. They are full computing environments sized for agent workloads: code generation, multi-step tool execution, long-running research tasks, and stateful orchestration loops that need hours, not seconds. [2]

Lambda MicroVMs did not appear in a vacuum. The rise of AI agents created sudden demand for safe, disposable environments where untrusted or machine-generated code can execute without endangering anything else. Containers share the host kernel, and a kernel exploit in the container compromises the host. The OpenAI sandbox escape in July 2026 proved this was not a theoretical risk. MicroVMs solve the problem at the hardware layer: each workload runs behind a KVM virtualization boundary that is structurally impossible to cross with a syscall. [3]

The Isolation Stack Has Converged

By mid-2026, the industry converged on a three-tier isolation spectrum for agent workloads. The tiers map directly to trust levels, and mixing them up is how incidents happen.

MicroVMs (Firecracker, Kata Containers) provide the strongest isolation. Each workload gets its own guest kernel running on KVM-based hardware virtualization. A microVM boots in approximately 125 milliseconds with under 5 MiB of memory overhead, compared to 300-500 MiB for a traditional virtual machine. Firecracker was purpose-built by AWS for this use case and powers Lambda, Fargate, and now the entire Lambda MicroVM product line. For LLM-generated code executing untrusted operations, microVMs are the production-safe choice. [3]

gVisor sits in the middle tier. It implements a user-space kernel that intercepts system calls before they reach the host kernel, providing stronger isolation than containers without the overhead of a full virtual machine. The trade-off is approximately 10-20% overhead per syscall and 20-40% overhead on file I/O-heavy workloads. Google uses gVisor for its Agent Sandbox on GKE, and Modal runs its entire sandbox platform on gVisor-isolated containers. For trusted-but-isolated workloads where you wrote the code but want a safety boundary, gVisor is the right tier. [4]

V8 isolates (Cloudflare Workers, Dynamic Workers) occupy the edge tier. Each isolate starts in under 5 milliseconds and uses single-digit megabytes of memory, roughly 100 times faster and 10-100 times more memory-efficient than containers. Cloudflare runs isolates across 300 or more cities, enabling AI inference and agent orchestration at the network edge. The limitation is that V8 isolates only run JavaScript and WebAssembly, so they handle the lightweight orchestration layer while heavy compute runs elsewhere. [5]

The decision framework: microVMs for untrusted code from agents, gVisor for trusted code that still needs a blast-radius boundary, and V8 isolates for edge orchestration and lightweight inference. Most production architectures in 2026 use at least two of these tiers in combination.

Snapshot-Restore: How Cold Starts Disappeared

The original objection to microVMs was cold-start latency. A full virtual machine takes seconds to boot. Firecracker reduced that to roughly 125 milliseconds. Snapshot-restore eliminated the remaining gap.

The mechanism is straightforward: boot a microVM once to a fully initialized state, snapshot its memory and device state to storage, and restore that snapshot per request instead of booting fresh. AWS Lambda MicroVMs implement this natively. You supply a Dockerfile and a code artifact, Lambda runs the Dockerfile, initializes your application, and takes a Firecracker snapshot of the running environment. Every subsequent launch restores from that snapshot rather than booting cold. [1]

The results are dramatic. E2B's Firecracker-based runtime restores sandboxes from snapshots in 5-30 milliseconds. Blaxel resumes from standby in under 25 milliseconds with full filesystem and memory state preserved, even after weeks of inactivity. CreateOS reports 30 millisecond cold starts for hardware-isolated Firecracker microVMs. The cold-start penalty that once made microVMs impractical for interactive agent workloads no longer exists. [6]

Warm pools complement snapshot-restore for workloads that cannot tolerate even 25 milliseconds of latency. A warm pool maintains a set of pre-booted microVMs ready to accept work immediately. The trade-off is cost: warm VMs consume compute whether or not they are serving requests. The emerging best practice is a hybrid approach: a small warm pool for latency-sensitive requests plus snapshot-restore for burst traffic.

Scale-to-Zero Economics

Agent workloads follow a burst-and-idle pattern. An agent generates code, executes it, waits for model inference, executes more code, and then sits idle until the next user request. In a fleet of thousands of sandboxes, average utilization is low but peak demand is high. Keeping standard VMs running during inference windows destroys unit economics. [7]

Scale-to-zero solves this by releasing compute resources entirely when a sandbox becomes idle. The sandbox transitions to a suspended state with its memory and disk snapshotted to storage. No CPU charges. No memory charges. When the next request arrives, the snapshot restores in milliseconds and the agent picks up where it left off.

The economics shift is significant. Blaxel sandboxes automatically scale to zero after five seconds of inactivity, with zero compute cost during standby and sub-25 millisecond resume. AWS Lambda MicroVMs suspend when idle and resume on demand, with billing only during active execution. Azure Container Apps Sandboxes, launched in 2026, follow the same pattern: sub-second startup, scale to thousands, zero cost when idle. [7]

The result is that strong isolation and cost efficiency are no longer in tension. You can give every agent its own kernel, its own filesystem, and its own network namespace without paying for that isolation when the agent is thinking instead of executing.

The Platform Landscape

Multiple platforms have built entire businesses around the microVM-for-agents pattern, each with different trade-offs.

AWS Lambda MicroVMs are the native hyperscaler option. Each session gets its own Firecracker VM with up to 16 vCPUs and 32 GB of memory. Sessions persist for up to eight hours with suspend and resume. The integration with the broader AWS ecosystem (IAM, VPC, CloudWatch) makes it the default choice for teams already on AWS. The limitation is regional availability: five AWS regions at launch. [1]

E2B runs a dedicated sandbox cloud built on a proprietary Firecracker runtime with a custom memory and snapshot layer. Sandboxes boot in approximately 150 milliseconds and restore from snapshots in 5-30 milliseconds. E2B is open source at the runtime level, with SDK integrations for LangChain, LlamaIndex, and Vercel AI SDK. Production users include Manus and Perplexity. The trade-off: running E2B at scale means operating their control plane yourself if you self-host. [8]

Modal takes a different approach with gVisor-isolated containers, prioritizing startup speed and elastic GPU access over hardware-level VM isolation. Lovable ran 250,000 applications in 48 hours on Modal with over one million sandboxes and 20,000 concurrent sandboxes at peak. Quora stress-tested creation throughput to 1,000 sandboxes per second. Modal is the strongest option for workloads that need GPU access inside the sandbox. [8]

Blaxel focuses on the standby problem. Its microVM sandboxes stay in standby indefinitely with zero compute charges and resume in under 25 milliseconds. Baseten acquired Blaxel in 2026, claiming 5 times faster performance than competing sandbox products. The perpetual standby model eliminates the cost-latency trade-off that forces other platforms to choose between warm pools and cold starts. [6]

What This Means for Agent Infrastructure

MicroVM sandboxing is not just a security measure. It is an infrastructure primitive that changes how agent systems are designed.

When isolation is cheap and fast, architects stop co-locating agents. Each agent session gets its own environment with its own dependencies, its own filesystem state, and its own network policy. Credential injection happens at the proxy layer, not inside the sandbox. Teardown is deterministic: when the session ends, the VM is destroyed, and no residual state leaks between sessions.

The pattern also changes the deployment model for multi-tenant platforms. SaaS applications that let users run AI agents can now give each user's agent a hardware-isolated environment without managing a fleet of virtual machines. The platform provisions a microVM on demand, the agent executes, the microVM suspends to storage, and the platform pays nothing until the next request.

Two security realities temper the optimism. First, 2026 produced Firecracker's first two escape-class CVEs: CVE-2026-5747 (an out-of-bounds write in virtio-pci, CVSS 8.7) and CVE-2026-1386 (a jailer symlink host-write, CVSS 6.0). MicroVMs are stronger than containers, but they are not invulnerable. Defense in depth still applies: microVM isolation is one layer, not the only layer. [9]

Second, not all syscalls are perfectly emulated in gVisor, which means applications that rely on advanced kernel features like eBPF or Docker-in-Docker will break. Teams choosing their isolation tier need to test their actual workloads against the runtime's syscall compatibility, not just read the feature matrix.

The convergence is clear. MicroVMs for untrusted code, gVisor for trusted-but-isolated workloads, V8 isolates for edge orchestration. Scale-to-zero economics and snapshot-restore have eliminated the cold-start and cost objections that once made VM-level isolation impractical. The question is no longer whether to isolate agent workloads at the hardware level. It is which tier to use for which trust boundary.