From Shared Kernel to Per-Agent Micro-VM Without Rebuilding Your Orchestration Layer

Firecracker micro-VM isolation gives each AI agent its own Linux kernel behind a hardware virtualization boundary, rather than sharing the host kernel through containers. Moving to that model is a targeted infrastructure swap at the execution boundary. Scheduling, routing, tool integrations, and agent logic can stay as they are while the execution layer adds VM isolation and snapshot-based sleep and restore.

Why shared-kernel containers create a structural problem for agentic workloads

A kernel vulnerability exploited inside a Docker container can compromise the host and other containers running on it. Those workloads share the same host kernel. For agents that write Python, install packages, and manipulate file descriptors, the exposed kernel surface is reachable by code the model generates or a user supplies. The code is now untrusted execution rather than application code written in-house, but the security boundary stays the same.

That mismatch becomes more consequential in multi-tenant systems. Namespace separation leaves tenants dependent on the same kernel, even when their data and permissions must remain separate. Model alignment cannot strengthen that boundary, nor can it substitute for authorization before a tool executes. Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents identifies pre-action authorization as distinct from sandboxed containment. The distinction is essential because preventing an unauthorized action and containing a compromised execution environment are different jobs.

How do you give each AI agent its own isolated kernel?

A Firecracker micro-VM runs a dedicated Linux kernel on hardware virtualization through KVM. So a guest-kernel compromise on its own does not compromise the host kernel or another guest. Crossing that boundary requires an escape beyond the guest. Firecracker’s virtual machine monitor is written in Rust and exposes a deliberately small device model, reducing the attack surface compared with general-purpose hypervisors. Hardware isolation is a stronger boundary that still carries the possibility of escapes.

The runtime options differ in where they draw that boundary. Docker workloads share the host kernel, while gVisor inserts a user-space kernel between workloads and the host. That makes gVisor an intermediate option, with stronger isolation than Docker but compatibility gaps for some Linux software. Firecracker instead provides a separate guest kernel, with roughly 125ms boot time and roughly 5MB of memory overhead per VM. Those figures make per-agent isolation operationally plausible.

AWS built Firecracker for Lambda and Fargate, while Google built gVisor to isolate production workloads at scale, including GKE Sandbox, Cloud Run, and App Engine. Azure uses Hyper-V isolation for Dynamic Sessions and hardware-isolated microVMs for ACA Sandboxes.

How snapshot-restore makes per-agent micro-VMs economically viable

The main cost objection is idle compute. Agents often wait for a human response, an API, or another task, leaving an always-on VM allocated without useful work. Snapshot-restore changes the dormant agent from a running process into stored state. The runtime boots a micro-VM, snapshots its memory and disk, and restores it when work resumes. During that pause, the economic burden shifts from CPU allocation to snapshot storage.

Copy-on-write makes restoration useful beyond simply stopping idle VMs. Restored guests can read shared template memory pages, with private physical pages allocated when a guest writes to them. A fleet restored from one template therefore need not multiply template RAM usage linearly. The same mechanism supports session forks from a warm parent, such as parallel candidate patch branches. Each candidate need not start with a full cold boot.

The benefit depends on actual waiting time. When only a fraction of tenants are active, snapshot storage for dormant tenants can cost a small fraction of keeping their compute live. But each suspend-resume cycle adds snapshot I/O overhead. For agents making high-frequency tool calls throughout the day, an always-on container may still be cheaper.

Where the execution boundary sits inside a typical orchestration stack

The execution boundary sits where a tool call becomes running code. Above it are the LLM reasoning loop, orchestration state, routing, and the interface through which tools are invoked. Below it is the environment that executes those tools. This separation makes the migration narrow. The component deciding what runs next need not be the component providing the kernel in which it runs.

LangGraph, Microsoft Agent Framework 1.0, and Mastra manage concerns such as state, routing, checkpointing, and multi-agent coordination. They are not inherently coupled to the execution environment underneath them. MCP, the Model Context Protocol, standardizes connections to tools and data sources, while A2A addresses agent-to-agent communication. Both sit above the execution boundary. The environment that receives tool calls can change while those protocols and the agent’s business logic stay the same.

Authorization also has a place at this seam. The Open Agent Passport specification, or OAP, intercepts tool calls synchronously, evaluates declarative policy before execution, and produces a cryptographically signed audit record. The micro-VM constrains the environment in which an allowed action runs, so authorization and containment remain complementary.

The targeted infrastructure swap: what changes and what stays the same

What changes is the execution runtime and its lifecycle management. Docker/runc gives way to Firecracker or an equivalent micro-VM runtime, while an adapter can preserve the interface already called by orchestration. The execution layer must then decide when to snapshot, where snapshots live, and how to restore them on demand. This is new infrastructure work. It does not require moving workflow decisions into the VM scheduler.

Network and resource configuration also move to VM granularity. Per-VM network namespaces may require changes to egress policies and credential injection, while VM resource allocations replace per-container limits. The team also has to maintain a sandbox pool with a minimum number of warm, pre-restored environments ready for requests. That pool avoids cold-start latency for the large majority of task requests without changing the agent’s routing logic.

What stays the same is the orchestration framework and its state, checkpointing, and routing behavior. MCP server configuration, tool definitions, prompt structure, agent business logic, and A2A communication patterns can remain intact. If a pre-action authorization layer is already in place, it stays too. Docker Sandboxes illustrates this interface-based approach through its sbx CLI for spawning, executing, and destroying microVM environments. Its custom VMM is not Firecracker, but the interface is designed to support existing agent runtimes without internal changes.

Persistent state across sleep cycles: what the agent runtime must preserve

An agent’s continuity depends on more than its orchestration checkpoint. Files, installed packages, process memory, and browser sessions can all be part of work that is still unfinished. Stateless serverless execution discards in-process state between invocations, so that continuity must be reconstructed elsewhere. A plain container can retain a volume, but restarting it still requires explicit handling of process memory and other runtime state. Disk persistence alone is not execution continuity.

A micro-VM snapshot preserves guest memory, disk, kernel state, and open file descriptors. That allows an agent to resume suspended execution rather than rebuilding its environment through agent-level initialization logic. Human-in-the-loop work is a natural fit. The VM can sleep while approval is pending and restore when the human responds, without keeping compute allocated throughout the wait.

Credentials require a separate lifecycle decision within that persistence model. They can be injected at the VM boundary and cleared on snapshot, keeping raw secrets out of the model’s context rather than treating every credential as state to retain. Persistent execution therefore does not mean preserving every byte indiscriminately.

Per-user agent fleets and what structural isolation requires below the model

A shared agent with tenant context inserted through a system prompt is not a tenant-isolation boundary. An instruction to “only act for customer X” still relies on the model to respect that separation. One successful prompt injection or misconfigured variable can expose another tenant’s data or spend. A demonstration can conceal this structural weakness. In production, isolation must sit below how the model reads instructions.

In a per-user VM design, each tenant’s agent has its own kernel, filesystem, and network namespace. Crossing that runtime boundary requires more than persuading the model to ignore a prompt. The budget for each session must be checked before every model call, while per-tool allow/ask/deny policies decide whether actions go ahead or wait for human review. VM separation does not authorize tool use.

The OAP paper reports a zero-percent success rate for social-engineering attempts under its restrictive pre-action policy, despite successful attacks against the model under a permissive policy. Per-VM metering adds a separate operational benefit by making tenant compute attribution more direct than accounting across shared node resources. As the number of tenants grows and compliance requirements and SLA expectations rise, runtime isolation makes sense as a base for the architecture.

Running per-agent micro-VMs without managing bare-metal scheduler complexity

The snapshot scheduler belongs at the platform layer. It must track VM state, manage snapshot storage, restore dormant agents, and maintain enough ready capacity for incoming work. These responsibilities sit beneath the stable orchestration interface, where infrastructure built for the job can handle them without each agent product team having to run its own bare-metal scheduler.

For an agent product to feel responsive, wake latency must be under one second, and a fast cold-boot figure alone does not show that it is. Maintaining the warm sandbox pool is ongoing work too. The execution platform must provide persistent disk, real kernel access, and package installation privileges as runtime primitives. A Firecracker-based platform on bare metal can offer these features without exposing how they are configured to agent code.

The intended developer workflow is correspondingly narrow. A team pushes agent code and receives a live API endpoint rather than writing Firecracker configuration or managing snapshot storage. This separation leaves the platform responsible for fleet sizing and sleep-wake behavior. When it absorbs those responsibilities, one VM per end user becomes a practical product primitive rather than a requirement to operate continuously allocated infrastructure for every user.

What to migrate first and what to leave alone

The lowest-risk migration starts with the highest-risk execution context. For a team planning the move, that means agents that run LLM-generated code, handle user-supplied input, or work across tenants. Orchestration configuration, MCP server definitions, agent business logic, and inter-agent routing should stay as they are at first. Limiting the change to execution makes it possible to validate the new boundary without also changing how the application chooses and coordinates work.

Before fleet rollout, the team should validate snapshot-restore on a single agent type. That validation needs to establish sub-one-second restore latency, persistent state across suspend-resume, and working per-VM egress and credential injection. The warm pool also needs sizing and burst-load testing before production traffic arrives. Pool starvation is a common early rollout failure. The team needs to check costs separately for agents that really are always-on, since putting them to sleep over and over may do little to help.

Once the execution layer is established, pre-action authorization should be added at the tool-call boundary if it is not already present. The resulting stack retains its orchestration layer, gives each agent an isolated VM, and preserves task state through turns and human approval pauses. Fleet economics then follow active work and dormant snapshots rather than continuous compute allocation for every agent.