How Firecracker Isolation Depth Varies Across Agent Cloud Platforms

Firecracker micro-VM isolation for AI agents gives each agent its own Linux kernel behind a hardware virtualization boundary, while containers share the host kernel. A platform’s isolation depth depends on its device configuration, guest kernel, network policy, snapshot controls, and host protections, together with the services around the VM.

Why the container-versus-microVM debate misses the real question for agent builders

A Docker container separates processes through Linux namespaces and cgroups, but its system calls still reach the host kernel. A vulnerability in that shared kernel can expose the host and other tenants’ data. The shared kernel is the central concern. Firecracker instead places a hardware virtualization boundary between the guest and host, using KVM and CPU support such as Intel VT-x or AMD-V.

That distinction answers how to give an agent its own isolated kernel without relying on container isolation. It does not settle which agent cloud to choose. An agent with its own kernel can still send secrets through an allowed network connection, and hardware virtualization does not set who can read a stored snapshot. Once platforms choose microVMs, what actually differs between their deployments?

What Firecracker's design does and does not guarantee out of the box

Firecracker combines a small virtual device model, a hardware boundary per guest, and a companion jailer that constrains the virtual machine monitor, or VMM. Each guest has its own Linux kernel running on KVM. The device model excludes USB, GPU pass-through, and arbitrary PCI hot-plug, while virtio device hotplug is in Developer Preview only. When fewer devices are exposed, a guest has less VMM code to attack.

The jailer provides another line of containment around the Firecracker process. It uses a chroot to restrict filesystem access, while a seccomp filter limits permitted system calls to 24. This protects a different layer from the guest boundary. If virtualization is compromised, restrictions around the VMM process can still limit what it reaches. Because they boot fast and have low per-VM overhead, thousands of microVMs can share a host while each keeps its own guest kernel.

Firecracker alone does not set network egress policy, filesystem scope, credential handling, snapshot permissions, or the guest kernel version. Nor does it determine what other services run on the host. Containers, gVisor, Firecracker microVMs, and WebAssembly are distinct runtime isolation options within a complete security stack. A sound sandbox also needs a lifecycle control plane, an egress proxy, a scoped filesystem with snapshot controls, and a secret broker.

The five dimensions on which Firecracker deployments actually differ

The first dimension is VMM configuration and device surface. Firecracker starts with a deliberately small device model, but the platform still decides what the guest can use. The exposed configuration matters because additional virtual devices expand the hypervisor attack surface. A weak configuration gives untrusted code more code that handles devices to attack.

The second dimension is guest kernel ownership and hardening. A platform may control the kernel and its updates, or let customers bring their own. That choice establishes who must track versions and patch kernel CVEs. The hypervisor’s protection is limited to the guest boundary. A flaw in the guest kernel can let an attacker take over the guest even when the host stays isolated.

The third dimension is outbound network access, usually called egress. Traffic may be unrestricted, sent through a controlled proxy, or denied by default. A prompt-injected agent does not need a VM escape to send readable environment variables or credentials to an external destination. Open egress enables data exfiltration through an otherwise intact sandbox.

The fourth dimension is snapshot and state access. The key questions concern who can read or restore snapshots, whether storage is encrypted and tenant-isolated, and what state a resumed VM receives. A snapshot is stored execution state. Its permissions must protect the tenant whose data is in it. Weak controls enable cross-session leakage or access to another tenant’s state.

The fifth dimension is host co-tenancy and jailer configuration. The platform controls the VMM’s chroot and seccomp restrictions and the other services sharing its physical host. An elevated co-tenant service or an overly permissive jailer can weaken containment. A weak host configuration can let an attacker get around the protections inside the guest.

How major platforms configure these dimensions in practice

AWS Lambda MicroVMs launched June 22, 2026, in five regions on ARM64, with one Firecracker VM per user session or agent. Its launch process accepts a Dockerfile, initializes the application, and snapshots running memory and disk state. Subsequent launches resume that initialized snapshot. Sessions do not share a guest kernel. The service preserves state for up to eight hours and reduces suspended machines to idle cost.

Lambda MicroVMs also integrates with CloudWatch logs, IAM roles, and VPC networking, with authentication through service-provided JWE tokens. Outbound access is configurable for the public internet or a VPC. That leaves an important policy decision with the team. Configurable egress is not the same as default-deny egress. The service complements Lambda Functions with a resumable lifecycle.

AWS Agent Sandboxes on Lambda MicroVMs, published July 22, 2026, adds an agent-oriented developer API to that primitive. It uses JSON-RPC 2.0 over WebSockets for inline tool calling into per-session Firecracker microVMs. The distinction here is the API and workload model. An interface built for programmatic tool calling makes the underlying runtime accessible to agents, but does not by itself answer questions about snapshot permissions or guest kernel hardening.

Kata Containers takes a different route through standard OCI container APIs and Kubernetes tooling. It supports Firecracker, Cloud Hypervisor, QEMU, and Dragonball as selectable backends. The backend in use therefore needs to be checked on its own. Kata and gVisor are the two supported isolation backends for Kubernetes-based agent deployments through the kubernetes-sigs/agent-sandbox controller. Kata offers a path to hardware isolation without abandoning Kubernetes workflows, but its name alone does not identify the VMM in use.

GKE Agent Sandbox uses gVisor. Its Sentry user-space kernel intercepts system calls before they reach the host, so agent code does not directly use the host kernel syscall surface. This syscall-based isolation trades hardware-enforced separation for syscall compatibility, with very fast boot and a useful performance-to-isolation balance for agents making limited I/O calls. It is designed for RL and orchestration of large numbers of secure environments.

Azure Container Apps dynamic sessions uses Hyper-V isolation, placing it in the hardware virtualization class without using Firecracker. It integrates with Azure AI Foundry agents and powers sandboxed code interpreter sessions in Azure Logic Apps agent workflows in public preview. Its fit is tied to that ecosystem. Across these platforms, the differences include the isolation primitive, lifecycle, networking choices, and API surface. The available platform descriptions do not establish every snapshot, jailer, or kernel policy, so those details require evaluation before the platforms can be ranked.

Where snapshot and resume mechanics change the isolation calculus

Snapshot restore lets each agent keep a machine without having to leave every idle session running. Firecracker can pause a microVM, preserve memory and disk state, and resume in tens of milliseconds. Files, installed packages, browser sessions, and in-memory state are still there when it resumes. That continuity is the operational benefit. A paused machine needs storage rather than a live allocation of RAM and vCPU, which suits workloads where most sessions spend most of their time idle.

A snapshot can keep data that was sensitive while the machine was running, so who can access it needs more care than ordinary image distribution. Storage permissions become part of tenant isolation. If another tenant can read or restore that state, the VM boundary may remain intact while confidentiality fails. Encryption at rest and control over the encryption key belong in that assessment, especially for healthcare and financial services workloads.

Fork-based launch makes the distinction sharper because many VMs can start from one snapshot. That is useful for evals and RL rollouts, but the shared starting image must be clean and free of secrets. Otherwise, each fork can get credentials meant for another task. Resuming a tenant’s own session and cloning a reusable base are different state-management jobs. Builders should therefore ask not just whether a platform uses Firecracker, but how it manages snapshot storage, encryption, and tenant isolation.

What surrounds the microVM matters as much as the microVM itself

The five dimensions describe different ways the full sandbox can lose protection. Device exposure and kernel hardening govern the execution environment, while egress and snapshots govern where data can go. Jailer settings and host co-tenancy govern containment outside the guest. None is an academic distinction. A correctly configured VM can still sit inside a system that grants an agent too much network access or exposes saved state through a privileged API.

Network policy is the clearest example because exfiltration need not involve an escape. A prompt-injected agent can use an open outbound connection to reach infrastructure that an attacker controls. A strong posture denies egress by default and allows specific domains through a controlled proxy, rather than relying on application logic to restrain an agent with open internet access.

Secrets need a separate boundary for the same reason. A guest that can read credentials from its environment can be directed to transmit them. A secret broker keeps credentials out of baked-in guest images and reusable snapshots, but readable credentials still make egress controls essential. These controls address different parts of the same path.

The control plane adds another privileged surface because it creates, suspends, resumes, and destroys microVMs. An attacker who takes over the control plane can launch images they control or expose other tenants’ snapshots. The jailer cannot substitute for API authorization. Nor can guest protections neutralize an unrelated service with elevated host privileges. A well-configured stack joins the hardware boundary to a restricted control plane, controlled egress, a scoped filesystem with protected snapshots, and brokered secrets, with the VMM itself jailed.

How do you evaluate an agent cloud's actual isolation depth before committing?

You need to request configuration details rather than accept a Firecracker label as the answer. Ask which virtual devices are exposed and whether the VMM runs jailed under chroot and seccomp. Ask what the syscall allowlist permits. Then establish who owns the guest kernel, which version runs, and how kernel CVEs are patched.

For network and state controls, ask whether egress is denied by default and how domain allowlisting works. Ask how snapshots are stored, how they are encrypted, how they are kept apart between tenants, and whose key protects them. Session boundaries need an explicit answer too. Can a machine get another session’s state when it resumes, and can credentials end up in base images or snapshots? For healthcare, financial services, and insurance workloads, encryption and egress controls belong in the infrastructure compliance assessment.

Control plane access deserves the same precision. Ask who can invoke create, destroy, and resume APIs. Ask what a compromised control plane credential could reach. Ask what else shares the host and whether those services have elevated privileges. These questions expose the reach of a single failure. They also establish which controls the platform supplies and which remain the customer’s responsibility.

Finally, evaluate lifecycle and pricing together with isolation. Persistent agent boxes suit long-lived tasks because they preserve state instead of forcing its reconstruction on every invocation. The useful shape is a machine that sleeps when idle and wakes in roughly a second, with per-second billing, no idle charges for sleeping machines, and no minimums. There still needs to be a clear policy for how snapshots are stored and protected. For computer-use agents, eval pipelines, and RL rollouts, a well-chosen stack combines that resumable lifecycle with hardware isolation and surrounding controls the agent cannot configure away.