Firecracker MicroVM Architecture for AI Agent Workloads
Firecracker isolates AI agent code with its own kernel and boots in milliseconds.
An AI agent that executes code breaks the assumptions container security was built on, because a language model wrote that code just seconds ago, and it was responding to a prompt nobody fully controls. A traditional service only runs code that has passed through a pull request, a review, and a CI pipeline. Once an agent can execute arbitrary code, it can do anything a programmer sitting at a terminal can do, and that includes everything a programmer should never be allowed to do on infrastructure shared with other tenants.
Three threat categories follow directly from that capability surface. The third is lateral movement: an agent that reads environment variables belonging to its own session but finds a path, through a shared kernel or a misconfigured mount, to data belonging to another tenant on the same machine.
A container isolates processes with Linux namespaces and cgroups, but the host kernel is shared with every other tenant on that machine. For an agent that writes its own Python, installs arbitrary packages from PyPI, and manipulates file descriptors at runtime, the shared kernel becomes a live liability. The claim "we reviewed it first" is never true of agent-generated code, and the isolation question for agent infrastructure is not whether namespaces are configured correctly. So you have to ask whether the untrusted code gets its own kernel.
What Firecracker is
Firecracker is a virtual machine monitor, written in Rust and open-sourced by AWS in 2018, built to resolve a contradiction that had no good answer before it: containers start fast but share a kernel, and full virtual machines isolate properly but start slowly. Containers were not isolated enough for that job. AWS first ran Lambda on full virtual machines, but they booted too slowly, and they cost too much per instance for the density Lambda's economics needed.
The three-way comparison that resulted frames the entire design space agent infrastructure now inherits. Containers boot fast and carry low overhead, but they share the host OS kernel, so they can't be enough for untrusted code. Firecracker occupies the gap between them: a guest kernel of its own through KVM hardware virtualization, a boot time of roughly 125 milliseconds, about 5 MB of memory overhead per microVM, and the ability to launch up to five new microVMs per CPU core per second.
Firecracker's codebase is a small fraction of the size of QEMU, a general-purpose virtualization stack built to emulate a much wider range of hardware. Fewer lines of code supporting fewer emulated devices means fewer places for a bug to hide, and Firecracker was deliberately stripped down to the minimum needed to run a Linux guest: virtio-net, virtio-block, virtio-vsock, a serial console, and a minimal keyboard controller, five devices total. That minimalism is the constraint that pushed Maritime to build persistent agent hosting on Firecracker's foundation, so hundreds of agents can run safely on shared hardware without paying the per-instance overhead full virtualization would impose.
The scale validation behind this design is concrete: AWS states Firecracker has powered over 15 trillion monthly Lambda function invocations, stress-testing the isolation model that agent infrastructure relies on today at internet scale years before anyone applied it to running AI-generated code.
How Firecracker's four-layer security model enforces isolation
Firecracker's isolation is a stack of four independent layers, each one built on the assumption that the layer above it has already failed.
The first layer is KVM virtualization itself, enforced in hardware through Intel VT-x, AMD-V, or ARM's aarch64 virtualization extensions. The guest runs in its own virtual address space and cannot see host memory or the memory of any other VM on the same machine. This is the same isolation boundary that separates EC2 instances from each other and from the host, so an agent microVM inherits a boundary already proven at hyperscale.
The second layer is a seccomp filter applied per-thread. Even in the scenario where a guest somehow escapes the KVM boundary, seccomp stands in the way of the dangerous syscalls an attacker would need to make next.
The third layer is cgroups and namespaces governing resource consumption. A cpuset cgroup pins each microVM to specific CPU cores, which matters beyond simple fairness: moving a vCPU thread between cores causes L1 and L2 cache misses and NUMA penalties, while pinning keeps caches warm across an agent's successive turns without any intervention from the developer. A cpu cgroup caps CPU time quota, a memory cgroup caps memory usage, and PID and network namespaces isolate the process tree and the network stack from the host and from other guests.
The fourth layer is the jailer process, which handles privilege dropping. The process model reinforces all four layers structurally: each microVM is a single process on the host, with dedicated threads for the API server, one thread per vCPU, and a VMM thread, and killing that process kills the microVM cleanly, leaving no zombie state and no orphaned resources behind.
vCPU count is fixed before boot and cannot change on a running microVM, with a ceiling of 32 vCPUs. More agents means more microVMs, not bigger ones.
Why sub-second boot and snapshot-restore matter for agents
Isolation and latency pull against each other unless something resolves the tension, and for agent products, snapshot-restore is what resolves it. A cold boot at Firecracker's roughly 125-millisecond speed is fast enough for a batch job that runs once and exits. It is still too slow for the turn-by-turn responsiveness an interactive agent session demands, where a user is waiting on the other side of a chat interface for the next reply. Skipping the boot entirely through snapshotting is the answer, not a faster boot.
Hibernate-and-restore works by freezing a running machine to disk in its entirety: the working directory, installed dependencies, and running processes all persist in the frozen image. A snapshot wakes with a sub-second restore instead of a multi-second boot, and the workspace stays intact through the idle gap because it remained running the whole time, never torn down.
Parallel forks from the same snapshot extend this further: ten simultaneous forks each get their own isolated microVM without interfering with one another's state, so concurrency does not multiply setup cost.
The human-in-the-loop pattern makes the requirement concrete. Snapshot-restore is the infrastructure primitive that makes all three of those requirements tractable at once, and without it, VM-level isolation would be too slow to use for anything but background batch work.
How snapshot-restore changes per-user agent economics
An always-on virtual machine bills for a scheduled vCPU and held RAM through every idle interval, even though a long agent run spends most of its wall-clock time waiting on the language model to decide its next step.
Idle cost per tenant becomes a storage line item instead of a compute line item, and a large population of dormant tenants appears on the bill as storage, not as compute. What governs total fleet cost is the ratio of active to total tenants at any moment, not the raw number of customers signed up. That holds whether the fleet has a hundred tenants or a million.
AWS has published a reference implementation of exactly this pattern in its aws-samples repository "sample-multi-tenant-ai-agents-on-lambda-microvm," demonstrating one VM per tenant with near-zero idle cost, snapshot resume, automatic lifecycle management, and state persisted through a managed file store, which stands as concrete validation that the pattern holds at production scale. Each agent on Maritime runs inside its own Firecracker microVM on bare metal, with a persistent disk and a real kernel, and it can wake from sleep in under a second.
Where the industry has landed on agent isolation
Independent organizations building production agent infrastructure have converged on Firecracker for running agent code, and that convergence is evidence the architectural fit is structural.
AWS Lambda MicroVMs, announced June 22, 2026, added a new Lambda resource category for dedicated, Firecracker-based execution environments built to run user-supplied or AI-generated code. That is a design decision made under production pressure, not a feature added for a press release. Lambda handles the hypervisor layer but not the fleet layer: the application still has to create VMs, track endpoints, route users to the correct session, and manage webhook verification, secrets, image builds, network policy, and cleanup.
Amazon Bedrock AgentCore Runtime uses Firecracker to run agent tools, including Code Interpreter, Browser, and custom tools, under a one-session-per-microVM architecture, priced at $0.0895 per vCPU-hour in its first version and, in a second version launching by October 2026, at $0.1276 per vCPU-hour for consumption pricing or $0.0997 per vCPU-hour for a committed baseline.
SmolVM, built by a developer at Celesto AI, wraps Firecracker on Linux, QEMU on macOS, and libkrun into a single multi-backend sandbox purpose-built for agent workflows, booting a fully isolated VM in approximately 500 milliseconds on an AMD Ryzen 7 7800X3D running Ubuntu. Across all of these deployments, including Maritime's, the pattern holds: none of them reached for plain containers once the workload involved untrusted or model-generated code. The architectural convergence across independently built systems is the strongest evidence available that this isn't a stylistic preference.
Matching isolation level to agent capability surface
Not every agent needs the heaviest isolation available, so you have to ask what the agent can actually do. The isolation spectrum runs across five meaningful levels. Containers, the Docker and Podman model, share the host kernel with namespace and cgroup separation, which is fast and sufficient for trusted, internally-written code but insufficient for anything a language model generates on the fly. MicroVMs, Firecracker and Kata Containers among them, give each VM its own guest kernel through hardware virtualization, so a kernel exploit inside one VM cannot reach the host or any other VM; this is the practical gold standard for untrusted agent code today. Confidential computing, built on AMD SEV-SNP or Intel TDX, adds hardware-encrypted memory isolation so that even the host operating system and hypervisor cannot read what's inside the sandbox, a property that matters specifically for regulated industries handling PII, financial records, or healthcare data.
A practical way to place an agent on this spectrum runs across a few axes. Tenant model is another: a single-tenant internal tool carries lower risk, while a multi-tenant SaaS product where one user's agent could conceivably reach another user's data needs a hardware isolation boundary to close off lateral movement.
The hyperscaler signal across the industry is consistent on this point. AWS built Firecracker for Lambda. None of the major cloud platforms reached for plain containers once the workload became untrusted code execution; most agents trending toward real autonomy, meaning package installs, shell access, browser sessions, and open network reach, will climb to the microVM rung by design.
What persistent state requires from infrastructure
Persistent state for a running agent covers a specific set of things: files and installed packages that survive between sessions without reinstallation, credentials and environment variables loaded once at session start rather than re-injected on every invocation, and in-memory working state, open file handles, partially completed computations, live browser sessions, that a hard shutdown destroys but a resume from snapshot preserves intact.
A stateless invocation model cannot satisfy any of this. Reconstructing state on every invocation from an external store adds latency, adds complexity, and adds cost that all grow in proportion to how long the agent's session runs.
The snapshot model resolves the problem structurally. Hibernation freezes the machine rather than shutting it down, so the guest sees no reboot when it wakes. Maritime's architecture treats this as a first-class property of the platform rather than an afterthought bolted on later: each agent runs in its own isolated Firecracker microVM with a persistent disk, and the snapshot-and-restore scheduler ensures files, credentials, and memory survive both sleep and redeploy. The agent's environment is durable because the architecture was built that way from the start, not because of an engineering workaround layered on top of a stateless default.
Building agent-native products on Firecracker today
If you run Firecracker directly, you own a specific set of infrastructure problems that have nothing to do with the agent's actual logic. Fleet orchestration sits on top of all of it: tracking which VM belongs to which tenant, routing requests to the right session, and enforcing TTLs so a crashed supervisor never leaves a VM billing indefinitely. None of this touches permissions, egress controls, logging, or cleanup, all of which remain the developer's responsibility regardless of how good the isolation boundary itself is.
Maritime is built on the view that most agent developers shouldn't have to build fleet management themselves. Each agent gets its own isolated Firecracker microVM on bare metal, a persistent disk, a real kernel, package installation privileges, browser sessions, and the ability to wake from sleep in under a second, for a flat rate that works out to roughly $1 per agent per month. The primitive it exposes to developers, going from code to a live API endpoint in a single push, is the right abstraction for agent-native products precisely because the isolation argument, the economics argument, and the persistence argument made throughout this piece are all resolved at the infrastructure layer, leaving the developer to build the agent.
Choosing where to run agent microVMs still calls for a few concrete evaluations: region availability and data-residency requirements, ARM64 versus x86 dependency compatibility, snapshot storage costs weighed against active compute costs for the workload's specific duty cycle, whether session duration limits match the longest agent run the product will plausibly need, and whether fleet management, meaning VM creation, endpoint tracking, routing, and cleanup, is a problem the team actually wants to own or one better handed to infrastructure built for exactly that purpose.
