Cloud Platforms That Use Firecracker for AI Agent Hosting

Firecracker micro-VM isolation for AI agents gives each agent its own kernel behind a hardware virtualization boundary, rather than sharing the host kernel as standard containers do. Cloud platforms that use Firecracker make that boundary a foundation for running untrusted, model-generated code. To be ready for production, it needs credential isolation, network controls, persistent state, and billing that does not charge idle agents as active machines.

Why AI agents broke the trust model that containers were built for

An incident with a computer-use agent shows how agents can be at risk when they browse and act on external content. Indirect prompt injection can turn that content into instructions to execute hostile payloads. The broader class of attack has been formally analyzed since 2023. Its significance for hosting is straightforward, because the runtime must contain code whose behavior was not approved before execution.

Standard containers use Linux namespaces and cgroups, but their tenants share the host kernel. That is adequate for internally written, CI-vetted code, but a host-kernel vulnerability exposed by one tenant can compromise neighboring workloads. Agents break this trust assumption because running model-generated or user-supplied code is part of their normal work. A coding agent with shell access can also damage production systems through hallucination, without an attacker directing it.

The isolation primitive sets how far the damage can spread when a session fails or is compromised. Restricting a process is not the same as giving it a separate kernel. Maritime makes Firecracker isolation a foundational requirement for precisely this untrusted-code model. For agent hosting, the VM boundary is a security decision rather than a performance optimization.

What runtime isolation options exist for untrusted AI agents in production?

The isolation spectrum is a decision ladder based on what an attacker must defeat. At Level 1, Docker/runc containers provide namespace and cgroup separation, but retain the shared host kernel. They are the fastest and weakest option in this framework, appropriate for trusted code. At Level 2, gVisor intercepts and re-implements syscalls in a user-space kernel, placing another boundary between the application and the host kernel.

Level 3 changes the boundary from process separation to hardware virtualization. MicroVM approaches including Firecracker, Kata Containers, and libkrun give each workload its own kernel through KVM. A guest-kernel exploit alone is not enough to reach the host or neighboring VMs, because escaping also requires defeating the hypervisor boundary. Firecracker combines this separation with boot times under 125 ms and roughly 5 MB of memory overhead per VM.

That combination makes a dedicated kernel practical for both individual agents and large application deployments. Snapshot-restore adds sub-second wake latency, allowing platforms to schedule isolated agents without keeping every VM active. Further up the spectrum, Level 5 confidential computing uses AMD SEV-SNP or Intel TDX to protect memory even from the hypervisor. That extra protection matters for regulated workloads that handle PII or financial records, but it meets a need that goes beyond ordinary guest-to-host isolation.

What Firecracker is and what it was originally built to do

AWS open-sourced Firecracker in 2018 to replace QEMU inside Lambda and Fargate. It was first built for density, to give each serverless customer's workload its own kernel without the overhead of a general-purpose hypervisor. Firecracker reduces the VM to a REST control API, a minimal device model, and a stripped-down Linux kernel. It omits BIOS and legacy hardware emulation, supporting a design intended to run thousands of VMs per host.

Those serverless constraints closely match agent hosting. Each workload must be kept separate, but the overhead has to be low enough to run a fleet. Snapshot-restore extends that design by resuming an already-initialized environment, avoiding repeated initialization. The distinction matters because restoring an agent workspace is not the same operation as booting a fresh machine.

Firecracker requires KVM and hardware virtualization on the host. That requirement excludes non-virtualization-capable hosts and some cloud environments. Platform selection therefore includes a real infrastructure constraint, even when a managed service hides the underlying fleet.

The platforms that have adopted Firecracker for agent hosting and what each one offers

AWS Bedrock AgentCore reached general availability on October 13, 2025, and expanded again in December 2025. It provides a Firecracker microVM per session within a managed stack covering runtime, memory, gateway, identity, sandboxes, policy, evaluations, and observability. AgentCore Runtime supports workloads lasting up to 8 hours on microVMs or up to 14 days on instances. Its March 2026 stateful MCP server features added dedicated session microVMs, context maintained through an Mcp-Session-Id header, interactive input, and progress updates.

AWS Lambda MicroVMs launched in June 2026 as a serverless primitive for user-generated and AI-generated code. Builders create an environment from a Dockerfile, snapshot it after initialization, and restore dedicated instances on demand. When environments are suspended, they keep their state for up to 8 hours with no charge for compute. This makes stateful, untrusted execution an explicit Lambda use case rather than an adaptation of general Lambda functions.

Vercel Sandbox reached GA on January 30, 2026. It runs on Hive, Vercel's internal platform for orchestrating Firecracker microVM clusters across regions. Its execution model targets agents that clone repositories, install dependencies, and run tests. Billing follows actual CPU use rather than wall-clock time, which matters when agents spend much of a session waiting.

Sprites takes a persistent-workspace approach, providing Firecracker microVMs with 100 GB of solid-state storage that survives between sessions. Agents can install dependencies once for use across runs. Deno Sandbox, which entered beta on February 3, 2026, offers a managed service for untrusted or AI-generated code. Its role in this landscape is managed sandbox execution rather than the persistent-workspace emphasis of Sprites.

Superserve combines persistent Firecracker sandboxes with startup under 200 ms and unlimited session duration. Its credentials broker keeps API keys away from agents, while per-sandbox egress rules constrain outbound access. A versioned filesystem with snapshot/rollback adds recovery to persistence. Blaxel emphasizes standby latency, claiming sub-25 ms resume, with each workload running its own kernel.

Tensorlake targets high-concurrency reinforcement learning and agent fleets. Maritime uses isolated Firecracker micro-VMs on bare metal to give each user an agent. Each agent receives a persistent disk, a real kernel, package installation privileges, browser sessions, and wake from sleep in under a second. Its snapshot-and-restore scheduler charges for storage rather than compute while agents are idle, with flat-rate pricing working out to roughly $1 per agent per month.

Isorun exposes a managed Firecracker runtime through command, file, and port APIs. Its lifecycle capabilities include hibernate/resume, snapshot/restore, and forking. SmolVM takes a self-hosted, free and open-source approach, with a Python SDK and CLI. It provides local filesystem mounts, state snapshots, and network egress control.

Firecracker versus gVisor: the real architectural trade-off for agent workloads

gVisor has a credible advantage when startup dominates the workload. Directional figures place its cold starts at roughly 30–80 ms, compared with roughly 100–200 ms for Firecracker. Overhead is estimated at roughly 10–50 MB for gVisor and roughly 4 MB of host overhead for Firecracker. Which option is cheaper depends on the trade-offs behind these ranges.

After startup, gVisor's re-implementation of Linux syscalls can be a deciding factor because software that needs uncommon calls may run into compatibility gaps. Firecracker runs an unmodified Linux kernel, preserving the environment expected by Linux software. That compatibility helps an agent throughout its session when it installs arbitrary packages, runs browser sessions, or does network-heavy work.

gVisor can be a good fit for short, high-density tool calls when their behavior stays container-shaped. Firecracker is a better fit for long, autonomous sessions because its compatibility supports the software agents run and its separate guest-kernel boundary limits the damage a compromised session can cause, even with a small difference in cold-start time. Snapshot-restore further changes the comparison for stateful work by avoiding repeated environment initialization. The relevant latency is the time until the agent can resume useful work.

How snapshot-restore changes the economics of running agent fleets

Idle time carries a greater economic cost than boot time. In a per-user deployment, most agents spend most of their lives waiting for a returning user, a scheduled task, or an external event. Keeping all of an agent's CPU and memory tied up during those waits makes persistence costly. Snapshot-restore separates the cost of retaining an agent from the cost of running it.

It starts with an initialized VM whose state can be saved and resumed. Auto-pause then removes idle compute charges while storage preserves the snapshot. For Maritime, this is the basis of a flat-rate model in which storage accounts for most of the per-agent cost. Its under-a-second wake lets a persistent agent return without rebuilding its environment from scratch.

AWS Lambda MicroVMs applies the same economic principle by stopping compute billing during suspension while retaining state for up to 8 hours. AgentCore Runtime also bills only while the agent is actively working. Its V2 on-demand rates are $0.1276 per vCPU-hour and $0.0169 per GB-hour.

For tasks that spend much of their time waiting, Actual-CPU metering also changes the cost compared with billing for CPU and memory by wall-clock time. However, idle-state storage and warm capacity are different costs. A pre-booted VM pool avoids request-time startup delays but consumes baseline compute. The appropriate pool size therefore depends on traffic shape and latency requirements, rather than the total number of agents whose state exists.

What production agent isolation actually requires beyond the VM boundary

Credential isolation is the first requirement beyond the VM boundary. A compromised sandbox containing live API keys can still exfiltrate data, exhaust billing limits, or reach other services without escaping its VM. AgentCore keeps keys in a credential provider and uses Gateway to inject them into outbound calls, returning only tool results to the agent. Superserve provides a credentials broker, while microsandbox keeps real secrets outside the VM at the runtime level.

Network egress is the next independent boundary. An agent with unrestricted outbound access can send data away or make unauthorized API calls even when host isolation works correctly. The emerging production pattern in 2026 keeps the agent loop and secrets outside the sandbox and routes egress through an allowlist. Cleanroom applies deny-by-default egress with a credential proxy, while iron-proxy and Infisical Agent Vault represent credential-injection proxies that also act as egress firewalls.

Durable state then raises a recovery requirement. Filesystems, memory, installed packages, and browser sessions must survive sleep without becoming an attack surface again and again. Superserve's versioned filesystem and snapshot/rollback provide a way to recover when an agent corrupts its environment. DeltaBox, described in arXiv:2605.22781 in 2026, targets millisecond-level sandbox checkpoint and rollback as a research response to this stateful-agent problem.

Two tenants' agents must not be able to touch the same filesystem or memory page. Isolated CPU, memory, filesystem, and network boundaries must also constrain noisy-neighbor effects and cross-tenant leakage. Firecracker supplies the hardware boundary, but the surrounding platform must preserve those distinctions through scheduling, credentials, state, and network access.

How to choose the right Firecracker-based platform for your agent architecture

gVisor may suit short tool calls that need no package installation, while Firecracker is a better fit for autonomous sessions that use browser control and arbitrary Linux software. AgentCore fits complex managed workloads with explicit session-duration limits. Sprites fits persistent workspaces where dependencies and storage need to survive between sessions.

Vercel Sandbox, Sprites, and Tensorlake meter actual CPU use, making them relevant to wait-heavy execution. For per-user fleets, Maritime combines persistent disks, bare-metal Firecracker isolation, and snapshot-based idle economics around that specific pattern. AgentCore's active-only billing and managed identity, gateway, memory, and evaluations suit enterprise workloads that also need more tools to run and manage them.

State requirements refine the choice further. Vercel Sandbox and Deno Sandbox fit ephemeral execution, while Superserve adds versioned state and rollback to persistent sessions. Isorun exposes lifecycle controls for applications that need hibernation, snapshots, or forks. The distinction is not simply whether a disk persists, but whether the platform's state and recovery model matches the agent's lifecycle.

Operational responsibility is the final filter. Managed platforms take care of scheduling, scaling, and the Firecracker fleet, while another tool lets teams host it themselves. A multi-tenant architecture can separate Gateway, Orchestrator, Scheduler, Memory, and Sandbox into independently operated services, but tenant boundaries remain non-negotiable regardless of who runs them. Builders who understand the trust model choose the boundary first, then evaluate the platform around it.