What is AI agent sandboxing?

AI agent sandboxing is the practice of running agent-generated code inside an isolation boundary, so that an agent which has been compromised, prompt-injected, or is simply wrong cannot reach the host or the rest of the estate. The premise is that the agent is untrusted by default, which is a different starting point from most application security and the reason designing for breach is the useful frame.

The question is almost never whether to sandbox. It is which boundary, because the substrates differ by orders of magnitude in both isolation strength and cost.

What sandboxing does and does not protect against

Sandboxing is containment after execution has started. Being precise about that boundary is what makes the control worth having, because it is routinely oversold.

It contains. Code running inside a sufficiently strong sandbox cannot read the host filesystem, reach services it was not granted, or escalate through the host kernel. If an agent is induced to run something destructive, the destruction is bounded by the sandbox.

It does not verify. Nothing about a sandbox checks whether the artifact that just loaded is the one you expected. A poisoned dependency, a tampered model, or a malicious tool definition runs perfectly happily inside a strong sandbox. That is a supply chain control, and it belongs upstream in the pipeline as signature verification. In the OWASP agentic threat taxonomy this is the class sandboxing is weakest against.

It does not decide. A sandbox constrains where code can reach. It has no opinion about whether the action should happen at all. An agent permitted to call the deployment API from inside a perfectly isolated sandbox can still roll out a bad change to every user. Deciding which actions are allowed is runtime policy enforcement, and it is a separate layer.

Prompt injection sits across all three. The sandbox limits the blast radius of a successful injection and does nothing to prevent it.

The isolation substrates

Substrate	Isolation boundary	What an escape requires	Reported cost
Container, namespaces and cgroups	Shared host kernel	A Linux kernel exploit	Native
Container plus seccomp and a tight profile	Reduced syscall surface	A kernel exploit within the allowed syscalls	Near native
gVisor	User-space kernel, the Sentry	Breaking the Sentry, or the roughly 50 host syscalls it still allows	Sentry footprint around 20 to 40 MB; simple syscalls measured 2.2 to 2.8x slower under runsc
Kata Containers	A lightweight VM with its own guest kernel	Breaking the hypervisor	Around 100 to 180 MB per pod; virtio I/O typically within 2 to 3x native
Firecracker microVM	Guest kernel plus a minimal device model	Breaking the hypervisor, across a deliberately small device surface	Boots in under 125 ms, roughly 5 MB overhead per VM
Unikernel, for example urunc	Single-purpose guest with no general-purpose kernel	Breaking the hypervisor, with almost no in-guest surface to pivot through	Container-class startup with VM-class isolation

The numbers vary by workload and the syscall-heavy cases move most, so treat them as the shape of the trade rather than constants. gVisor's Systrap platform, which replaced ptrace with a seccomp-based trap, cut context-switch overhead materially on syscall-heavy workloads and the older figures overstate the tax.

The pattern underneath is consistent. Moving the boundary further from the host kernel buys isolation and costs either memory or startup time. What changed recently is that microVM and unikernel runtimes narrowed the startup penalty enough that the old reason to accept a shared kernel, that VMs are too slow for short-lived work, no longer holds for most agent workloads.

Running it in Kubernetes

The mechanism is RuntimeClass, and it is the part people expect to be harder than it is.

You install a sandboxed runtime on the node, register it as a RuntimeClass, and set runtimeClassName on the pod spec. Scheduling, networking and the rest of the orchestration layer are unchanged, which means sandboxing can be applied per workload rather than as a cluster-wide decision. That granularity matters: the useful policy is usually strong isolation for anything an agent generated and standard containers for everything you built and reviewed.

urunc and the Kubernetes agent-sandbox CRD is how that is wired for unikernel-backed sandboxes through containerd.

How to choose

Start from what the code is, not from a security tier list.

Code your team wrote and reviewed does not need a microVM. Standard containers with a tight seccomp profile are proportionate, and reaching further costs real money in memory and latency for a threat you do not have.

Code an agent generated is untrusted regardless of which model produced it, and the shared host kernel is the wrong boundary for it. Somewhere at or beyond gVisor is the floor.

Then let the workload shape pick between the stronger options. A long-lived, syscall-heavy process pays gVisor's syscall tax continuously and is usually better in a VM-backed sandbox. A short-lived, high-churn workload, which is what most agent tasks are, is dominated by startup cost, and that is where microVM and unikernel runtimes win outright.

The last question is the one this page opened with. A sandbox is one of three controls, and the other two are artifact verification before load and policy enforcement on what the code is allowed to do. The sandboxing whitepaper covers the substrate comparison in depth, and AI agent governance covers the enforcement layer that decides which actions a sandboxed agent may take at all.