Kubernetes Builds a Sandbox CRD for AI Agents
The Kubernetes community has launched a new project to make a home for AI agents. The Agent Sandbox project, under development by SIG Apps, is a lightweight, single-container VM environment built on Kubernetes primitives that offers fast start-up times.
The project shows that Kubernetes maintainers are recognizing the requirements for flexible cloud native computing are changing.
By the end of 2026, 40% of enterprise applications are expected to run embedded task-specific agents, noted Ben Wheatley, a platform engineer at incident.io.
These agents will all need to maintain context, call external tools, write and execute code, and maybe even communicate with each other.
“Mapping these unique agentic workloads to traditional Kubernetes primitives requires a new abstraction,” wrote Kubernetes maintainers Janet Kuo and Justin Santa Barbara in a blog post.
A New Type of Kubernetes Workload
The present Kubernetes primitives don’t align well with the emerging agentic workloads.
For starters, agents are stateful. They need a persistent identity and a scratchpad for notes and executing code. They are mostly idle, except when they need to quickly spring into action. Tasks can take 50 milliseconds, or they can run for weeks at a time.
“While you could theoretically approximate this by stringing together a StatefulSet of size 1, a headless Service, and a PersistentVolumeClaim for every single agent, managing this at scale becomes an operational nightmare,” the maintainers write.
Built on a Kubernetes Custom Resource Definition (CRD), Agent Sandbox will have a declarative API for running single entity stateful workloads. It is a perfect fit for AI agent runtimes.
A “sandbox” will have a dedicated hostname and network address, so agents within this namespace will be able to communicate with each other.
Each agent will run from inside its own container, with its own stateful workspace, and can be set to idle when not in use. The CRD supports multiple secure run-times such as gVisor and Kata Containers. These run-times support security boundaries for multi-tenancy.
No Lagging Cold Starts
The sandbox also promises near-zero start times. Agents will need to be invoked quickly. Starting a new pod will take about a second, which the maintainers admit is too long for an agent.
A custom resource, called SandboxWarmPool, maintains a pool of pre-provisioned sandbox pods, effectively eliminating cold starts.
“Users or orchestration services can simply issue a SandboxClaim against a SandboxTemplate, and the controller immediately hands over a pre-warmed, fully isolated environment to the agent,” the maintainers write.
Get Started Today
The blog post shows how Agent Sandbox can be installed directly from kubectl. The software is still being rapidly updated so be sure to download the latest edition. Version 0.21 was released two weeks ago.
A Python client provides a high-level interface for creating and managing sandboxes.
The K8s folks also provide a set of examples to help developers get started. Templates are available to set up policies, run OpenClaw, establish a Python or VS Code environment, operate a Chrome browser and build a LangChain-based coding agent.
A New Era for Kubernetes
Although still in early development, Agent Sandbox is a timely release for the Kubernetes community.
“The architectural model of consuming AI is shifting from stateless inference to stateful execution environments interacting with external tools,” wrote start-up advisor Pradipta Banerjee in a Medium post. “This is fundamentally changing the security posture required to operate these systems.”
Container provider Northflank, which uses both gVisor and Kata, pointed out on its own blog that “Agent Sandbox fills a gap that raw Kubernetes primitives do not cover natively: managing long-running, stateful, singleton workloads with stable identity, lifecycle controls (pause, resume, scheduled deletion), and strong isolation for untrusted code execution.”
