Kubernetes Agent Sandbox Explained

What it is

Agent Sandbox is a Kubernetes SIG Apps project that runs each AI agent session in its own single-Pod, stateful workspace. The page is a newsletter edition by Bibin Wilson (DevOps Cube). It gives a minimal manifest and a conceptual workflow, and it defers the install and SDK steps to a separate hands-on guide.

How it works

Isolation comes from the container runtime, not from Agent Sandbox. The project orchestrates a sandboxed runtime: gVisor, or Kata Containers, which runs each sandbox in a lightweight VM with its own kernel.

The minimal Sandbox resource uses apiVersion: agents.x-k8s.io/v1beta1. Its key fields are:

• spec.operatingMode: Running
• spec.podTemplate.spec with restartPolicy: Never
• a python:3.12-slim container running sleep infinity
• workingDir: /workspace, backed by an emptyDir volume

The reusable workflow splits roles, loosely like PersistentVolumes and claims:

1. An administrator creates a SandboxTemplate (image and pod config).
2. The administrator creates a SandboxWarmPool that references the template. The controller keeps replicas pods running and ready.
3. An agent application creates a SandboxClaim against the pool. The controller assigns a ready sandbox, and the pool creates a replacement.
4. The application sends requests through the Sandbox Router, a lightweight proxy that forwards them to the assigned pod and returns results.

Preconditions / Affected

• The Agent Sandbox CRD and controller must be installed.
• gVisor or Kata Containers must be configured in the cluster separately. Without that, the sandbox is not isolated by those runtimes.

What to do

Lifecycle controls are set on the Sandbox:

• Suspend: change operatingMode from Running to Suspended. The controller deletes the pod and keeps its persistent storage. Setting it back to Running recreates the pod and reattaches the storage.
• Scheduled deletion: set shutdownTime with the Delete policy to remove a sandbox automatically at a given time.

The linked guide covers installing the controller and Sandbox Router, running untrusted code through the Agent Sandbox SDK, and testing deletion, hibernation and resume. The page does not give install commands.

Caveats

• Warm pools cut startup time, but the idle pods still consume resources.
• Suspending lowers compute cost only if the freed capacity lets the cluster scale down nodes. Persistent storage may still be billed while suspended.
• The example manifest uses emptyDir. The page does not show how to configure the persistent storage that suspend and resume rely on.
• The page gives no version numbers, benchmarks or startup-time figures.