Safe Code Execution Inside Agent Micro-VMs
Firecracker isolates agent code execution with its own kernel and network controls.
To run code safely inside agent micro-VMs, the isolation boundary must be built for code whose author can be hijacked as it works. Firecracker micro-VM isolation for AI agents gives each workload its own guest kernel behind hardware virtualization. That boundary must work with per-task ephemerality, default-deny network controls, and pre-action authorization to contain both execution risks and unauthorized actions.
Why AI agents executing code are a different threat model than traditional untrusted-code problems
Johann Rehberger’s ZombAIs incident demonstrated the threat in Anthropic Claude Computer Use public beta. The agent navigated to a page containing a hidden prompt injection payload, read it, downloaded a binary, ran chmod +x, executed it, and connected to a command-and-control server. It succeeded on the first try, on an uncontained host machine. The attacker did not need to author the agent. External content redirected an agent that already had the ability to act.
The code author is nondeterministic, can be hijacked mid-task, and may execute thousands of commands without a human reviewing the next command. A web page, file, or tool result can become an instruction source, so commands derived from external content must be treated as attacker-controlled. Trust cannot rest on the model alone. Isolation is the architectural response to that uncertainty, while a disposable environment limits what a compromised session can leave behind.
The isolation spectrum and where shared-kernel containers fall short for agent workloads
The isolation ladder begins with language-level sandboxes such as RestrictedPython and JS VM contexts. These restrict execution within an interpreter, but the interpreter was not designed as a security boundary, and determined code repeatedly escapes such restrictions. They can contribute defense in depth as supplementary protections. Containers such as Docker with plain runc move the boundary outward through namespaces and cgroups. That is a real improvement for trusted, internally written code, but every container still depends on the host kernel.
For unattended, multi-tenant agent execution, that dependency is the disqualifier. An agent can write Python scripts, install packages, and work with file descriptors, so code shaped by adversarial inputs can reach a broad shared syscall surface. A kernel vulnerability can turn one container’s compromise into a threat to its neighbors. Configuration does not remove that shared dependency.
User-space kernels such as gVisor form the next step. gVisor intercepts and re-implements syscalls rather than letting the sandboxed program talk directly to the real kernel, providing stronger separation than containers with less overhead than a full VM. It is a reasonable answer for some workloads. Compatibility gaps can affect Linux software, however, and syscall mediation is not the same boundary as a separate hardware-isolated guest kernel.
Micro-VMs, including Firecracker, Kata Containers, and libkrun, cross that boundary by giving workloads their own guest kernels on hardware virtualization. KVM provides this on Linux, while libkrun also supports Apple Hypervisor.framework on macOS. To escape, code must cross the virtualization boundary, which takes more than exploiting the shared Linux syscall interface. Confidential computing adds a further protection through AMD SEV-SNP or Intel TDX, using hardware-encrypted memory isolation to protect sandbox data even from the host OS and hypervisor. That addresses regulated-industry needs, but it is not the general-purpose starting point for agent sandboxing.
How Firecracker micro-VMs give each AI agent its own isolated kernel
AWS built Firecracker to run millions of untrusted workloads, and it powers Lambda and Fargate. Its stripped-down device model reduces the surface exposed across the guest boundary, while hardware virtualization separates the guest kernel from the host. A guest exploit is not automatically a host exploit. Reaching the host requires breaking through KVM and the hardware virtualization boundary. This is the decisive difference from sharing a kernel among tenants.
Within that boundary, each agent gets its own kernel, filesystem, and network namespace. It can install packages, break its environment, and rebuild without making those changes part of a neighboring agent’s environment. Packages from potentially untrusted sources such as PyPI and npm remain inside the guest’s isolation boundary. This does not make the packages trustworthy. Their execution depends on a boundary designed for untrusted workloads.
Snapshot-restore also changes the historical cold-start objection to VMs. Implementations that restore already-booted snapshots can deliver live, isolated environments in milliseconds rather than cold-booting each task or maintaining an idle warm pool. AWS builder content describes a snapshot-and-restore scheduling model for Lambda MicroVMs, but that capability should not be assumed of every Firecracker deployment. Google’s October 22, 2026 announcement of Agent Compute Engine, before general availability, is another signal toward micro-VM-based agent execution, with broadly deployed behavior still unproven.
Ephemerality as a first-class security property, not just a cleanup convenience
Isolation limits where a compromise can spread, while ephemerality limits how long it can survive. A long-running sandbox accumulates credentials, partial writes, installed packages, and data from earlier tasks. Each addition can become an attack surface for the next session. A fresh session starts from a known-good snapshot rather than inheriting whatever the previous session left behind.
One microVM remains alive for the task’s duration, keeping its working directory, installed dependencies, and running processes available across steps, and is then destroyed. A mandatory ttl_seconds parameter provides a dead-man’s switch if the agent loop crashes before cleanup executes. Without that backstop, zombie VMs accumulate state and cost. Ephemerality must be enforced even when the code responsible for cleanup fails.
Snapshot-restore can keep a working directory, memory, and artifacts across sessions even when the execution VM itself is thrown away. That distinction requires care because restoring compromised execution state would also restore the compromise. Vercel Sandbox, generally available January 31, 2026 and built on its internal Firecracker orchestration platform Hive, illustrates the economic fit through active-CPU billing that excludes I/O wait time.
Network controls as the third leg of the containment model
A hardware boundary does not block an internet connection. An injected agent can attempt to exfiltrate data through HTTP, DNS, or any other open egress path without escaping its microVM. Default-deny egress is therefore the recommended starting posture, with explicit access only to the domains or IP ranges needed for the task. An allowlist stops the agent from freely choosing to connect next to an attacker’s infrastructure.
Service credentials should be short-lived and added outside the microVM when traffic leaves it, rather than stored inside the sandbox where agent-generated code can read them. Google’s announced architecture calls for this kind of external injection. An agent can reach an approved service without keeping the service credential inside the environment where it runs.
Tool architecture can make this boundary more useful. MCP servers expose capabilities through lightweight JSON-RPC 2.0 endpoints, moving tool calls out of the agent binary and across a network boundary that can be firewalled and audited. Different tenants can get different tool sets without changes to the code, and calls that cross the boundary can be logged. The boundary becomes an enforcement point for capabilities. The scope of network controls remains limited to reachability, however.
Why sandboxing alone does not close the authorization gap
Uchibeke et al.’s March 2026 research points to the need for pre-action authorization. Agents have credentials for tool calls such as fund transfers, database queries, shell commands, and sub-agent delegation, but lack a standard mechanism for enforcing permission before execution. Model alignment operates probabilistically at training time, while post-hoc evaluation examines actions retrospectively. Neither is deterministic enforcement at the individual tool call. A sandbox determines where an action runs, while authorization of its purpose remains a separate concern.
An agent allowed to call an API can still go over a spending limit, send to a recipient outside an allowlist, or access a forbidden data class while staying inside a perfectly isolated VM. No kernel escape is required for those failures. Isolation, network restrictions, and resource controls limit the risks of running code, including cross-tenant access and exfiltration paths. They do not themselves express the meaning of a permitted transaction.
The study’s adversarial testbed found that social engineering succeeded against the model at a high rate under a permissive policy. Under a restrictive Open Agent Passport policy, attackers had a zero success rate across hundreds of attempts. That result is limited to the tested policy and testbed. OAP intercepts tool calls synchronously, evaluates a declarative policy before execution, and produces a cryptographically signed audit record. The policy layer can enforce quality gates, operational contracts, and compliance controls as well as security constraints, complementing the sandbox.
The full containment architecture — isolation, ephemerality, network controls, and authorization working together
Hardware isolation separates the executing guest from the host and neighboring tenants, while destruction and TTL bound the lifetime of its execution state. Egress controls limit where traffic can go, and external credential injection keeps service secrets outside the guest. Pre-action authorization evaluates the requested operation before a tool executes it. These controls answer different questions, so none can substitute for the others.
AWS Bedrock AgentCore grounds the session boundary in a managed-service example by using one Firecracker microVM per session. AWS Lambda MicroVMs and microvm-ctl illustrate a separate implementation pattern with one Firecracker microVM per tenant, identity injected at launch, and conversation memory in RAM. The distinction between those examples is important. The tenant implementation also gives each VM a dedicated HTTPS endpoint, avoiding a shared load balancer that could misroute requests. Its tokens are port-scoped and VM-specific, making one tenant’s credential useless against another tenant’s endpoint.
A tenant’s identity, endpoint, and execution environment have matching boundaries. Authorization then constrains actions taken through that identity, while network controls constrain where those actions can go. Completion or TTL ends the disposable environment. Persistent agent state remains a separate concern, rather than a reason to keep every execution session alive indefinitely.
Why the economics of per-agent VM isolation work at scale
The economic case depends on distinguishing an agent’s existence from its active compute time. Most agents are idle most of the time, so a snapshot-and-restore scheduler can make dormant agents consume only storage. Per-user isolation need not mean an always-on VM. AWS builder content says that running a VM briefly and then keeping it suspended for several hours costs a small fraction of what an equivalent always-on VM costs. It places a fully idle tenant at a few cents per month and a thousand dormant tenants at roughly $49/month of storage.
Setting suspendedDurationSeconds so that the long tail of dormant tenants is terminated and relaunched from a snapshot on demand ties quota to the active subset of signed customers. The distinction is especially useful for per-user agents. A product can keep a user’s agent state without running a workload around the clock for every registered user. Storage preserves continuity while restored compute serves the active window.
These economics depend on a Firecracker implementation’s snapshot scheduling, how suspension works, and billing rules, which decide whether an idle agent stops using compute that must be paid for. When those mechanisms work together, however, the long tail of dormant users becomes primarily a storage cost. Per-agent microVMs then become a workable way to deploy agent-native products, with security boundaries that fit the code’s threat model and can stay strong even with idle infrastructure.
