Kubernetes Agent Sandbox: Kubernetes sandbox for isolated agent workloads
Kubernetes Agent Sandbox is a Kubernetes sandbox for isolated agent workloads from Kubernetes SIG Apps. It is open source under the Apache-2.0 license and is offered as: Cloud-native, Self-hosted.
Platform teams on Kubernetes that need isolated, stateful environments for agents that run generated or untrusted code
Teams building a code-execution tool for an agent who want a Python SDK that runs commands in a pre-warmed, isolated pod
Consider instead if
You want kernel-level file, network and credential policies around a coding agent, with credentials added only to approved requests so the agent never sees them.
See OpenShell.
You want default-deny permit and forbid rules checked at network egress, interpreters and an MCP broker, on a developer machine rather than a cluster.
See Strands Box.
What Kubernetes Agent Sandbox does
Agent Sandbox gives Kubernetes a native object for one agent session: a Sandbox, a single stateful pod with a stable hostname and optional storage, plus templates, claims and warm pools of pre-started sandboxes so a new session does not wait for a cold start. Isolation comes from the runtime you choose through RuntimeClass, gVisor or Kata Containers. The project's threat model adds a default network policy (ingress only from the Sandbox Router, egress only to the public Internet, metadata endpoints blocked) and drops the service account token when a template is used. That puts it a level below NVIDIA OpenShell or Strands Box, which add per-action policies and keep credentials away from the agent; the README and threat model describe neither. The threat model also says the router's default authorizer allows every request. Apache-2.0, run on your own cluster.
This summary is our own wording of the sourced facts on this page.
Key facts
Each value links to the page that states it, with the date we checked it.
Where Kubernetes Agent Sandbox fits in our AI security layers
Our analysis
Our editorial model, not a standard. The primary layer follows the category, except for tools whose main documented job is detection and response; other layers rest on a capability the sources document.
How the model works.
AI security layers that Kubernetes Agent Sandbox covers, with the role, how each applies and what it rests on
Runtime isolation and default network rules limit what an agent workload can reach if it runs untrusted code.
Runs each agent workload as a Sandbox, a stateful pod with a stable identity, and delegates isolation to a runtime such as gVisor or Kata Containers; Reusable SandboxTemplate resources let administrators set the runtime class, resource limits and service account token behavior for sandboxes; Managed NetworkPolicy by default limits ingress to the Sandbox Router and egress to the public Internet, blocking private ranges and cloud metadata endpoints; SandboxWarmPool keeps pre-warmed sandboxes ready, and SandboxClaim hands one to a user without exposing its configuration; Python SDK creates a sandbox from a warm pool, runs shell commands and writes files in it without Kubernetes manifests
Not mapped in our analysis: LLM01, LLM02, LLM05, LLM07.
These are risks we expect tools in this category to cover; the sources we checked do not document a matching capability.
Scans skills and MCP servers, inspects agent tool calls and keeps an audit trail around AI coding agents.
Best for: Security teams that want scanning, guardrails and an audit trail around the coding agents developers already run, starting in observe mode before anything is blocked
Proxies AI clients to MCP servers it runs as isolated Docker containers, with tool filters and call logs.
Best for: Developers and platform teams that already use Docker and want MCP servers to run in containers behind one gateway with per-server tool selection
Open-source proxy that applies auth, CEL policy and guardrails to LLM, MCP and agent-to-agent traffic.
Best for: Platform teams that want one open-source gateway in front of MCP servers and LLM providers, with token validation, CEL rules per MCP method and pluggable guardrails
69Coverage Score 69 out of 100
LLM02 Sensitive Information Disclosure
LLM06 Excessive Agency
Reviewed
Kubernetes Agent Sandbox FAQ
Does Agent Sandbox provide the isolation itself?
No. The threat model says Agent Sandbox itself does not implement isolation but supports configuring runtimes such as gVisor or Kata Containers. The site describes gVisor as a userspace kernel and Kata as hardware virtualization with a dedicated kernel per sandbox.
Is it open source?
Yes. It is Apache-2.0 licensed, and the code is on GitHub at kubernetes-sigs/agent-sandbox.
What are its stated limits?
The threat model says the default router authorizer allows all requests, so the IP-class check is the only SSRF defense unless you configure an authorizer, and the router lacks connection-level limits for upgraded connections.
How does it differ from NVIDIA OpenShell or Strands Box?
Agent Sandbox manages sandbox pods on Kubernetes (templates, warm pools, claims, a default network policy) and leaves isolation to gVisor or Kata. Its README and threat model do not describe per-action policies or credential injection, which are the focus of those two tools.
Key facts you can cite
Kubernetes Agent Sandbox is released under the Apache-2.0 license.
We have no commercial relationship with Kubernetes SIG Apps.
Sources & last reviewed
Last reviewed . We compile from the vendors' own public
pages and repositories and we do not run the products. Source links open in a new tab. Found a mistake? Report a correction.
We may use analytics and, later, show ads. They stay off until you choose, wherever you are. Declining
never limits what you can read. See our privacy policy and
cookie policy.
Privacy settings
Choose what you allow. Your choice is stored on this device for 13 months. You can change it later from the
"Privacy choices" link in the footer.