Firecracker MicroVM Architecture for AI Agent Workloads

The agent is not calling a fixed set of tools anymore, it is generating arbitrary code and executing it, and the infrastructure built to contain that code was designed for a different job.

Earlier agents worked from an enumerable, auditable menu: search this, query that database, send this email. The behavior surface was bounded because someone wrote every function the agent could call. Autonomous code-executing agents threw that boundary out: generating and running code as part of a task loop is Turing-complete, so the agent can do anything a programmer at a terminal can do. It can also do anything a malicious instruction tells it to do, because the model doesn't distinguish between code it wrote to solve the task and code it wrote because a prompt injection told it to. A poisoned CSV cell or a scraped web page with hidden text can produce code that reads /etc/passwd or dumps and exfiltrates environment variables, and the model emits it with the same fluency as legitimate code.

Three threat categories follow from this:

Prompt injection escape: malicious content buried in a tool's output, a web page, or a pasted document tricks the agent into running attacker-controlled code instead of the task it was actually given.

• Resource abuse: fork bombs, runaway loops, and disk exhaustion can take an entire host down without any privilege escalation.
• Prompt injection escape: malicious content buried in a tool's output, a web page, or a pasted document tricks the agent into running attacker-controlled code instead of the task it was actually given.

This is the operating condition of any agent that writes and runs its own code, and production AI coding agents make it worse: generated code often runs in a Docker container on the same host as the orchestrator, sometimes --privileged, sometimes bind-mounted to /var/run/docker.sock. That second configuration hands the container root-equivalent control over the host's own Docker daemon. It is about the worst setup available.

None of this makes containers poorly built. Containers were engineered on a reasonable assumption: the host kernel is trusted, and a container is just a Linux process wrapped in namespaces and cgroups, sharing syscalls, memory management, and scheduler with every other process on the box. That held fine for years, since code inside containers was written and reviewed by people. LLM-generated code breaks it outright: a kernel-level exploit inside a container is a full compromise of the host and everything else it runs. The industry has already seen what that looks like in practice. CVE-2019-5736 let a container overwrite the runc binary on the host, further escape vulnerabilities followed, and runc, Docker's underlying runtime, has picked up new CVEs at a steady clip since, a track record spanning years rather than an isolated incident. None of this is exotic. It's the ordinary rhythm of a widely used piece of infrastructure repeatedly discovering that its trust boundary has a hole.

Firecracker and the engineering choices behind its minimalism

Firecracker is a Virtual Machine Monitor written in Rust, and its defining feature is what it refuses to do.

Firecracker was built by AWS and released as open source in November 2018, originally developed to power Lambda and Fargate, emerging from the recognition that QEMU (the established general-purpose VMM) emulated hardware (USB controllers, displays, sound cards, PCI buses, BIOS) that serverless functions simply do not need. Firecracker's answer was to strip the device model to six things, virtio-net, virtio-balloon, virtio-block, virtio-vsock, a serial console, and a bare-bones keyboard controller, talking to the guest through optimized virtio interfaces instead of emulating real hardware.

The numbers this produces make agent infrastructure at scale plausible. Memory overhead per microVM comes in under 5 MiB. A single host can spin up as many as 150 microVMs a second. It runs on 64-bit Intel, AMD, or ARM chips with hardware virtualization support, on a Linux host with KVM and a kernel at 4.14 or newer.

It matters later when the AgentCore story comes up, so there's a second layer to understand now. Firecracker ships with a companion program, the jailer, adding cgroup isolation, namespace isolation, and a chroot to restrict filesystem visibility; Firecracker itself installs seccomp filters limiting available syscalls. That's a second boundary sitting behind the virtualization layer; it supplements the virtualization layer rather than substituting for it. Firecracker also builds in rate limiters, letting an operator running thousands of microVMs on one host cap network and storage throughput per microVM, via burst allowances or a fixed ceiling.

None of this is an accident of underinvestment. QEMU's flexibility is what makes it heavy, and Firecracker's refusal to be flexible is what makes it light. The minimalism is the whole design philosophy. Boot time initiates user-space code in approximately 125ms.

The hardware isolation boundary and its effect on the blast radius of a compromised agent

Putting the agent threat model from the first section next to the mechanism from the second makes the argument for microVMs concrete instead of abstract. A microVM doesn't just shrink the attack surface available to a compromised agent, it changes the category of exploit an attacker needs to break out, and that's a different kind of security property than anything a shared-kernel container can offer.

It helps to lay the isolation options out in order of what they actually promise. A standard Docker container gives process-level isolation on a shared kernel, so one kernel bug or one misconfiguration is enough to escape to the host. gVisor sits a step up: a user-space kernel that intercepts syscalls before they reach the real one, stronger than a bare container, weaker than a VM, with some I/O overhead, suited to compute-heavy AI workloads where full VM isolation isn't worth the cost. Firecracker microVMs go further: an attacker must break both the guest kernel and the hypervisor to reach the host, a harder path, not impossible, but a different order of difficulty than jumping a shared kernel.

A container is a polite suggestion to a shared kernel that processes behave, while a microVM gives every workload its own kernel behind a hardware boundary, KVM, a wall instead of a suggestion. For an agent that only reads text and never touches a shell or the network, a container boundary is probably fine. The moment an agent executes code, installs packages, or reaches out to the network on its own initiative, the boundary needs to match that capability, and only a microVM does.

Disposability compounds the security gain rather than sitting apart from it. The worst case inside a microVM is a wrecked, throwaway guest: its own kernel, memory, filesystem, and network namespace, gone at the run's end. The worst case inside a container is a compromised host and every other tenant's workload riding on it. Discarding the VM after each run also guarantees the same environment never sees two users' data, whereas long-lived containers tempt teams into reuse, quietly mixing trust domains inside one shared kernel. That gap is the price of a wall a single kernel exploit can't cross, and it's a fair trade for most agent workloads.

None of this should be read as a claim of absolute safety. Hypervisor escapes have existed before and a future one isn't ruled out; the honest claim is a meaningfully higher bar, not an unbreakable one, changing what an attack actually costs to pull off.

The AgentCore incident is the case that makes all of this concrete rather than theoretical. AWS AgentCore runs its sessions on Firecracker, and BeyondTrust's research did not break that compute isolation. The failure sat one layer up, in an AgentCore "Sandbox" configuration still allowing outbound DNS queries; researchers built a command-and-control channel over DNS and rode the interpreter's overly broad default IAM role to pull PII and credentials out of an S3 bucket, all over DNS. The VM boundary held. The policy layer around it didn't. MicroVM isolation is necessary but never sufficient alone: network egress controls and least-privilege IAM sit in the same stack, and skipping them leaves a door open beside an otherwise solid wall. Kata Containers offer similar hardware-level isolation, but a larger attack surface with QEMU or Cloud Hypervisor as backend, orchestrated via standard container APIs and Kubernetes, ~200ms boot, aimed at regulated and Kubernetes-native environments.

Persistent state as an agent requirement, and its break from the stateless sandbox model

Isolation solves half the problem. An agent that resets to zero after every call is safe, but it's also useless for anything longer than a single-shot request, and most of what makes agents valuable happens across many turns.

Agentic systems carry four kinds of state: perception context (how it has interpreted its environment so far), reasoning state (planned actions in progress), execution artifacts (files, packages, open sessions), and memory (accumulated context from earlier). A sandbox that wipes itself between calls forces the agent to rebuild all four from scratch every time. For a short, single-purpose tool call, that's a non-issue. For a coding agent holding a repo checkout, a running test suite, and half-finished reasoning about which file to edit next, resetting to zero on every turn is simply the wrong architecture.

What the agent needs is simple: a disk surviving between turns, real installed packages, browser or terminal sessions that stay open, and credentials not re-injected every call. The obvious fix, leaving the container running between calls, solves the state issue but reintroduces the cost issue, since a long-running container bills for every idle second waiting on model or user, and idle time is most of an agent's life.

A VM has an option a container doesn't: a machine state that can be serialized whole. The snapshot captures guest memory and device state in full, letting the host reclaim resources while the agent's execution context sits safely on disk. Snapshot-restore freezes the environment between turns rather than destroying it; the next action restores from that snapshot and resumes exactly where it left off, mid-thought if needed. This reconciles the two goals earlier sections framed as tension: isolated and disposable for security, persistent for continuity, with the snapshot as bridge.

The broader ecosystem is already building around this assumption rather than against it. OpenAI's Agents SDK, Google's Agent2Agent protocol, and Anthropic's Model Context Protocol are converging on interoperable standards with different stances on state: MCP moves toward statelessness, A2A uses opaque agents without shared memory, and OpenAI adds optional stateful infrastructure. Whichever way the protocol layer settles, the infrastructure underneath has to support the stateful case, because that's the one production agents actually need.

Snapshot-restore scheduling: turning idle agents from a cost problem into a storage line item

Snapshot-restore doesn't just solve continuity. It quietly rewrites the economics of running one persistent environment per user, and that's the part of this architecture most people underestimate on first look.

The trap is easy to fall into from either direction. A purely stateless, pay-per-call model is exactly right for a stateless code interpreter and exactly wrong for a long, stateful agent session. An always-on durable VM fixes state but bills for every idle second, which is most of an agent session. A durable per-run sandbox that hibernates when nobody's using it gives you the persistent workspace without paying for the silence in between. Most agents spend the overwhelming majority of their wall-clock time waiting: waiting on a model response, waiting on a user to type something back, or simply parked between sessions with nothing happening.

Pre-warmed VM pools buy back startup latency but trade idle cost for speed rather than eliminating either. Snapshotting gets the speed without the idle cost: between requests nothing runs, a frozen machine on disk rather than a live one holding RAM open needlessly. AWS Lambda MicroVMs, generally available since June 22, 2026, run each session in its own Firecracker microVM, charging storage-only rates with no compute charge while suspended; it spans multiple AWS Regions as of August 2026, supporting sessions up to 8 hours with up to 32 GB memory and disk and multiple vCPUs. Those are each company's own published figures, specific to that company rather than universal constants. Firecracker's API doesn't fix restore time by itself: snapshot size, storage bandwidth, compression, filesystem behavior, and concurrent restores on the same host all feed into it, and operators at scale must account for each.

There's an honest limit to how far this economics argument travels. If a tenant genuinely runs flat-out all day with no idle stretches, a plain container is cheaper, full stop; snapshot-restore earns its advantage for the intermittent, bursty pattern that describes most agents. In PandaStack's case, snapshot restore is roughly 179ms p50 and 203ms p99, and billing separates active compute from idle time, so an hour spent waiting on the model isn't charged. GPU workloads are the main exception, since virtio-gpu passthrough inside a microVM is slow and driver-fragile; the working pattern is CPU-bound sandbox code calling a separate GPU-backed inference service over an authenticated network allowlist.

What the per-user agent fleet looks like in production

Putting the three problems back together, security, state, and cost, produces a specific shape: one isolated, persistent, hibernatable VM per user, rather than one shared pool of containers serving everybody. That shape is what changes how a multi-tenant agent product actually gets built.

Self-hosted agents traditionally ran as always-on containers or VMs, one per user, billing continuously even while idle, a model that doesn't scale to large tenant counts. The hibernation model inverts this: a control plane launches one VM per tenant, running while active, suspending automatically once quiet, and parking its full state on storage at near-zero ongoing cost. The tenant is paying for the conversation, not for the silence around it, which is the right unit of billing for something that behaves like an agent rather than like a server.

Multi-tenancy at this scale also raises an identity question that's easy to overlook until it goes wrong. Each VM in the fleet needs its own dedicated HTTPS endpoint, so no shared load balancer in front of every tenant could misroute one user's request into another's session. That detail sounds minor next to hardware isolation and snapshot mechanics, but it keeps the per-tenant boundary intact all the way out to the network edge, not just inside the hypervisor. Isolation at the kernel level and persistence at the disk level don't mean much if the routing layer in front of them hands the wrong request to the wrong machine.