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.