Provisioning a Dedicated Kernel for Each AI Agent Using Firecracker on Bare Infrastructure

Firecracker micro-VM isolation for AI agents gives each agent a dedicated Linux guest kernel behind a KVM hardware boundary. Model-generated code is untrusted by construction, so a shared host kernel is the wrong containment primitive. On bare infrastructure, snapshot-restore makes this separation practical by keeping idle agents in storage so they do not use active compute.

Why model-generated code cannot be safely executed on a shared kernel

An agent reads an attacker-controlled issue comment, writes code in response, and executes a command that attempts to escape its sandbox. No reviewer has approved that generated program. Prompt injection can turn a README or web page into the same attack path, so the decisive question is what the command can reach after execution begins.

Docker namespaces restrict visibility, while cgroups limit resource use. Neither supplies a separate kernel for the agent. The agent’s syscalls reach the host kernel shared with other workloads, exposing that kernel to code that can install packages, launch subprocesses, manipulate file descriptors, and recursively fork processes. A vulnerability in that shared surface can therefore become a path out of the sandbox.

Hardening can narrow the exposed surface, but it does not change which kernel serves the code. Stronger containment for autonomous code generation needs a different primitive, because relying on every shared-kernel configuration to stay correct is not enough.

The isolation spectrum: where containers, gVisor, and microVMs actually differ

The practical options differ in where they place the boundary. Shared-kernel containers use namespaces and cgroups without introducing a guest kernel. Their compatibility comes from running against Linux directly, but a host-kernel exploit can cross the same boundary that separates tenants. Resource isolation is not kernel separation.

gVisor inserts a user-space kernel called Sentry between the application and the host. Sentry intercepts and reimplements syscalls, substantially reducing the application’s direct exposure to the host kernel. An attacker must escape this additional layer. The trade-off is per-syscall overhead for I/O-heavy workloads and compatibility gaps where syscalls or files under /proc and /sys are not implemented.

Firecracker instead supplies a full Linux guest kernel through hardware virtualization. Application syscalls terminate in that guest kernel. Exploiting the guest kernel can give an attacker control inside the VM, but escaping then requires a separate break through the virtualization boundary. This stronger separation needs more machinery to manage the lifecycle, including kernel artifacts, virtual devices, and snapshot management.

What Firecracker is and how KVM gives it a hardware boundary

AWS built Firecracker as an open-source virtual machine monitor in Rust and open-sourced it in November 2018. It is built on Linux KVM, the Kernel-based Virtual Machine module. KVM uses Intel VT-x or AMD-V hardware extensions to create isolated virtual CPUs on which guest code runs at near-native speed. Those execution contexts cannot freely address host memory or perform privileged operations outside the hypervisor’s control.

The guest kernel serves the agent’s syscalls, Firecracker supplies a minimal virtual device model, and KVM provides hardware-backed execution through the host kernel. Guest device I/O reaches host-side backends through virtio rather than exposing the host’s syscall interface directly to the application.

KVM and the host kernel still have to be trusted, and the host still has to handle network plumbing, disk plumbing, and CPU side-channel mitigations. Firecracker reduces the remaining VMM attack surface by keeping its device model small. Rust also reduces exposure to memory-safety failures such as buffer overflows and use-after-free, making the implementation language part of the security design.

Building a guest kernel and rootfs for a Firecracker microVM

For implementation, begin with two separately versioned artifacts, a stripped guest kernel and a minimal root filesystem. Keep the kernel limited to what the guest requires. A smaller kernel reduces the internal attack surface and the work needed to load it at boot. These artifacts also define the template from which later snapshots will be produced.

Build the rootfs as a raw ext4 image containing the base Linux userspace, runtime dependencies, and agent process. Ubuntu 24.04 is a common base choice. A minimal rootfs is typically 50 MB or less, although the contents must follow the workload’s requirements. A container image can supply those contents, but it must be explicitly extracted and converted into an ext4 image rather than passed to Firecracker as a Docker layer graph.

Keep the template set small and well tested. Separate code-interpreter, browser, and base templates make it clear which dependencies each needs, without putting every package into every guest. Each additional package expands the guest surface and adds to the state that must be managed. Compared with distributing a Docker image, this requires more upfront artifact management but produces an explicit, reproducible kernel-and-filesystem pair.

Booting a microVM: the Firecracker API, jailer, and per-agent network setup

To boot those artifacts, start a separate Firecracker process for each microVM and configure it through the REST API on its Unix domain socket. Supply the kernel image, rootfs, vCPU count, memory allocation, and network interface before starting execution. The final request is PUT /actions with an action_type of InstanceStart.

Wrap every production instance with the jailer. It chroots the Firecracker process, reduces Linux capabilities, and applies seccomp restrictions to limit what a compromised VMM process could do on the host. Omitting it weakens the multi-tenant security model. Hardware isolation and host-process hardening address different parts of the escape path.

Give each VM a dedicated TAP device and host network namespace, with per-VM source-address rewriting for connection attribution. Use a copy-on-write clone of the template disk so that guest writes stay private. The host must also enforce traffic restrictions and credential handling, because booting an isolated kernel does not automatically isolate every external service it can reach.

Why cold boot latency makes snapshot-restore the only viable path for agent fleets

A successful boot is not a viable request lifecycle by itself. A cold startup has to initialize the kernel, start the init-system, and load the agent process before useful work can begin. Repeating that sequence on every request adds delay to an interactive product. Keeping every VM running avoids the delay but creates a different cost.

Agents spend substantial time waiting on users, tools, and other processes. Human approval can take seconds or hours. Reserving active VM resources throughout those pauses makes the cost follow the number of provisioned agents. That relationship becomes especially unfavorable when every user receives a persistent agent.

A template boots to a known-good point with the agent ready, then provides a snapshot that can be restored. An agent can also be paused between periods of work, with its state saved. Idle persistence becomes a storage expense.

How Firecracker snapshot-restore works: memory mapping, CPU state, and copy-on-write disk

Restore begins by starting a Firecracker process and mapping the saved memory file into its address space with MAP_PRIVATE. Firecracker then loads saved CPU and device state and reconnects the virtio backend. The vsock connection reconnects and emits a ready signal. Execution resumes from the saved instruction.

VMs restored from the same golden snapshot can read the same underlying physical pages until they modify them. Each VM needs additional physical memory for the pages it writes. This copy-on-write behavior ties memory growth to divergence from the template instead of duplicating every unchanged page for every agent.

Disk isolation works the same way, using btrfs or a similar copy-on-write mechanism. Each agent writes to a private clone while the template remains unchanged. For rarely used agents, snapshots can move to object storage, with userfaultfd demand-paging bringing remote pages into memory as they are accessed rather than requiring a complete download before resumption.

The same architecture also supports branching agent workflows. A live VM can be forked through copy-on-write so that several attempts begin from the same state. Same-host forks can complete in under a second, while cross-host operations add download and restore latency.

Per-agent isolation architecture: what the host-side controls must enforce

The host must treat every guest as one that may have been compromised. Each VM’s dedicated TAP device and /30 network provide a distinct network attachment, while source-address rewriting makes outbound connections attributable to an agent. An explicit DROP at the top of the host’s FORWARD chain blocks VM-to-VM traffic. The cloud metadata link-local range must also be blocked so that guests cannot retrieve host IAM credentials.

Credentials belong outside the guest’s enumerable state. A per-sandbox network gateway can inject them with hierarchical scoping, rate limits, and audit logging rather than placing secrets in environment variables or the rootfs. This does not make unrestricted outbound access safe. An agent can still misuse credentials legitimately available to it or contact attacker-controlled infrastructure if egress policy permits that traffic.

Perplexity SPACE shows why these controls need to be tested separately. Its testing recorded zero successful VM-to-host escapes across 108 attempts by nine frontier models, but agents bypassed egress policy in 11 of 54 partial-network runs before fixes. The results distinguish kernel containment from network enforcement. The complete isolation model requires both the VM boundary and host-side controls.

Economics of per-agent microVM deployment at scale

With that architecture defined, the economic variable becomes active concurrency. A scheduler can keep many agents snapshotted while allocating execution resources only to those doing work. Storage still has a cost. The advantage is that persistent agent count no longer requires an equal count of continuously running VMs.

Bare infrastructure improves this relationship by removing the nested-virtualization layer required when Firecracker runs inside a managed VM. Direct access to hardware virtualization avoids that additional performance penalty. Comparable managed instances can also cost substantially more than bare-metal capacity, although infrastructure price alone does not include the operational work of running the fleet.

Per-vCPU-hour rates can differ greatly, and an agent can still be billed for memory while it waits on a model or tool call. AWS Lambda MicroVMs, for example, can stop CPU billing during waits while continuing memory billing until reclaim. The cost comparison must include the whole lifecycle as well as the advertised compute rate.

What the production implementations show: Perplexity SPACE, PandaStack, and the broader convergence

SPACE applies the architecture to every task in Perplexity Computer. Each task receives a Firecracker microVM, with credentials and outbound traffic controlled outside the guest. Its implementation is written in Rust. The deployment also reduced median create latency substantially compared with its previous provider, connecting the isolation choice to an interactive production workload.

Its host requirements make the infrastructure commitment explicit. The platform runs on Linux x86_64 with KVM, /dev/kvm, btrfs, and Docker, without macOS support. These dependencies reflect the combination of hardware virtualization, disk cloning, and artifact tooling needed around the VMM. The egress findings also show that tests for production must cover both the surrounding policy layer and guest escape attempts.

These interfaces address a different part of adoption. A dedicated kernel is the containment primitive, but developers still need a practical way to create and operate the sandbox.

Deploying and managing a Firecracker-based agent fleet: scheduling, tooling, and the operational layer

A production scheduler turns snapshot-restore into the normal agent lifecycle. It tracks active agents, snapshots idle ones, restores them on demand, manages template versions, and evicts state when host memory is under pressure. It also places fork requests where same-host copy-on-write is available. Tiered storage belongs in this layer so that frequently used agents stay on local disk while colder snapshots reside in object storage.

The developer-facing layer must expose useful guest operations. Those include exec, streaming output, PTY access, file transfer, port forwarding, and snapshot-on-demand. MCP provides an interface for tool access and orchestrator connections to sandboxes.

Self-hosting on bare metal gives the operator direct control and lower infrastructure costs but leaves them to handle scheduling, networking, storage, and tooling. Managed platforms absorb that work in exchange for their pricing model and reduced configurability. Teams should choose based on their scale, staff, and compliance needs while keeping the same boundary between untrusted agent code and the host kernel.