Replacing the Shared Kernel Model With Per-Agent Firecracker VMs in a Managed Agent Cloud

Firecracker micro-VM isolation for AI agents gives each agent its own guest kernel, memory space, and virtual hardware through KVM, rather than separating processes on a shared host kernel. Replacing containers with per-agent microVMs makes hardware virtualization the compute boundary for untrusted agent code. In a managed agent cloud, that shift works in practice only when snapshot-restore ends idle compute costs and separate authorization controls check tool calls and credentials.

Why container isolation is the wrong default for agents that execute AI-generated code

Linux namespaces and cgroups separate container processes while leaving every container on the host dependent on the same kernel. Namespaces constrain what a process can see, but they do not contain a compromise of that kernel. An agent that writes Python, installs packages, and manipulates file descriptors exposes the host to code that the operator neither authored nor reviewed.

The mismatch is structural. Developer-authored code that passed CI/CD presents a different threat from code produced in response to previously unseen user instructions. Once an agent can write and run programs, the shared kernel’s syscall interface becomes an attack surface. A successful kernel exploit can expose the host and other tenants’ workloads, regardless of their separate namespace views.

The relevant threats extend beyond filesystem access. They include arbitrary network egress, host kernel exposure, cross-tenant leakage, and secret exfiltration through environment variables or /proc. Container restrictions can partially address filesystem and network access, but they do not add an independent kernel boundary. Describing an agent as sandboxed therefore leaves the central security question unanswered.

How do Firecracker microVMs give each AI agent its own isolated kernel?

Firecracker uses KVM for hardware virtualization, giving each microVM its own kernel, memory space, and virtual hardware. The guest kernel is no longer the host kernel. After compromising it, crossing into the host or another tenant’s microVM requires crossing a separate boundary enforced by hardware, which exposes Firecracker’s virtual machine monitor in place of the host’s full syscall surface.

This changes the boundary without needing the footprint of a full conventional VM. With Firecracker’s approximately 125ms boot time and approximately 5MB memory overhead, an agent can have hardware isolation and still start quickly. Those figures describe startup and overhead only. The important architectural change is the smaller, more focused interface between untrusted execution and the host.

Production isolation options include OS process sandboxes, user-space kernels, hardware microVMs, full VMs, and confidential computing. User-space kernels such as gVisor intercept and re-implement syscalls, adding separation without a full VM, though some Linux software faces compatibility tradeoffs and execution overhead. MicroVMs instead retain a guest kernel behind a hypervisor boundary. Andronchik & Lokhmakov’s comparative study separates microVMs, userspace kernels, and OCI containers across its measured architectural axes, making boundary type a meaningful selection criterion.

Why the shared-kernel model breaks specifically in multi-tenant agent fleets

With multi-tenancy, the risk from running code in one environment can spread to other customers. Standard containers can be a reasonable choice for internal workloads that run reviewed code. LLM-generated code adds risks such as resource exhaustion and logic bombs, while custom code supplied by unscreened users calls for a hostile-code threat model. For that last category, hardware virtualization is the minimum acceptable isolation tier.

Cross-tenant data leakage is a concern for compliance. One tenant’s agent must not read another tenant’s memory, data, or credentials, even when its own execution environment is compromised. With a shared kernel, those workloads all depend on the same vulnerable part. With per-agent microVMs, each tenant’s code runs behind its own guest kernel, which sits between it and the virtualization boundary.

But compute isolation cannot tell which customer an agent acts for. A multi-tenant runtime also needs to validate the JWT, extract tenant context, create the isolated session, and restrict access to namespace-scoped memory. The session must keep its identity when it takes external actions. Shared API keys undermine that separation even when execution is isolated, so the recommended pattern gives each agent a short-lived workload identity and routes egress through a policy proxy that injects credentials after verification.

How the industry converged on per-agent microVM isolation in 2026

Amazon Bedrock AgentCore Runtime places each agent session inside an isolated micro-VM for tenant-level compute isolation. It bills vCPU-hours and GB-hours per second, with CPU free during I/O wait. Memory remains billable until the session ends in v1, or until reclamation after 120 seconds of idling in v2. Its isolation model therefore leaves session lifecycle as an important cost variable.

AWS Lambda MicroVMs shipped June 22, 2026, with a dedicated Firecracker microVM for every session. It supports suspension and resumption with memory and disk intact for up to eight hours, billing zero compute while suspended. Suspension changes the economics of waiting between requests. Alibaba Agent Native Cloud launched July 18, 2026, with no public per-unit rate announced, giving the new category another named offering.

Microsoft Foundry Agent Service illustrates a different deployment and billing choice. Foundry-native prompt and workflow agents incur no additional runtime fee, while hosted agents running customer code in containers incur underlying container compute charges. Those charges cover active sessions, including idle timeout windows. By September 2026, the per-user persistent-computer pattern had become a product category, but the offerings did not share one isolation mechanism or one treatment of idle time.

The idle cost problem that determines whether per-agent VMs are economically viable

Most agents are idle most of the time. A persistent agent may need to keep its environment between requests even when it does no useful computation in that time. If keeping that environment takes live memory and compute, idle sessions become the biggest source of costs. At fleet scale, that can make a per-user product unviable despite a sound security design.

Storage changes that calculation by orders of magnitude. Keeping a memory snapshot in object storage costs far less than keeping the same environment on live compute. When providers charge for memory during I/O wait, operators pay to keep agents ready. Providers that charge zero compute during suspension turn the waiting period into a storage expense instead.

AgentCore’s lifecycle rules make shorter idle timeouts a cost-control lever, while Lambda MicroVMs and DigitalOcean MicroVMs bill zero compute during suspension. The distinction is whether an inactive agent must occupy billable compute to remain persistent. Making storage the idle-state resource requires a snapshot-and-restore mechanism fast enough that waking an agent does not compromise the product experience.

Snapshot-restore as the scheduling primitive that makes per-agent microVM fleets tractable

Snapshot-restore serializes the microVM’s memory and disk state to object storage when the agent becomes idle, then restores that state on the next request. With billing based on suspension, charges for compute stop while charges for storage continue. Wake latency is the constraint on this strategy. A restore that takes seconds interrupts interaction, while sub-second wake allows suspension to serve as routine scheduling.

Restoring a snapshot can be faster than cold boot because the guest kernel does not re-initialize. DeltaBox, from Shanghai Jiao Tong University in May 2026, studies a related OS-level checkpoint-and-rollback problem. It records only the differences between similar consecutive states. Its software engineering benchmark and RL micro-benchmark evaluations report checkpoint and rollback latency of 14ms and 5ms respectively, allowing more execution nodes to be explored within fixed time budgets.

AgentZip, published in September 2026, addresses memory compression for high-fanout agent sandboxes. Its focus becomes relevant when a host must accommodate hundreds of paused snapshots. These studies look at different parts of keeping state, so their results do not give one Firecracker restore result that holds in all cases. OS-level checkpointing also complements agent-level checkpoints of conversation state and workspace.

Runtime scheduling must fit the product’s data-isolation design. Silo separates each tenant’s runtime, vector index, and API endpoint, while Pool shares infrastructure with tenant_id filtering. Bridge combines pooled low-risk tenants with siloed high-risk tenants. When tenants supply custom tool code, runtime microVM isolation keeps their kernels separate in a way that logical data filtering alone cannot.

What persistence actually means when each agent has its own kernel

Persistence lets an agent continue work in an environment it has already changed. Installed packages stay installed, filesystem writes last through suspension, and memory that is restored can keep browser state and long-running processes. The developer gains continuity beyond conversation history.

Containers can retain state through external coordination, but stateless execution requires the application to serialize and restore what it needs. A persistent microVM instead makes disk state part of the agent’s environment, with memory snapshots preserving execution state across sleep. Disk and memory serve different roles here. Keeping files alone cannot keep a browser or process running, and even after memory is restored, the application still needs to manage reasoning context.

The agent can install tools, break its environment, and rebuild without modifying another tenant’s guest kernel. This supports the per-user computer model in concrete terms, including a continuing workspace, browser session, and tool installation. Credential continuity still needs a separate policy, because restoring an environment must not be treated as permission to retain or reuse unrestricted secrets.

Pre-action authorization as the layer that completes microVM isolation

A microVM contains execution, while authorization of actions such as a fund transfer remains a separate responsibility, and an isolated agent with permitted network access can still make an unauthorized API call or exfiltrate accessible data. Prompt injection remains a risk inside the guest.

Uchibeke’s Open Agent Passport paper identifies this gap as the need to authorize actions before execution. Model alignment operates probabilistically at training time, while post-hoc evaluation examines actions retrospectively. Neither can enforce policy deterministically before each tool call. The proposed authorization layer intercepts calls before execution and evaluates them against declared policy, covering actions such as database queries, shell commands, and sub-agent delegation.

MCP’s role as the de facto tool-connectivity layer by mid-2026 makes its server boundary an increasingly important authorization point. The July 2026 specification added a stateless request/response core and left infrastructure to manage stateful agent context. The August 22, 2026 roadmap explicitly prioritized agent identity and enterprise-ready security. Tool connectivity and agent state therefore remain distinct responsibilities even when they serve the same session.

Credential injection connects authorization to the isolated runtime. Credentials remain outside the guest and are injected at the policy boundary after verification, scoped to the session’s workload identity. A compromised guest cannot extract credentials it was never given. The resulting design combines microVM isolation at the compute layer, pre-action authorization at the tool-call layer, and credential injection at the egress layer.

What this architectural shift means for teams building agent-native products

A managed agent cloud takes on more than VM startup. Building the equivalent environment requires bare-metal Linux with KVM, TAP interface management, IP tables, routing, rootfs assembly, snapshot scheduling, and fleet lifecycle management. Those tasks can take days before the first agent runs. Providing them as infrastructure lets product developers focus on agent logic.

Per-user agents keep a computer for each human user, task-scoped agents use ephemeral microVMs that are destroyed when the task is done, and fleet agents use multi-tenant pools with isolation tiers that match the risk to the data. Their retention policies differ, but they draw on the same primitives. These include an isolated kernel, persistent disk where required, fast wake, and an idle-cost model that does not require continuous compute.

For teams building these products, the architectural lesson is to evaluate those primitives together. Strong isolation without affordable suspension makes persistent fleets expensive, while persistent state without scoped identity leaves external actions insufficiently controlled. A managed Firecracker deployment on bare metal can combine a real guest kernel and persistent disk with sub-second snapshot wake, charging idle agents only for storage. That foundation remains useful across LLM vendors and tool providers because execution boundaries, state retention, and authorization do not depend on which model calls the tools.