Microvm Isolation with Firecracker for AI Workloads

When an AI agent runs code it just generated, nobody has reviewed that code. Not a security team, not a linter with human judgment behind it, not even the person who wrote the prompt. The agent wrote it, and now it wants to run it, and the infrastructure underneath has to decide how much damage that code can do if it turns out to be malicious, buggy, or hijacked mid-execution. Firecracker, the virtual machine monitor AWS built and open-sourced, answers that question with hardware rather than policy. What follows is a look at how that answer actually works, where it holds up, and where teams still need something else.

The scale of the problem is worth sitting with for a second. An agent with shell access can install packages, open sockets, read environment variables, fork processes, and touch every file descriptor the host process can see. That's the entire Linux surface, handed to code that arrived seconds ago from a language model. And the attack path doesn't require the model itself to be compromised: prompt injection lets an attacker bury instructions inside a tool result or a document the agent reads, and the agent, unable to distinguish data from command, executes them with whatever permissions the process holds.

This isn't hypothetical. In a disclosure coordinated for March 16, 2026, the security research group PromptArmor detailed a vulnerability in Snowflake's Cortex Code CLI, patched in version 1.0.25 on February 28, 2026. The chain: indirect prompt injection, weak validation of process-substitution syntax in commands, and injection-driven manipulation of an unsandboxed execution flag. Combined, they bypassed the human-in-the-loop approval step entirely, enabling arbitrary code execution and unauthorized access to cached credentials. Separately, CVE-2025-34291 in the Langflow AI platform showed attackers chaining a CORS/CSRF flaw to hijack authenticated sessions and run arbitrary Python. And a research finding that deserves more attention than it gets: LLM-generated patches meant to fix a security issue introduce a new vulnerability in roughly 9.5% of cases. Even the corrective code carries fresh risk.

So the trust problem isn't a prompting problem. No amount of instruction-tuning lets a runtime verify, after the fact, where a piece of code actually came from or what it intends to do. That's a structural gap, and it means sandboxing for AI workloads has to mean something more than throttling CPU and memory, which is the problem Daytona, a cloud infrastructure platform for running untrusted AI-generated code, was built to solve. It has to mean preventing a fully compromised execution from ever touching the host.

What the shared-kernel model gets wrong for untrusted code

Docker containers, and the OCI standard generally, isolate processes using Linux namespaces and cgroups. That's isolation by convention, enforced by the kernel's bookkeeping, not by a hardware wall. Every container on a host shares that one kernel, and the Linux kernel runs to something like 40 million lines of C. A single exploitable path anywhere in that surface, in a driver, a syscall handler, a networking subsystem, can let one container reach every other workload on the box and the host itself.

Container escape doesn't mean the attacker gets a slightly bigger foothold. It means root on the host. The blast radius is the whole machine, not the workload that got popped.

This isn't a theoretical worry dressed up for effect. CVE-2024-21626 in runc, the low-level container runtime underneath Docker and Kubernetes, allowed a crafted container to break out to the host filesystem. CVE-2025-23359 in the NVIDIA Container Toolkit did something similar for GPU-enabled containers. The kernel's io_uring subsystem has been a noted source of guest-to-host escape concerns, with CVE-2026-1109 representing one documented example in this class.

And notice who moved first. AWS has shifted parts of its own control plane away from runc-style shared-kernel containers toward hardware-enforced isolation. None of the major clouds reached for standard containers when it came time to secure workloads running arbitrary AI-generated code. That's a signal worth taking seriously: the people who operate at the largest scale, with the most to lose from a single escape, chose a different primitive entirely.

Standard containers remain fine for code your own engineers wrote and reviewed. The moment the code comes from a model, or from a user upload, or from an agent chaining tool calls together, the shared kernel stops being an acceptable bet.

How Firecracker draws that boundary in hardware

Firecracker is a virtual machine monitor written in Rust, open-sourced under Apache 2.0, running entirely in user space. It uses Linux's KVM subsystem to spin up what it calls microVMs, and the isolation boundary it creates isn't a software convention at all. It's Intel VT-x or AMD-V, the CPU's own virtualization extensions, enforced in silicon. Each microVM gets its own kernel, its own filesystem, its own network stack. A kernel exploit inside one microVM has nowhere to go: it can compromise that one guest kernel completely and still never touch the host or any neighboring VM.

The minimalism is deliberate, and it's a security property in itself, not just a performance one. Firecracker emulates a deliberately small set of devices: virtio-net for networking, virtio-block for disk, virtio-vsock, and a serial console, among others. That's the entire device model. Compare that to QEMU, which emulates a full PC, complete with legacy peripherals nobody's guest OS has needed in a decade, and runs over 1.4 million lines of C to do it. Firecracker's whole VMM comes in at roughly 83,000 lines of Rust, measured with cloc as of March 2026. Every feature QEMU supports that Firecracker doesn't, GPU passthrough, CPU hotplugging, nested virtualization, is attack surface that simply isn't there to exploit.

Firecracker also ships with a companion program called Jailer, which locks the VMM process down with its own set of user-space restrictions: cgroups, chroot, dropped privileges, seccomp filters. Even in the scenario where the virtualization barrier itself somehow fails, Jailer's constraints are a second wall standing between the guest and the host.

What would it actually take to break out of a Firecracker microVM? A hypervisor-level CVE, essentially a flaw in KVM itself or in Firecracker's narrow device emulation code. That class of vulnerability is rare enough to command real money on the exploit market, in the range of $250,000 to $500,000, and Google's kvmCTF bug bounty program pays out $250,000 for a full KVM escape on its own. That price tag is a rough proxy for how hard the exercise actually is.

That distinction matters most when comparing Firecracker to something like gVisor or a standard container: the security primitive here is the CPU's own virtualization hardware, not a layer of software sitting on top of the same kernel everyone else shares.

The performance properties that make this boundary practical at agent scale

None of this matters if it's too slow to use. VMs have carried a reputation for decades as heavy, slow-to-boot, memory-hungry things, fine for a long-running server, wrong for a workload that lives for a few seconds. Firecracker was built to overturn that reputation, and the published numbers back it up: Firecracker can boot a microVM in as little as 125 milliseconds, using under 5 MiB of memory overhead per VM, and a single host can spin up new microVMs at a rate of 150 per second.

Those aren't lab numbers dressed up for a keynote. Firecracker is the VMM underneath AWS Lambda and AWS Fargate, and Lambda's Firecracker-based microVMs handle over 15 trillion function invocations a month. At that volume, a memory overhead of even 20 or 30 MiB per VM instead of 5 would translate into a genuinely enormous amount of wasted capacity across the fleet. The density numbers aren't a nice-to-have here, they're load-bearing for the whole economics of serverless compute.

Firecracker's API gives operators per-microVM control over resource assignment at spawn time. That means isolation and resource governance travel together: thousands of microVMs on one host, each one boxed in not just from a security standpoint but from a noisy-neighbor standpoint too.

Still, 125 milliseconds is a floor, not a universal answer. For batch jobs, pipeline stages, anything where a person isn't sitting there watching a cursor blink, that's plenty fast. For an interactive agent loop, where a user is waiting on a response and the agent needs to spin up a sandbox mid-conversation to run a tool call, 125 milliseconds of cold boot on top of everything else in the request path starts to add up. The snapshot mechanism solves that gap.

How Firecracker snapshots reduce cold starts to the range agents actually need

A full cold boot of a Firecracker microVM, walked through step by step, looks something like this: the Firecracker process itself starts up in around 50 milliseconds, the guest kernel loads into memory in about 100 milliseconds, the kernel then boots and runs its init sequence in roughly 500 milliseconds, and the guest agent inside starts up and signals ready in another 200 milliseconds or so. Add it up and a full path from nothing to a ready sandbox runs close to a full second.

A second is a long time to sit inside an agent's chat loop. Nobody wants to watch a spinner for a full second every time an agent decides it needs to check something in a sandbox, and that's exactly the gap snapshotting closes.

Here's the mechanism. Boot a microVM once, let it reach a fully ready state, then pause it and write everything to disk: the complete memory contents, every CPU register (instruction pointer, stack pointer, the works), and the state of every emulated device. That snapshot file becomes the seed for every future sandbox spawned from that same image. Restoring one doesn't mean booting a new VM. Firecracker memory-maps the snapshot file, loads the saved CPU state directly into the virtual CPU, and resumes execution from the exact instruction where it left off. The guest kernel never runs its init sequence again. From inside the VM, no time appears to have passed at all, it just... continues.

One example of what this looks like in practice: ForgeVM, a Firecracker-based orchestrator, reports sandbox boot times around 28 milliseconds using this snapshot-restore approach, against Firecracker's baseline cold start of anywhere from 125 milliseconds to close to a full second depending on how much of the init path has to run. Broken down, that 28 milliseconds splits roughly into 5ms to start the Firecracker process, 8ms to memory-map the snapshot, 10ms to restore CPU and device state, and 5ms to reconnect the vsock channel and signal readiness.

Density comes from a second trick layered on top: copy-on-write overlays. The base snapshot stays read-only, and every new VM spawned from it gets its own thin CoW layer for memory and the root filesystem. Fifty VMs spun up from the same snapshot share nearly all of their memory pages; only the pages each one actually modifies get duplicated. That's how a host handles high fan-out without every sandbox eating its own full memory footprint from scratch.

Put together, a restore path running in the 5 to 30 millisecond range is what makes something like a SWE-bench-style agent harness workable in practice, one where an agent accumulates context across dozens of tool calls, and each call might spin up a fresh sandbox to run a test or inspect a file. The economics work out because the expensive part, the cold boot and the snapshot creation, happens exactly once per image. Every spawn after that is a restore, not a boot, and the cost amortizes across however many invocations follow.

Where Firecracker's deliberate constraints become real limitations

None of this comes free. Firecracker's minimalism is the whole point of its security model, but minimalism means real capability gets left on the floor, and it's worth being honest about what that costs a team trying to build on it.

No GPU passthrough, by design. Any agent workload that needs a GPU for inference or heavier compute simply cannot run inside a Firecracker microVM as it stands. No nested virtualization either, which rules out anything that needs to run a VM inside the sandbox. No CPU hotplugging: CPU resources a microVM gets assigned at spawn time are fixed for its lifetime, with no scaling up mid-flight if a workload turns out to need more than expected.

There's a host-level requirement too. Firecracker needs a Linux host with KVM support, meaning 64-bit Intel, AMD, or Arm hardware with virtualization extensions turned on. That rules it out for any environment without kernel-level access to the host, which matters for teams evaluating it against fully managed platforms where that access isn't on offer.

And running Firecracker directly is not a drop-in replacement for docker run. It's a primitive, not a product. Teams that adopt it are signing up to build snapshot lifecycle management, the copy-on-write overlay logic, a vsock-based agent protocol for talking to the guest, and network namespace setup for each VM, essentially an entire orchestration layer that Firecracker itself doesn't provide. Without that layer, teams are stuck at the 125-millisecond baseline. Getting down to the 28-millisecond range described above requires the snapshot pipeline to be in place first, which represents real work before the first line of agent code ever runs.

None of these constraints are oversights. They're the direct consequence of a threat model that says: remove every feature that isn't load-bearing, because every feature is also a door. But that means the constraints define, pretty sharply, which workloads belong on Firecracker and which need a different foundation.

When to reach for gVisor, Kata Containers, or Cloud Hypervisor instead

Isolation isn't a single ladder with one correct rung. It's closer to a set of tradeoffs, and the right pick depends on what the workload actually needs.

Standard containers, Docker and the OCI ecosystem, sit at one end: shared kernel, the fastest option, and appropriate only when the code running inside was written and reviewed by people the organization trusts. Not for LLM-generated code, not for anything a user uploaded.

gVisor sits a step further out. It's a user-space layer that intercepts syscalls from the sandboxed program and re-implements them itself, so the guest program never actually touches the real kernel's syscall surface. That's meaningfully stronger than a standard container, and lighter than a full VM, though the tradeoff shows up as syscall compatibility gaps: some Linux software that depends on obscure or newer syscalls can break under gVisor's reimplementation. Google's own Agent Sandbox project uses gVisor as its foundational runtime, and it shows up in a number of managed platforms as the default isolation layer.

Firecracker microVMs, as covered above, sit further out still: hardware-level isolation via KVM, a dedicated kernel per workload, and arguably the current default answer for untrusted code at scale, with the GPU, nested-virtualization, and hotplugging gaps already discussed.

Kata Containers takes a different angle on the same hardware-isolation idea. It orchestrates VMMs, Firecracker among them, alongside Cloud Hypervisor and QEMU, but wraps them behind a standard container API. From Kubernetes' point of view, a Kata-managed workload looks like an ordinary container. Underneath, it's a full VM with hardware isolation. That makes it a natural fit for teams already committed to Kubernetes who want VM-grade isolation without rebuilding their deployment tooling. Northflank runs on this model.

Cloud Hypervisor keeps Firecracker's minimal-VMM philosophy but adds back some of what Firecracker deliberately strips out: nested KVM (a --cpu nested=on|off flag added in December 2025), VFIO-based device passthrough for GPUs, CPU and memory hotplugging, and support for Windows guests. The cost is a few dozen milliseconds of extra boot time and a somewhat larger attack surface than Firecracker's six-device model. For a team that specifically needs GPU passthrough or nested virtualization, features Firecracker excludes on principle, Cloud Hypervisor is the natural next stop rather than a compromise.

A simple way to frame the decision: internal CI/CD code running your own pipelines can stay on containers. LLM-generated code needs gVisor or a microVM at minimum. Anything involving user-uploaded binaries or packages an agent installed on its own should be treated as hostile by default, which means hardware virtualization, full stop.

Worth watching, though none of these are production-proven yet: Microsoft's LiteBox, introduced in February 2026, is a Rust-based Library OS built on AMD SEV-SNP confidential computing, aiming at a middle ground between container and VM, but it's experimental, with no SDK and no real ecosystem around it as of early 2026. SmolVM, launched April 17, 2026, is a single-executable microVM aimed squarely at sub-second cold starts for one-shot agent sandboxes, and it has shown early traction but has not proven itself at any real scale yet. And WebAssembly, specifically WASI 0.3, offers speed and density for polyglot tool execution with fine-grained capability control, but it's a different kind of boundary altogether: it doesn't provide OS-level isolation the way a VM or gVisor does, so it answers a different question than the one this piece is mostly about.

How the platforms building on Firecracker handle what you'd otherwise build yourself

Firecracker itself is a primitive. What a development team actually experiences, the session model, the API, how much operational weight lands on their own shoulders, comes entirely from whatever orchestration layer sits above it.

A few platforms build directly on Firecracker. Vercel Sandbox offers managed, ephemeral compute for running untrusted or AI-generated code, built on an internal platform called Hive that orchestrates clusters of Firecracker microVMs across regions. It was announced in mid-2025 and reached general availability on January 30, 2026, pitched specifically as the execution layer for agents that clone a repo, install dependencies, and run a test suite. Fly.io offers Sprites, persistent Firecracker microVMs with idle billing and SOC 2 compliance. And AWS Lambda's MicroVMs, mentioned earlier for their invocation volume, preserve full memory and disk state for up to eight hours, suspending when idle and resuming on demand, scaling vertically up to four times baseline capacity during peak load, with per-second billing and no compute charges while suspended.

Others build on Kata Containers, getting Firecracker or Cloud Hypervisor under the hood with a standard container API on top. Northflank processes over 2 million isolated workloads a month this way, choosing gVisor or Kata Containers per workload depending on what that workload needs, with bring-your-own-cloud deployment across AWS, GCP, Azure, and bare metal, unlimited session duration, and GPU support bundled into its pricing.

For teams that want to self-host rather than adopt a managed layer, Microsandbox is one option: version 0.1.0 shipped in April 2025, combining hardware-level microVM isolation (via libkrun) with sub-200 millisecond startup times, released under Apache 2.0 and picking up a few thousand GitHub stars since launch.

And for teams already committed to Kubernetes, Google's Agent Sandbox, launched at KubeCon NA 2025 as a Kubernetes SIG Apps subproject and now a CNCF project, offers a declarative API for managing isolated, stateful sandbox pods directly on an existing cluster. It supports both gVisor and Kata Containers as backing runtimes, and its SandboxWarmPool custom resource keeps a pool of pre-booted pods on standby, pushing cold-start latency down to sub-second without introducing a new vendor dependency for teams that are already running Kubernetes anyway.

When a team picks one of these managed layers over hand-rolling Firecracker directly, they're buying everything underneath the surface: snapshot lifecycle management, automated network namespace setup, policies around session duration, bring-your-own-cloud support, and whatever compliance certifications the workload requires. That orchestration layer is where the bulk of the real engineering effort lives, not in Firecracker itself.

What stateful execution requires beyond the isolation boundary

Isolation answers the question of whether a compromised sandbox can hurt anything outside itself. It doesn't answer the question of what an agent needs across the life of a task that spans dozens of tool calls, file edits, and test runs, sometimes over minutes, sometimes longer. A sandbox that resets to a blank slate after every single call is safe, certainly, but it also forces the agent to re-establish its entire working state, reinstall dependencies, re-clone a repo, rebuild whatever context it had, every single time.

That's where the snapshot-and-restore mechanism earns its keep beyond just cutting cold-start latency. Preserving memory and filesystem state across pauses means an agent's sandbox can hold its working directory, its installed packages, its open file handles, across a whole sequence of tool calls, rather than losing all of it the moment execution pauses. The isolation boundary keeps a bad actor from reaching the host. The snapshot mechanism is what lets a legitimate, long-running agent task actually accumulate state without paying a full rebuild cost at every step.

Both pieces matter, and neither substitutes for the other. Hardware isolation without state continuity gives an agent a locked room that resets to empty every time it steps out. State continuity without hardware isolation gives an agent a workspace that persists, sitting on infrastructure a single kernel exploit could walk straight through. Workloads worth building on Firecracker, or on whatever platform sits on top of it, need both properties at once: a boundary that holds even under full compromise, and a memory that holds even under real work.