Autonomous AI agents execute code that has never been reviewed by humans. They install packages selected by models, run freshly generated scripts, and iterate based on test outcomes. While such experimentation poses limited risk on a developer's laptop, deploying agents across shared Kubernetes infrastructure amplifies the threat surface. An allowed system call that exploits a kernel vulnerability can compromise the entire node and expose workloads from other tenants.

As agent adoption accelerates, workload isolation has evolved from a specialized hardening practice into a foundational requirement for platforms hosting agentic workloads. The cloud-native community has responded with solutions spanning five distinct layers: from the pod specification through the node configuration and up to session-level management. This layered approach lets platform teams assemble existing components rather than building isolation mechanisms from scratch.

1. The isolation layer: choosing your risk boundary

The first decision involves selecting an isolation strategy that balances security posture against performance requirements. Three primary options exist, each with distinct tradeoffs.

runc delivers maximum performance by sharing the host kernel. Seccomp-based filtering restricts which system calls a process may invoke, providing a lightweight security boundary.

The five layers of a pod sandboxing stack, each built from open-source components.
Figure 1. The five layers of a pod sandboxing stack, each built from open-source components.

gVisor addresses scenarios where a restricted kernel interface suffices. Its user-space application kernel intercepts system calls instead of launching a guest Linux kernel, creating a narrow interface between workload and host. gVisor implements a Linux subset, enabling rapid startup and dense packing. However, applications must operate within the interfaces that Sentry implements, potentially constraining agent capabilities.

Diagram of rgw same pod under three runtimes, with the boundary each one draws around agent code.
Figure 2. The same pod under three runtimes, with the boundary each one draws around agent code.

Kata Containers provide full VM isolation for use cases demanding the strongest guarantees. Each pod executes within a lightweight VM featuring its own guest kernel, incurring VM boot overhead and guest-kernel memory consumption. Agents frequently exercise package managers, compilers, nested builds, and headless browsers—workloads where system-call emulation may introduce unexpected constraints. As one practitioner noted, "A separate guest kernel with hardware virtualization avoids surprises where system-call emulation falls short and unexpectedly handcuffs agents."

2. The node: assembling it and accounting for it

Worker nodes must be configured to support the chosen sandboxed runtime.

runc containers rely on Linux namespaces to isolate process, filesystem, and network views, and cgroups to enforce resource limits. Since they share the host kernel, nodes require only runc configured through a container runtime such as containerd—no guest kernel or hypervisor needed.

gVisor processes workload system calls through Sentry, while a separate Gofer process manages access to host-backed files. Each eligible node must have the gVisor runtime installed and integrated with containerd.

Inside a worker node when a pod selects the Kata runtime. Everything outside the microVM runs on the host.
Figure 3. Inside a worker node when a pod selects the Kata runtime. Everything outside the microVM runs on the host.

Kata Containers place each pod in a lightweight VM, routing workload system calls to the guest Linux kernel isolated by hardware-backed virtualization. This approach adds significant overhead and requires bare-metal nodes or VMs supporting nested virtualization. In a Kernel-based Virtual Machine (KVM) setup, nodes need the Kata runtime shim, a supported virtual machine monitor (VMM), KVM and hardware virtualization capabilities, plus a guest kernel and image containing the kata-agent. Operators must maintain that guest image; a kernel CVE requires patching two kernels. For use cases demanding flexibility and strict isolation, this maintenance burden may prove necessary.

3. The access layer: limiting the agent's reach

A sandbox protects the host from the agent but not from resources the agent receives. Code running inside can still delete a writable repository, read a mounted secret, or transmit data wherever network policies permit. Sandbox policy matters as much as the sandbox itself.

  • Network: Implement default-deny egress through NetworkPolicy, then permit only destinations the task requires, such as a package mirror or model endpoint.
  • Credentials: Provision short-lived credentials scoped to individual tasks rather than long-lived tokens mounted into the pod. Leaked credentials expire when the task completes.
  • Storage: Mount repositories and data as read-only unless the task requires write access, and assign writable workspaces their own volume.
  • Remote tools: Grant API endpoints and Model Context Protocol (MCP) servers independent authorization. Since they run outside the sandbox, its boundary does not protect them.

4. The request: RuntimeClass

Kubernetes enables users to retain the standard Pod API while allowing selected pods, including agents, to opt into more isolated runtimes. RuntimeClass lets pods choose the security and performance balance they require without imposing isolation overhead on non-agentic workloads.

Elevated isolation increases resource consumption and affects pod readiness. gVisor's Sentry processes and Kata's guest kernel, kata-agent, and VMM introduce memory and CPU overhead. Cluster administrators should measure this overhead and add it to the RuntimeClass definition so the Kubernetes scheduler and resource quotas account for it. Copying example values risks misconfiguration; measure your actual workloads.

Cluster administrators create a RuntimeClass matching the node's configured runtime. It informs Kubernetes that the runtime is available, how pods select it, and what overhead it requires:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata
handler: kata              # runtime name in the node's containerd config
overhead:
  podFixed:
    memory: "160Mi"        # example value; measure your own
    cpu: "250m"
scheduling:
  nodeSelector:
    sandbox.example.com/kata: "true"

A pod opts in through the runtimeClassName field of its spec:

apiVersion: v1
kind: Pod
metadata:
  name: agent-task
spec:
  runtimeClassName: kata   # or gvisor; omit for the default runc
  containers:
  - name: workspace
    image: python:3.12

Everything else remains unchanged. Workloads that do not require sandboxing omit the field and use the default runtime. A cluster can expose each runtime as a separate RuntimeClass.

5. The session layer: Agent Sandbox

Agent work arrives in bursts. An agent executes code, then waits minutes or hours for the next interaction with a model or human. Keeping a VM running maintains readiness to resume work but consumes cluster capacity. Tearing it down frees capacity but requires rebuilding it later. Warm pools offer a compromise, though they reserve capacity.

The Agent Sandbox project, maintained by Kubernetes SIG Apps, standardizes this choice. Its Sandbox API creates stateful single-pod environments with stable identities and persistent storage, plus extensions for templates, claims, and warm pools. It remains runtime-agnostic and delegates isolation to the selected RuntimeClass.

Building on community foundations

Community-driven projects have enabled the goal of running untrusted agent code on shared infrastructure using familiar Kubernetes tools. They maintain workload portability: the same pod specification runs on any conformant cluster. Security fixes and design reviews benefit from a network larger than any single vendor. Frameworks integrating with Agent Sandbox do not require new APIs. By leveraging community solutions, users can adopt these tools without reinventing foundational components.