Firecracker Micro-VM Architecture for AI Agent Workloads

An agent writes a file-handling routine, the developer hits run, and three seconds later the host's runc binary has been quietly overwritten. That is not a hypothetical. CVE-2019-5736 let a malicious container rewrite the runc binary on the host and obtain root access on the machine running it, and the flaw worked precisely because of what a container actually is: a regular process wrapped in namespaces and cgroups, sharing the one kernel the host runs. AI agents turn that old vulnerability class into a daily operating risk, because the whole premise of an agent is that it writes and runs its own code, and that code is untrusted the moment it's generated.

A container gives you resource isolation, not a separate machine. Namespaces keep one process group from seeing another's filesystem and process table; cgroups cap what CPU and memory a group of processes can use. None of that changes the fact that every container on a host is a process running on the same kernel as every other container and the host itself. Seccomp filters, AppArmor profiles, SELinux policies, user namespaces: all of these sit on top of that one shared kernel, and all of them assume the kernel itself holds. A single kernel-level exploit collapses every one of those layers at once, because they were never independent boundaries to begin with. They were policy layered on a single piece of trusted code that every tenant on the box depends on equally.

Agents turn this structural weakness into an operational one. An agent optimizing a slow file-read might reach for subprocess.Popen(shell=True) because that's the fastest path to the result it was asked to produce. An agent acting on a prompt-injected instruction buried in a document it was asked to summarize will execute that instruction with the same confidence it executes a legitimate one, because it has no reliable way to tell the two apart. Code written by a model, at the moment it's about to run, hasn't been reviewed by anyone. CVE-2019-5736 is one demonstrated case of a container escape reaching host root through exactly this kind of shared-kernel surface, and because the attack surface it exploited is architectural rather than incidental, more such cases are certain to follow.

None of this makes containers a bad technology. If you package trusted application code in a controlled deployment pipeline, namespaces and cgroups still work as a fast, cheap, well-understood way to isolate workloads from each other. The failure is specific to the agent case: code that is generated autonomously, that may have been steered by an adversarial input, and that runs before any human reviews it. That combination needs a boundary that doesn't assume the kernel underneath it is trustworthy by default. It needs a boundary the kernel itself can't dissolve.

Firecracker's VMM

Firecracker closes the shared-kernel gap by giving each workload its own kernel. It runs in user space, uses Linux's KVM to create microVMs, and each microVM boots its own guest kernel. A kernel exploit inside a Firecracker guest reaches that guest's own kernel, and nothing past it. Behind that, the host's kernel, and every other microVM running alongside it, sits behind a hardware boundary the exploit can't touch.

The design choice that makes this practical, rather than merely safer in theory, is what Firecracker leaves out. That breadth is also QEMU's liability, because every device model it emulates is more code a guest can potentially exploit to break out. Firecracker throws nearly all of it away. It exposes only the minimal device emulation a cloud workload actually needs: a basic network device, a basic block device, a serial console, nothing else. Stripping away that legacy device surface removes most of what makes a traditional hypervisor an attractive target.

Firecracker runs one VMM process per microVM, isolating each from the others. The jailer isn't the thing doing the heavy lifting of isolation; it's a second barrier that has to be defeated even if the first one somehow isn't.

A hardware boundary beneath these software layers is one neither can bypass by accident. Intel VT-x splits execution into VMX root mode, where the host and hypervisor run, and VMX non-root mode, where guest code runs. In every case, the processor itself, not a software policy, prevents guest code from directly touching host memory, host devices, or host kernel interfaces under normal operation. Reaching the host from inside a Firecracker guest means defeating that hardware-enforced mode separation and the guest sandbox around it. Escaping a container means defeating a software policy layered on a kernel every tenant already shares. Those are different classes of problem, and the exploits for the first are rarer and considerably more expensive to produce than the exploits for the second.

Boot time and memory overhead: the numbers that make per-invocation microVMs viable

The standard objection to virtual machines has always been speed: containers start in under a second, VMs take ten or twenty. Firecracker was built to make that objection obsolete for exactly the workloads where it mattered most. Firecracker removes the excuse, because its startup time and memory overhead are low enough to isolate every single invocation without the user noticing.

Firecracker can launch multiple new microVMs per CPU core every second. Firecracker runs on 64-bit Intel, AMD, and Arm CPUs with hardware virtualization support, generally available for production use, so this isn't a capability locked to one chip vendor or a narrow slice of cloud hardware.

Memory behavior matters just as much as boot speed for agent workloads specifically, because agent memory needs are unpredictable in a way a typical web request is not. Firecracker supports memory hotplugging without downtime, so the guest can grow into the memory it needs mid-session, and the operator doesn't have to over-provision every agent from the start or risk a crash the moment a task gets heavier than expected.

Putting the boot numbers and the memory behavior together removes the old tradeoff. Firecracker fits roughly as many microVMs on a given host as Docker fits containers, at a comparable per-instance cost. That's VM-level isolation at container-equivalent economics, cheaper than the expensive, low-density tradeoff that made traditional virtual machines a poor fit for ephemeral, bursty workloads like agents.

Snapshot-restore scheduling: how idle agent VMs pay for storage instead of compute

Fast boot solves the delay of starting a new instance from scratch. It doesn't solve the cost of keeping an agent's state alive between turns, and agents spend most of their time waiting, not computing. The pattern that resolves this is snapshot-restore: boot a microVM fully once, snapshot it, and restore that snapshot on demand, keeping it out of the background otherwise. The restored instance comes back with warm-start latency, and the platform doesn't have to pay for a pool of idle, fully-booted VMs sitting around in case they're needed.

The economics behind that choice are straightforward. A warm pool trades continuous idle compute cost for instant handoff: you pay for every VM in the pool, every minute, whether or not a request ever lands on it. For workloads that are bursty and mostly inactive, which describes agents, CI runners, and code interpreters about as well as it describes anything in modern infrastructure, the snapshot bet usually wins. A restore also doesn't pay for the whole memory image regardless of size. It pays, in time and RAM, only for the pages the guest actually touches between the moment it resumes and the moment it's ready to handle work, meaning its working set, not the full snapshot. A large guest that only touches a small fraction of its memory to become usable again pays for that fraction, not the total.

On PandaStack, this plays out as a specific, measured number: every create operation restores a baked Firecracker snapshot at roughly 179 ms at the 50th percentile. The only slow path in the system is the very first spawn of a brand-new template, which has to cold-boot the guest and bake the initial snapshot; every creation after that rides the fast restore path instead.

This is the piece of infrastructure that makes the pattern of an agent pausing for human input practical: HITL workflows pause mid-task and wait on a human for input, sometimes for seconds, sometimes for hours, and that wait has to be cheap, or the economics of the whole agent product break. Snapshot-restore is what lets an agent securely persist its full state while it waits, and it doesn't burn compute for the duration of the pause. Everything the agent accumulated before it went to sleep, meaning its files, credentials, installed packages, open browser sessions, in-memory context, comes back immediately on restore, intact. That's what separates a genuinely persistent agent from a stateless function call that just happens to be invoked repeatedly.

At fleet scale, the implication compounds. In any real multi-tenant deployment, the overwhelming majority of agents are idle at any given moment, waiting on a user, a tool call, or another process. A scheduler built around snapshot-restore turns a fleet of thousands of agents into a compute bill that tracks active concurrency, not total agent count, which is the only version of that math that scales.

Economics of Running Agent Fleets at Scale

The real cost of an agent fleet depends on the utilization profile the workload actually produces, and for most agent products, that profile is bursty and mostly idle, which is exactly the profile snapshot-restore was built to serve cheaply.

There's a crossover point between low and high utilization that determines which economics wins. At low utilization, where individual agents run in short, scattered bursts and spend most of their life suspended, snapshot-restore economics dominate every other option, because there's close to nothing to pay for between bursts. At high, sustained utilization, where an agent is working close to continuously, a warm pool or an always-on instance starts to look comparably attractive, since the restore overhead no longer buys much when there's rarely an idle gap to restore out of. Most agent products, most of the time, sit in the first category, not the second.

Suspended VMs themselves cost no compute. What they do cost is storage: every snapshot sitting in reserve for a sleeping agent occupies disk space somewhere, and that cost varies by provider and becomes a real line item once a fleet reaches thousands of suspended instances. If you're planning a large hibernating fleet, you have to budget for that storage cost explicitly, because suspension isn't free just because the compute meter stops.

Picture a platform running several thousand tenants, each with their own agent, where most of those agents are asleep at any given time. The fleet scales with a single API call per new tenant. Isolation, under this model, is close to a free upgrade, because the workload's own bursty, mostly-idle shape is what snapshot-restore was designed around from the start.

Per-user agent patterns and multi-tenant fleet architecture

Firecracker's one-VMM-per-microVM design maps onto a specific, concrete architecture for multi-tenant agent products: one isolated VM per tenant, with that tenant's identity injected at runtime. The base image knows nothing about any particular tenant. Isolation here is structural, built into the fact that each tenant's code runs in its own VM with its own kernel, not a matter of policy that a misconfiguration could quietly weaken.

That structure extends down to networking and credentials. Each VM gets its own dedicated HTTPS endpoint, so there's no shared load balancer in the path that a routing bug or a compromised tenant could exploit to misdirect traffic meant for someone else. Tokens are port-scoped JWEs minted per VM, so even a stolen credential for one tenant's endpoint is useless against any other tenant's. This matters because namespaces and cgroups are a resource boundary, not a security boundary, and a multi-tenant AI product is exactly the kind of workload where a hostile tenant gets to type arbitrary input into your process all day long. Confusing resource isolation for security isolation is the mistake the whole architecture is built to avoid.

Scaling the fleet is a control-plane operation, not an infrastructure project. Onboarding a new tenant is the same operation as adding any other VM to the fleet: no special-cased infrastructure, no per-tenant configuration step that has to be maintained by hand.

Major cloud providers are now shipping this exact model as a named product. Maritime, a persistent AI agent hosting platform that gives each agent its own Firecracker micro-VM with a dedicated kernel rather than a shared container, has built its entire infrastructure around this isolation primitive. DigitalOcean's MicroVMs, in private preview as of October 2026, explicitly lists per-tenant tools and MCP servers as one of its use cases, with each customer's tools running in their own VM so that one tenant can never reach another's. AWS Lambda MicroVMs, generally available since June 22, 2026, gives developers a dedicated, hardware-isolated, stateful VM per user, per session, or per job, launched from a snapshot in near-real time, without requiring the developer to manage any virtualization infrastructure directly. Amazon Bedrock AgentCore Runtime applies the same principle one layer up, at the session level: every agent session gets its own microVM for as long as that session lasts, state persists across multiple invocations within it, and the VM is terminated with its memory sanitized once the session ends.

The pattern common to all three products is this: each user's agent gets its own space, its own memory, and its own continuity from one session to the next, the way people live in separate apartments. Firecracker is the architecture that makes that primitive affordable at the scale a real product needs.