Safe Code Execution Inside Agent Micro-VMs

To run code safely inside agent micro-VMs, the boundary must treat generated code as untrusted. Firecracker micro-VM isolation for AI agents gives each workload its own Linux kernel behind a hardware-enforced boundary. For agents that execute unreviewed code and need a full Linux environment, that is the isolation primitive that matches the threat model, while persistence and layered controls make it practical for production.

Why agent code execution is a fundamentally different threat than traditional application risk

The ZombAIs incident showed a prompt-injection chain reaching shell execution and a C2 callback when an agent ran directly on the host machine. The chain kept going after the first attempts to download failed. The agent kept following the malicious instructions, so attacker-controlled content led to actions on the host. The failure was not simply an unsafe answer. It was an unsafe action performed through tools.

Deployed application code has a fixed instruction set available for review, while an agent can generate novel code on every invocation. Instructions from webpages, documents, or poisoned tool responses can flow into execution without human review. An agent can also choose API calls and how to use resources in ways that static policies cannot foresee, while persistent memory lets manipulation carry over from one session to the next.

A model that refuses a harmful request in chat can execute it when operating with tool access. OWASP AIVSS assigns a CVSS v4.0 Base Score of 9.4 to the interpreter tool attack scenario in which an LLM-based agent is manipulated into executing attacker-provided arbitrary code. Architecture must therefore constrain what that code can reach after redirection succeeds.

Why the standard isolation options fall short of the agent threat model

For trusted code written in-house, Docker and Podman containers can give enough isolation and are familiar to run. Their namespaces and cgroups separate processes and resources, but those processes share the host kernel. That is the decisive limitation for untrusted execution. A kernel vulnerability reachable from one container can expose other workloads, making arbitrary scripts, package installation, and file-descriptor manipulation a different proposition from running reviewed application code.

If the workload needs a stronger boundary without a full VM, gVisor intercepts and re-implements syscalls in a user-space kernel. This reduces direct exposure to the host kernel, although syscall emulation gaps can break Linux software. Compatibility becomes part of the security decision. WebAssembly and V8 isolates offer sub-10ms startup, but their narrower language and runtime support fits edge functions better than agents needing package installation and persistent Linux file state.

For unreviewed code that needs that environment, a separate guest kernel adds containment beyond what shared-kernel controls can do. If the threat model also covers the host reading sensitive sandbox data, confidential computing technologies such as AMD SEV-SNP and Intel TDX can add hardware-encrypted memory isolation. Containers remain useful for trusted workloads, but their convenience does not resolve the risks of LLM-generated code with credentials, filesystem access, and outbound networking.

How does Firecracker give each AI agent its own isolated kernel?

Firecracker uses KVM hardware virtualization to run each micro-VM with its own Linux kernel. Guest syscalls execute against that kernel rather than the host kernel shared by ordinary containers. The separation changes what an exploit must cross. Compromising the guest kernel does not by itself grant access to the host or sibling VMs, because reaching them requires crossing the virtualization boundary.

That boundary gives untrusted agent code a full operating environment with a kernel of its own, separate from the platform’s kernel. Sibling workloads remain separated at the machine level. This is distinct from confidential computing, whose additional purpose is to protect sandbox data even from the host OS and hypervisor.

Firecracker narrows the exposed machinery through a minimal device model, with far fewer emulated devices than a full QEMU VM. Its Rust implementation eliminates a class of memory-safety vulnerabilities common in C-based hypervisors. Firecracker boots in approximately 125ms with approximately 5MB memory overhead per VM, although repeated boot cost is only part of the economics of an agent fleet.

George Andronchik and Pavel Lokhmakov’s 2026 comparative security study examines host attack surface, information leakage, defense-in-depth stackability, public CVE history, patch cadence, and upstream fuzzing posture. The study finds clear architectural separation between micro-VM, user-space kernel, and OCI container classes, while differences within a class are product-driven. It also identifies an unoccupied combination in the measured product set, namely a micro-VM engine with continuous public fuzzing, leaving that intersection structurally unmeasured.

Why snapshot-restore is what makes micro-VM isolation practical for agents at scale

Snapshot-restore separates the one-time cost of booting a kernel from the recurring cost of starting an agent session. A VM boots fully once, then its memory and device state are frozen to disk for later restoration. Subsequent starts thaw that state. With the associated filesystem state, the restored environment can retain installed packages, browser sessions, and in-memory context.

Warm pools boot VMs ahead of time and hand them out without restore latency, but keep full private RAM set aside for machines that are idle. That tradeoff fits sustained, high-traffic workloads. Snapshot-restore adds a restore step while letting idle compute cost round to zero, and copy-on-write sharing lets restores of one template share read-only memory pages. Resident memory cost can therefore grow sublinearly with sandbox count.

Human-in-the-loop work makes the difference especially clear. An agent may wait seconds or hours for a response, during which its full state can be parked to disk and host compute released. Serializable machine state also supports forking a warm parent for parallel hypothesis evaluation, rather than building every branch from a cold environment. But each suspend-and-resume cycle adds snapshot I/O, so an idle timeout that is too short slows down chatty tenants. Agents active throughout the day may be better served by an always-on model.

What full isolation actually gives an agent that containers and serverless functions cannot

An agent can install packages, compile code, run system processes, and break and rebuild its environment without sharing that environment’s kernel with other tenants. Containers can support many of these operations too. The distinction is the boundary under which they occur, while stateless functions do not provide the same persistent, agent-controlled machine.

Ramp’s Inspect agent illustrates the capability this enables. It receives sandboxed access to realistic engineering tools, including Vite, Postgres, and Temporal, without touching actual production data during a live task. Combined with persistent disk and snapshots, this model can preserve files, installed packages, browser state, and working context across sleep and redeploy.

Browser access also brings hostile content inside the agent’s workflow. A headless browser can run into prompt-injection payloads, so isolation must limit the damage from compromised execution even when browsing is unsafe. Network access remains a separate exposure. An agent permitted to make outbound HTTP requests can still exfiltrate data or receive attacker instructions without escaping its VM. Claude Code prompts for approval of curl and wget by default rather than hard-blocking them, illustrating why approval behavior and enforceable egress restrictions are different controls.

The defense-in-depth layers that harden a micro-VM sandbox beyond the hardware boundary

The VM does not automatically restrict legitimate access used for illegitimate purposes. A redirected agent may remain entirely inside its guest kernel while misusing writable files, credentials, or network connections. Production hardening must address those paths separately. Defenses must assume prompt injection will sometimes succeed and constrain its consequences, because there is no fool-proof, deterministic prevention mechanism.

Filesystem policy limits what a confused agent can damage without escaping. Non-root execution, read-only mounts where writes are not needed, and strict limits on which paths are writable reduce what it can do inside the VM. Network policy must be equally explicit. Default-deny egress with an outbound allowlist or proxy intercepts requests before they leave the sandbox, limiting exfiltration and C2 traffic that would otherwise travel over ordinary HTTPS.

Credential handling requires a narrower boundary than tenant isolation alone. Secrets should not be written into the sandbox at rest. A TLS-terminating local proxy can inject credentials per request so agent code never holds a raw API key it could log or forward. Strict wall-clock timeouts also make infinite loops and long-running malicious tasks terminable without the agent’s cooperation.

Seccomp profiles and namespace restrictions can constrain the VMM process that manages the VM. These controls are additive to hardware isolation. Together, they address different routes to damage, including guest behavior, outbound access, secret exposure, resource consumption, and attacks against the host-side virtualization process.

How persistent micro-VM architecture maps to the per-user agent deployment model

One persistent micro-VM per user makes the security boundary the product boundary. Each user’s agent has its own environment, sleeps between sessions, and restores when work resumes. Because most agents are idle most of the time, a suspend-and-restore scheduler shifts dormant-user cost toward storage while compute use follows active tenants.

That alignment depends on the wake experience. Restore in under a second is a usability requirement for the per-user model. Waiting several seconds for an environment before work begins undermines an interactive product.

AWS Bedrock AgentCore uses a strict one-session-one-microVM model, provisioning a dedicated Firecracker micro-VM per session. Its session boundary validates the isolation pattern, but it does not preserve execution state, filesystem artifacts, or memory between sessions by default. Persistence remains a separate product property. Optional managed session storage, in preview since March 2026, allows filesystem artifacts to survive stop/resume cycles when configured, which is narrower than preserving full machine state.

Deno Sandbox, announced in beta on February 3, 2026, also assigns each sandbox a dedicated Firecracker micro-VM on Deno Deploy infrastructure. Neither example makes isolation synonymous with continuity. A per-user agent product still depends on explicit support for the files, packages, browser sessions, and memory that its workflows need to retain.

What to evaluate when choosing a micro-VM sandbox for agent workloads

The first evaluation axis is security, performance, and compatibility. For LLM-generated code or user-supplied binaries that need Linux, the products to compare are those with hardware-isolated guest kernels. Trusted internal code may justify simpler containers. User-space kernels and language isolates occupy different positions, with syscall emulation and runtime restrictions that must be assessed against the actual software the agent will run.

The second axis is statefulness, including what survives suspension, redeploy, and a new session. Snapshot support alone is not a complete specification. Evaluation should establish whether the product preserves files, installed packages, browser state, and in-memory context, and whether restore meets the interactive latency requirement. Traffic then determines the scheduling choice, with bursty agents favoring snapshot-restore and continuously active agents potentially favoring provisioned compute or warm pools.

The third axis is patch delivery into production. The study finds engine-side patch latency of approximately zero days for coordinated disclosures, so what matters most to operators is the downstream pin policy and how reliably updates are applied. Engine selection does not settle operational security. Evaluation must also cover egress controls separately, because a strong VM boundary does not close an authorized outbound channel used for exfiltration.

The fourth axis is managed convenience versus self-hosted control. Vercel Sandbox, AgentCore, and Deno Sandbox reduce infrastructure operations, while self-hosted Firecracker requires the team to operate scheduling, snapshot storage, and networking. Product limits need independent attention. Vercel supports Python and Node.js and bills active CPU time rather than I/O wait, while AgentCore’s aggregate billing requires external tagging or an observation layer for per-tenant cost attribution. For agent-native products, the strongest architectural fit treats the per-user micro-VM as a first-class unit, with persistent disk, snapshot-restore scheduling, and sub-second wake.