Evaluating Production Runtime Isolation for AI Agents That Execute Untrusted Code

Firecracker micro-VM isolation for AI agents gives each workload its own kernel through KVM hardware virtualization, rather than sharing the host kernel as standard containers do. The choice of production runtime should match that boundary to code trust, tenancy, session persistence, and compliance requirements. For hostile code, microVMs provide the appropriate isolation floor, but safe and affordable operation also requires independent controls over external effects and billing that accounts for idle time.

Why executing agent-generated code is categorically different from running ordinary application code

The attack surface includes repository files, web pages, GitHub issues, and other content. The user's original request need not be malicious. Instructions encountered during legitimate work can redirect an agent toward execution the user never authorized.

That changes the premise of runtime security. Traditional application code has a fixed, auditable instruction set established at compile or deploy time, while agents generate novel code from inputs that may be attacker-controlled. They also make runtime decisions about API calls and resource use that static policies cannot fully anticipate. Stateful memory adds another exposure because manipulated context can persist across sessions. OWASP AIVSS assigns a CVSS v4.0 Base Score of 9.4 to the interpreter tool attack scenario in which an agent is manipulated into executing attacker-provided arbitrary code.

The most consequential combination is the “lethal trifecta” of private-data access, exposure to untrusted external content, and authority to act on external services. Together, these let a content-level attack become an authorization bypass. Indirect prompt injection delivers the payload through retrieved material rather than the user's message, so perimeter defenses do not cover the execution path. The runtime must therefore contain behavior that could be hostile as well as separate an otherwise trusted application from its neighbors.

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

The five-level spectrum distinguishes isolation boundaries. Level 1 consists of standard containers such as Docker/runc, where namespaces and cgroups separate processes that still share the host kernel. Dropped capabilities, seccomp, AppArmor, a read-only root, and no-new-privileges reduce exposure without removing that shared dependency. A kernel vulnerability can compromise co-resident workloads. The documented runc escapes CVE-2019-5736 and CVE-2024-21626 illustrate the runtime's own attack surface, while CVE-2025-31133 and CVE-2025-52881 show that this vulnerability class remains active.

Level 2 introduces a userspace kernel such as gVisor. Its Sentry intercepts and reimplements Linux syscalls, preventing sandboxed programs from reaching the host kernel directly. Escape requires a flaw in that implementation and another in the limited host syscalls gVisor issues. That separation has a measurable cost. Per-call syscall latency is roughly 10x native latency, approximately 800ns versus about 70ns, while realistic workload overhead is typically 5–15%. Incomplete syscall emulation can also affect Linux software compatibility.

Level 3 uses microVMs, including Firecracker and Kata Containers, to give each workload its own kernel under KVM hardware virtualization. A guest-kernel exploit does not itself cross that boundary. The remaining escape surface is the hypervisor's virtual machine monitor. Firecracker boots in approximately 125ms with under 5 MiB of memory overhead, and a host can launch up to 150 microVMs per second. Running it involves managing TAP interfaces, IP tables, and host routing by hand.

Level 4, represented by Microsoft LiteBox, links applications against a minimal OS library that exposes a handful of controlled primitives. It offers a theoretically small attack surface but remains experimental as of early 2026, with no production SDK. Level 5 addresses a different trust concern. Confidential computing technologies such as AMD SEV-SNP and Intel TDX encrypt memory so even the host OS and hypervisor cannot read sandbox data. These boundaries still leave the legitimacy of an authorized external action to separate controls over effects.

How the threat model should drive tier selection before evaluating any specific tool

The boundary should be selected before the product. Internally written code that passed CI/CD can justify hardened containers, while LLM-generated formatting or calculation tasks call for at least gVisor or microVMs. Arbitrary binaries, unvetted package installs, and code derived from attacker-reachable inputs warrant a hostile-code assumption. For those workloads, hardware virtualization provides the boundary that remains when the guest kernel is compromised.

Session behavior then constrains the operational model. One-shot scripts can tolerate cold starts and deletion after completion, but an interactive coding agent may need its cloned repository and memory across tool calls. Such an agent needs persistent standby that preserves its state. Multi-tenancy raises the stakes further because a shared-kernel escape can expose other users' data and credentials. The session model and tenant boundary must therefore be evaluated together.

NIST states that containers do not provide as clear a security boundary as VMs, a distinction that can become a procurement gate. Security requirements involving SOC 2, ISO 27001, or HIPAA can consequently settle the container-versus-microVM choice before performance tuning begins. Hyperscaler offerings span both userspace-kernel and hardware-isolated approaches. Their availability provides directional guidance alongside the required workload classification.

The resulting decision matrix has four practical cases. Trusted internal code can use hardened containers when it runs in a single-tenant deployment and has no compliance floor. Latency-sensitive, bounded LLM-generated work with low multi-tenancy can use gVisor. Untrusted or user-supplied code in a multi-tenant environment with compliance requirements calls for a microVM floor, with Firecracker as the baseline. Regulated PII, healthcare, or financial data combined with untrusted code warrants confidential computing.

What the leading managed runtimes actually deliver against the framework criteria

GKE Agent Sandbox uses gVisor and offers a direct path for teams already operating Kubernetes. It fits moderate-risk LLM-generated workloads where syscall compatibility is not a constraint. The relevant tradeoff is therefore interception overhead and compatibility against the team's existing Kubernetes operating model, rather than an assumption that every sandbox supplies a separate kernel.

Vercel Sandbox and AWS Bedrock AgentCore use Firecracker. They fit workloads where code trust is lowest, tenancy exposure is high, or procurement calls for hardware-enforced isolation. Firecracker's boot time alone does not establish either platform's end-to-end startup latency, and a microVM boundary does not establish certification coverage. Session persistence, how the service wakes, and which compliance requirements it meets each need their own checks.

AgentCore also applies Cedar policy to each tool call, so agents face policy checks when they use their tool authority. Its pricing structure charges $0.0895 per vCPU-hour for active compute, with a committed baseline rate available for predictable workloads. Tool policy governs permitted actions, while active-compute billing addresses workload economics. Neither replaces the isolation boundary.

Framework-native execution introduces another independent consideration. MS-Agent CVE-2026-2256 shows the risk of failing to sanitize inputs before passing them into a shell execution context. The input path remains a safety risk in a well-isolated runtime, a distinction that prevents a product evaluation from ending at the hypervisor and leads directly to the controls required around it.

Why isolation tier alone does not complete the security posture and what layered controls fill the gap

A Firecracker microVM with unrestricted outbound access can still exfiltrate data or contact attacker infrastructure. The required complement is default-deny filesystem and network policy with explicit allowlists, enforced at the host or hypervisor level. Otherwise, the agent's external permissions can undermine the value of its strong compute boundary.

The MS-Agent vulnerability makes input handling relevant even after the runtime has been selected, while least-privilege process configuration limits the authority available inside it. The agent process should not run as root. Application-layer input/output classifiers and hardened system prompts complement that configuration, and tool or plugin provenance must be established before permission grants. Observability must also make executed code and resulting effects reconstructable for audit and remediation.

In multi-agent workflows, these requirements apply across the fleet. Each channel through which a coordinator talks to a specialist can become an injection vector, so the full boundary must cover more than host isolation. Separation between agents is also necessary. A compromised participant must be considered in relation to both the machine on which it runs and the other agents it can influence.

Irreversible effects expose the principled limit of sandboxing. Hu, Goel, and Bindschaedler's PACMI '26 paper argues that generated code should only plan when effects cannot be recovered and the generator may be adversarial. A fixed trusted mediator owns every effect and permits it only when the specification would have produced it. A database mutation, device write, or financial transaction cannot be made safe by a check performed after its consequences have propagated. The reference monitor therefore controls authority that no VM boundary can supply on its own.

The economics of isolation and how billing and idle behavior determine affordability at scale

Agent workloads often burst briefly and then remain dormant. Billing built for steady use can therefore make even the right isolation tier costly when each user has an agent in the fleet. The relevant cost is not just running code, but preserving an agent's ability to resume without paying continuously for inactive compute.

Snapshot-driven scale-to-zero separates those obligations. The harness saves execution state, including memory, call stack, and pending continuations, to durable storage before terminating the process. Compute then drops to zero while the saved state can be restored, enabling perpetual scale-to-zero. Deleting a sandbox loses state and requires a cold start plus reconstruction, whereas snapshot restore preserves continuity for persistent workloads.

Snapshot storage can also save less than a full copy of the apparent disk. Untouched offsets can reference shared base chunks, while a session that dirties a modest number of memory chunks adds a bounded amount of new disk data. That sharing supports economical standby. Google Agent Substrate completes its activate/deactivate cycle, including snapshot, worker release, restoration, and traffic routing, in under a second. Jakob Nielsen's research places perceived instantaneous response at 100ms and flow interruption at approximately 1 second, making wake latency consequential for interactive products.

It is better to rent that infrastructure when utilization is low or run it directly when utilization is high. Indicative 2026 market slot pricing is near $0.08/hour, compared with roughly $0.01–0.03 per slot-hour amortized for self-hosted Cluster API fleets running Kata or Firecracker at healthy packing. The estimated break-even lies around 15–25% utilization. These estimates depend on isolation technology, packing, and utilization. AgentCore's active-only compute model illustrates the pricing structure needed to avoid charging dormant agents as continuously busy workloads.

For persistent per-user fleets, idle agents need storage-only billing. That makes hardware isolation compatible with sparse activity without discarding session state. Active-only billing and preserved standby solve different parts of the problem, so both belong in the evaluation.

A practical selection checklist for teams making the isolation decision today

First, classify code trust before considering deployment convenience. Hardened containers are defensible for trusted, CI/CD-gated internal code. Bounded LLM-generated tasks require at least gVisor, while arbitrary or attacker-reachable code calls for a Firecracker microVM minimum.

Second, distinguish disposable scripts from persistent sessions. Ephemeral scale-to-zero fits work without state carryover, while interactive sessions need snapshot-backed standby. Third, check whether different users or trust domains share infrastructure, because a breach of the shared kernel can put other tenants on the same host at risk.

Fourth, set the compliance floor and check which certifications cover the platform before buying it. Regulated data used with untrusted code calls for confidential computing. Fifth, test cold-start and wake behavior against the latency budget, with sub-second snapshot restore required for interactive workflows.

Sixth, assess idle costs at expected fleet utilization. Low or spiky demand calls for storage-only idle billing, while sustained utilization can favor self-hosting. Across those choices, retain host-enforced default-deny policies, provenance checks, least privilege, effect mediation, and auditable execution records.