How to sandbox AI agent code with the right isolation tier

Most agent platforms obsess over the wrong boundary. Teams bolt a language-level interpreter onto an agent, wrap it in a container, and call the result sandboxed, while the container itself shares a kernel with every other tenant on the host. The isolation ladder runs from shared-kernel containers through user-space kernels and hardware virtualization to language-level sandboxes, and the real question is never “which is strongest” but “where does the trust boundary actually break for this workload.” Knowing how to sandbox AI agent code execution means picking the rung where your threat model fails, not the rung with the best marketing.

How This Was Researched

This essay is desk research, not a benchmark report. It compares documented architecture and published performance figures across isolation tiers, drawing on primary project documentation, the Firecracker NSDI’20 paper, and live GitHub API metadata collected 2026-09-18. No hands-on benchmarking was performed.

Windows and macOS isolation are out of scope, as are confidential computing and TEE side-channel analysis, vendor agent frameworks beyond orchestration primitives, and AWS Fargate internals. Last researched: September 2026. The methodology is deliberately narrow: for each tier, read what the maintainers claim about the isolation boundary and what published numbers exist for density and startup cost, then compare those claims against the threat each tier is designed to contain. Where a number is not in a primary source, the point stays qualitative. That constraint matters because isolation marketing routinely outruns isolation evidence, and the only defense is refusing to repeat figures nobody published.

Why Agent Code Execution Breaks the Stateless Threat Model

Agent code execution breaks the stateless threat model because agents are stateful, long-lived environments running untrusted LLM-generated code, not stateless inference calls that terminate in milliseconds. A request-scoped sandbox can be torn down after each call; an agent that holds a filesystem, a shell, and a tool session cannot.

Kubernetes frames this directly in its agent-sandbox work, which treats agents as workloads needing persistent, isolated execution rather than ephemeral function invocations (Kubernetes agent-sandbox announcement).

The practical consequence is that the attack surface compounds over time. A stateless call has one shot at exploitation; a long-lived agent accumulates tool state, cached credentials, and network reachability that an attacker can probe across many turns. This is also why approval gates and guardrails sit at a different layer than isolation — see our human-in-the-loop approval gates analysis for how policy enforcement complements, rather than replaces, a hard boundary.

Linux Primitives Underneath Everything

Every isolation tier reduces to namespaces, cgroups, seccomp, and user namespaces, with user namespaces providing UID/GID mapping so a process can hold root inside its namespace without holding root on the host (user_namespaces(7)). Seccomp filters syscalls, namespaces partition kernel-visible resources, and cgroups bound consumption (seccomp(2), namespaces(7)).

Bubblewrap is the clearest illustration that these atoms compose into a usable sandbox without setuid binaries: it is a small setuid-free sandbox built directly on namespaces and related primitives (containers/bubblewrap). Its current release is v0.12.0, published 2026-08-26, with 8,758 stars and 387 forks on GitHub. The lesson generalizes: no tier above this layer is magic. gVisor, Kata, and Firecracker all recombine the same primitives at different points in the stack, which is why comparing them means comparing where the boundary sits, not whether the primitives exist.

How Do You Sandbox AI Agent Code Execution in Production?

You sandbox AI agent code execution in production by choosing among four tiers — shared-kernel containers, user-space kernels, hardware virtualization, and language-level sandboxes — and matching the tier to the trust boundary that actually fails for your workload, accepting each rung’s measurable density and latency tax. The ladder is cumulative in cost, not in correctness.

Each rung buys a specific boundary. Rung 0 buys process isolation on a shared kernel. Rung 1 buys a kernel-API boundary that never passes syscalls through to the host. Rung 2 buys a hardware virtualization boundary with a separate guest kernel. Rung 3 buys per-module memory and capability isolation inside a single process. Choosing the wrong rung means either paying for isolation you do not need or trusting a boundary that does not hold. For the surrounding execution model, our agent runtime architecture breakdown covers how these runtimes sit under orchestration.

The Isolation Ladder: Four Tiers, Four Trust Boundaries

The isolation ladder’s four tiers map to four distinct trust boundaries, and the correct choice is the lowest rung whose boundary contains your threat model. Shared-kernel containers, user-space kernels, hardware virtualization, and language-level sandboxes each cost progressively more in density and startup latency, so over-isolating at the top while under-isolating at the kernel boundary is the most common failure mode.

Rung 0: Shared-Kernel Containers

A shared-kernel container is still a host process wearing namespaces, so its trust boundary is the kernel itself and a kernel exploit crosses every container on the host. runc is the canonical OCI runtime here, with v1.5.1 released 2026-07-14 and 13,451 stars on GitHub (opencontainers/runc). The boundary holds against misbehaving application code and fails against kernel-level attacks.

Rung 1: User-Space Kernels

gVisor is a user-space kernel, not a VM and not a seccomp filter, implementing a Linux-like application kernel in memory-safe Go where the Sentry services syscalls without passing them through to the host kernel (gVisor documentation). The Gofer mediates filesystem access over 9P, and runsc presents the whole thing as an OCI runtime (gVisor architecture guide).

Google’s own description is unusually precise: GKE Sandbox is “a userspace re-implementation of the Linux kernel API that does not need elevated privileges,” aimed at untrusted code and AI/ML workloads (GKE Sandbox). The trust boundary is the syscall interface — the host kernel never sees the workload’s syscalls directly. gVisor’s latest release is release-20260914.0, published 2026-09-16, with 19,348 stars and 1,992 forks.

Rung 2: Hardware Virtualization

Hardware virtualization adds a second isolation layer by running container workloads inside a lightweight VM with its own guest Linux kernel, which is exactly how Kata Containers is designed (Kata Containers virtualization design). Supported VMMs — QEMU, Cloud Hypervisor, Firecracker, and Dragonball — are all KVM-based and interchangeable, so the boundary is the hypervisor, not any single VMM.

Kata’s 4.2.0 release landed 2026-09-15 with 8,750 stars. Firecracker is the load-bearing case. Its NSDI’20 paper documents memory overhead under 5 MB per microVM, boot to application code under 125 ms worst case, and up to roughly 150 microVMs created per second per host, with production use at AWS Lambda since 2018 (Firecracker NSDI’20 paper). It is Apache-2.0, and the paper contrasts it with QEMU 4.2 at over 1.4 million lines of code (Firecracker project site). Firecracker v1.17.0 shipped 2026-09-10 with 36,811 stars.

Rung 3: Language-Level Sandboxes

WebAssembly provides per-module memory and capability isolation inside a single process, which is the boundary Wasmtime exposes (Wasmtime introduction). WASI inherits a capability-based POSIX and CloudABI model and has moved from Preview 1 (witx) through Preview 2 (Wit IDL, 0.2) toward Preview 3 (WebAssembly/WASI).

Wasmtime’s v48.0.2 landed 2026-09-10 with 18,644 stars. The boundary is the module: no ambient authority, no shared memory across modules, but also no protection from a host-runtime bug.

Decision Matrix: Density vs. Latency vs. Trust Boundary

The decision matrix compares each tier on isolation boundary, memory overhead, startup latency, density implication, OCI-runtime compatibility, and orchestration integration, and the tradeoff is monotonic: stronger boundaries cost density and startup time. Only Firecracker’s figures are published in the fact base; the rest stay qualitative.

The density tax is real at every rung above zero, but it is not the deciding factor. A workload running untrusted LLM-generated shell commands needs the syscall or hypervisor boundary because the code is adversarial by construction; a workload running deterministic transforms inside a capability-scoped module can stay at rung 3 and keep its density. The mistake is applying rung 3 to adversarial code and calling it sandboxed while the container underneath still shares a kernel.

Orchestrating Runtime Choice in Kubernetes

RuntimeClass selects a container runtime configuration per Pod and has been stable since Kubernetes v1.20, which is the mechanism that makes rung selection a scheduling decision rather than a rebuild (Kubernetes RuntimeClass). It is the boundary the cluster scheduler actually understands, so the rung can be chosen per workload class rather than per cluster.

The OCI Runtime Spec is what makes rung selection portable: runc, crun, youki, gVisor, and Kata are interchangeable low-level runtimes invoked by containerd or CRI-O, and v1.3.0 landed 2025-11-04 with 24 PRs since v1.2.1 (OCI Runtime Spec v1.3 announcement).

That interchangeability is what lets kubernetes-sigs/agent-sandbox natively support gVisor or Kata runtimes without the agent framework knowing which rung it is on (kubernetes-sigs/agent-sandbox). The project’s v1.0.3 release landed 2026-09-17 with 3,936 stars. A minimal RuntimeClass binding looks like this:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc
---
apiVersion: v1
kind: Pod
metadata:
  name: agent-worker
spec:
  runtimeClassName: gvisor
  containers:
    - name: agent
      image: registry.example.com/agent:latest
      env:
        - name: AGENT_TOKEN
          value: "Authorization: Bearer <API_TOKEN>"

Swap handler: runsc for a Kata handler and the same Pod spec runs on rung 2. That is the entire orchestration story: pick the rung per workload class, expose it as a RuntimeClass, and let the OCI runtime spec absorb the difference. For how this interacts with long-running state, our durable agent execution patterns covers checkpointing and resumption across runtime restarts.

FAQ

These are the three boundary questions that come up most often in design review: whether gVisor is a kernel or a filter, how far Firecracker’s specialization reaches, and what WebAssembly’s per-module sandbox actually guarantees. Each answer cites its primary source.

Is gVisor a VM or a seccomp filter?

gVisor is neither a VM nor a seccomp filter; it is a user-space kernel that implements a Linux-like application kernel in memory-safe Go, where the Sentry services syscalls without passthrough to the host kernel (gVisor documentation). The Gofer mediates filesystem access over 9P, and runsc exposes it as an OCI runtime.

Can Firecracker replace QEMU for all container workloads?

Firecracker cannot replace QEMU for all container workloads, because it is a minimal VMM optimized for a narrow device model rather than the broad emulation QEMU provides. Its NSDI’20 paper documents under 5 MB memory overhead per microVM and boot under 125 ms worst case, with production use at AWS Lambda since 2018 (Firecracker NSDI’20 paper).

Does WebAssembly provide enough isolation for untrusted agent code?

WebAssembly provides per-module memory and capability isolation inside a single process, which is enough only when the host runtime and the surrounding container boundary are also trusted (Wasmtime introduction). WASI’s capability-based model removes ambient authority (WebAssembly/WASI), but a host-runtime bug or a shared kernel underneath still crosses the boundary, so it is not a complete answer for adversarial code.

The ladder is not a ranking. It is a set of boundaries, each with a price in density and startup latency, and the engineering work is deciding which boundary your threat model actually requires. Most agent stacks pay for rung 3 semantics while running on rung 0 infrastructure, and that gap is where incidents live. Start from the kernel boundary, move up only when the threat justifies the tax, and let the OCI runtime spec and RuntimeClass make the choice reversible. The starting points are in the AI stack reference and the tools directory if you want to map the runtimes to your own deployment.

📖 Related Reads

• NiteAgent — AI agent development, frameworks, and production patterns
• NoCode Insider — AI workflow automation with no-code tools, agents, and APIs
• ToolBrain — tool reviews, LLM comparisons, and AI workflow guides

Cross-links automatically generated from CodeIntel Log.