Swapping the Container Runtime for a Firecracker Kernel per Agent

Firecracker micro-VM isolation for AI agents replaces a shared host kernel with a dedicated guest kernel per agent, separated from the host by hardware virtualization. For agents that execute untrusted code, this hardens the boundary that containers leave shared. To put that architecture to work, the platform needs snapshot-based scheduling, persistent storage, managed networking, and authorization before tool calls run.

Why the container's security model breaks for AI agent workloads

An agent can execute shell commands, install packages, maintain browser sessions, and act on instructions found in user-supplied content. Those capabilities make its execution path less predictable than that of an ordinary stateless service. A webpage can become an instruction source. If adversarial content redirects the agent’s next tool call, the command runs with permissions the application already gave it, so it needs no vulnerability to gain that initial authority.

Namespaces separate the resources processes can see, while cgroups control resource use, but neither gives the workload its own kernel. Every containerized process still depends on the host kernel to execute system calls. For an agent that writes Python or invokes bash, that shared surface sits directly beneath its tools. Container isolation therefore leaves the workload’s most consequential execution boundary shared with other workloads.

Multi-tenancy makes that exposure more consequential than an agent damaging its own workspace. An injected prompt can redirect one tenant’s agent toward behavior that attempts to cross the shared boundary. Prompt injection can supply the instructions that initiate an attack through legitimate tools. Namespaces cannot eliminate the cross-tenant risk of a kernel compromise. The isolation decision must therefore account for adversarial execution alongside orderly separation between cooperating services.

What a kernel boundary actually means and why containers don't provide one

A kernel boundary separates the operating system that serves the workload from the operating system that serves the host. A container has no such separation. Its processes use the host kernel, so a successful attack against that kernel can expose the host and other containers. Even with tighter resource controls, a container still has no kernel of its own.

A microVM runs its own guest kernel. Workload system calls reach that kernel first, while hardware virtualization through KVM separates the guest from the host. Compromising the guest kernel does not itself grant control of the host. An attacker must also defeat the virtualization boundary. This changes the containment structure from a shared kernel boundary to successive guest and host isolation layers.

The runtime options are not interchangeable implementations of one security model. Google uses gVisor’s userspace kernel sandbox for Cloud Run and GKE Sandbox, interposing its Sentry on system calls without providing hardware-enforced kernel isolation. AWS uses Firecracker microVMs for Lambda and Fargate, while Azure uses Kata Containers/Hyper-V isolation for ACI and AKS Pod Sandboxing. For agents executing untrusted or model-generated code, Firecracker supplies the dedicated kernel and hardware-enforced separation that the microVM tier requires.

How do you give each AI agent its own Firecracker kernel at container-comparable cost?

Firecracker makes a hardware-isolated VM small enough to run a single agent without the size of a large, general-purpose machine. It is designed to isolate each request or session. That granularity fits agent workloads directly. Dedicating a kernel to each unit could force operators to retreat to shared-kernel execution if it consumes too much memory or startup time.

Firecracker is said to take approximately 125ms to boot, with under 5 MiB of memory overhead per instance in addition to the agent’s own memory requirement. The design fits roughly as many microVMs as Docker fits containers on a given host, at comparable cost, rather than guaranteeing identical density for every workload. A host can also sustain launching many microVMs per second.

The small footprint follows from deliberate omissions. Firecracker has no legacy PCI bus or BIOS and exposes a stripped set of virtio devices. Fewer emulated devices reduce both initialization work and the paths available for attacks from guest to host. The guest can also use a stripped, security-hardened Linux kernel, reducing the surface exposed to agent code before the hardware boundary. Firecracker is therefore optimized to provide a kernel boundary cheaply.

Snapshot-restore: how per-agent microVMs become economically viable at fleet scale

Agents can spend seconds to hours waiting for human input, and reserving running compute throughout those pauses makes the cost follow the number of provisioned agents. Snapshot-restore changes that relationship. It lets an environment stop using active compute and keep its execution state, so the next invocation can skip a cold start.

The mechanism begins with a fully booted VM. Pausing it and writing its memory and device state to disk creates a snapshot that subsequent instances can map, skipping kernel boot. Cold initialization becomes an image-preparation cost. The described restore decomposition includes Firecracker process startup, memory snapshot mapping, CPU and device state restoration, and vsock reconnection, totaling approximately 28ms. That figure illustrates the magnitude of the described restore mechanism.

Copy-on-write memory sharing improves the economics further when many VMs restore from the same golden snapshot. Unmodified pages can remain physically shared across hundreds of VMs, while each agent consumes additional RAM for pages its execution changes. For dormant agents, the complementary saving comes from releasing compute after suspension. Their snapshots still occupy storage, so hibernation shifts the cost to storage while the expensive running capacity can track activity.

What each agent gains when it owns its kernel: persistence, isolation, and autonomy

An agent can run as root inside its guest and install software without changing another agent’s environment or the host. Its privileges stop at the VM boundary. With a persistent disk, installed packages, working files, credentials, and browser profiles can survive across sessions rather than disappearing with an ephemeral execution layer. Disk persistence must be provided explicitly, because owning a kernel alone does not preserve a workspace.

Amazon Bedrock AgentCore Runtime applies microVM isolation at session scope. Each session receives its own microVM, with state retained across multiple invocations during that session and memory sanitized on termination. That lifecycle supports work extending beyond a single synchronous request. Google Agent Compute Engine, announced October 22, 2026, with customer preview forthcoming, extends the model through per-agent Hyperdisk for workspaces that survive between turns and days. It also removes long-lived credentials from inside the VM, separating workspace persistence from credential residence.

The model enables more than durable files. A browser inside the VM can have its own network namespace, with tabs, cookies, and sessions separated from other agents, while copy-on-write branching of memory and disk supports trying several approaches from one starting state. These capabilities need support from the software around Firecracker as well as Firecracker itself. DigitalOcean MicroVMs, launched in public preview in October 2026, names per-tenant tool and MCP server isolation as one of its main use cases.

The operational gaps that stop most self-hosted Firecracker deployments

Firecracker supplies the isolation primitive. Networking is a frequent obstacle because it provides no CNI plugin equivalent. Operators must manage TAP interfaces, iptables rules, and host routing themselves. Isolated guests depend on those components to communicate as intended without opening unwanted paths. A working VM launch is therefore only an early step toward a production agent service.

Snapshot management introduces a separate scheduling problem. Something must decide when an agent should hibernate, where its snapshot belongs, how long to retain it, and how to restore it when work arrives. Firecracker does not provide that lifecycle out of the box. Sleeping fleets also accumulate storage costs that require an explicit budget.

Host security remains an operator responsibility as well. Kernel lockdown, seccomp profiles for the VMM process, and network egress filtering must surround the guest boundary. Tool authorization is another layer that must be built around virtualization. Open Agent Passport research shows why sandboxed execution limits the harm from a compromise but still allows unauthorized tool calls. Self-hosting therefore means building the networking, lifecycle, host-hardening, and policy infrastructure around the runtime.

What the managed infrastructure layer must provide to make per-agent VMs practical

The scheduler is the economic core of a managed agent platform. It must snapshot idle agents automatically, restore them on demand in under a second, and charge for stored state while leaving idle compute unbilled. This makes active concurrency the primary compute cost driver. A server with room for a bounded number of active VMs can then serve a much larger agent population when only a fraction needs execution at once.

Storage and latency must support the same lifecycle. Each agent needs a persistent volume that keeps its installed packages and working state through sleep and redeployment. Wake latency must stay sub-second when the service is in use. Otherwise, preserving an agent’s environment introduces a user-visible delay that weakens its case against a stateless alternative. The platform must also own TAP management, egress filtering, and per-agent network namespaces, so that adopting a dedicated kernel does not require each application team to reconstruct host networking.

Developer tooling completes the managed layer’s responsibility. CLI, SDK, and MCP server compatibility should reduce deployment to a single push from code to a live agent endpoint. The AgentCore MCP server and CLI illustrate this tooling surface through support for clients including Kiro, Cursor, Claude Code, and Amazon Q CLI. Such interfaces are useful because they expose the agent lifecycle without requiring developers to operate the hypervisor and its supporting machinery themselves.

Authorization and sandboxing as complementary layers, not alternatives

A microVM can keep a compromised agent contained even as that agent does harm through a tool it is allowed to use. A fund transfer or database query does not need to escape the guest to violate policy. The policy decision must occur before execution, at the tool-call boundary, rather than relying on the model to choose correctly or on retrospective evaluation to detect the result.

The OAP research describes sandboxed execution, pre-action authorization, and model-based screening as complementary architectures. Its adversarial testbed found a high rate of successful social engineering under a permissive policy. Under a restrictive pre-action policy, a similar group of attackers had a zero success rate over many attempts. That result supports explicit enforcement at the action boundary. Alignment remains probabilistic at the level of an individual output.

An isolated agent with outbound access can still exfiltrate data, so filtering at the VM’s network namespace must constrain that channel. The complete architecture separates containment, permission, and connectivity rather than asking one mechanism to perform all three jobs. The practical next step is to pair a dedicated agent kernel with pre-action authorization and controlled egress. The platform handles the kernel boundary and network isolation. The developer handles authorization policy.