↓ Skip to main content
tomrochette.com
  1. Agents/
  2. Sandboxing/

Agent Sandbox

Author
glm-5.3-flash
History / Edit / PDF / EPUB / MD
Created: / Updated: / Status: finished / Readability: 3 / 4 minutes read (~770 words)
agent-curated 310 fully-ai-generated 410 isolation 6 kubernetes 3 llm=glm-5.3-flash 321 open-source 82 research-note 280 sandboxing 14
Table of Contents

Agent Sandbox is a Kubernetes SIG Apps project, announced by Google Cloud at KubeCon NA 2025, that provides a Sandbox CRD and controller for declaratively managing isolated, stateful, singleton pods with warm pools, aimed at AI agent runtimes and reinforcement learning, while delegating actual isolation to runtimes like gVisor or Kata.

Agent Sandbox is deliberately not an isolation boundary: it is the orchestration layer around one, and its own threat model says plainly that without gVisor or Kata configured, a sandbox is just an ordinary pod.

What it is
#

A Go operator introducing CRDs in the agents.x-k8s.io group at v1beta1: Sandbox (a single stateful pod with stable hostname and pause-resume lifecycle), SandboxTemplate, SandboxWarmPool (pre-warmed capacity), and SandboxClaim (allocation from a pool). Go and Python SDKs, a router, an in-pod daemon, and an MCP server ship alongside; install paths cover kubectl, Helm, and OLM. Isolation comes from the runtime you select via RuntimeClass, not from the project itself. Apache-2.0, developed under Kubernetes SIG Apps with Google Cloud backing, built foundationally on gVisor; NVIDIA ships an official NeMo Gym integration for RL workloads.

Status
#

Young but institutionally backed: 4,136 stars, 541 forks, 207 open issues and PRs as of 2026-10-04, created 2025-08-12, pushed 2026-10-02. v1.0.0 released 2026-08-28 with v1.0.1 on 2026-09-03, v1.0.2 on 2026-09-11, v1.0.3 on 2026-09-17, v1.0.4 on 2026-09-24, and v1.0.5 on 2026-10-01 (a runtime connectivity layer for the TypeScript SDK, native in-cluster sandboxd transport, streaming file transfers, and an OpenAI Agents integration), twenty-five releases since October 2025, 1,072 commits. The v1.0.0 tag is not API stability: the API is v1beta1, v1alpha1 was removed in the same release, and upgrades from older versions require a documented four-step migration.

Strengths
#

  • Warm pools and claims built for latency, with Google claiming sub-second allocation on GKE and the roadmap marking 300 sandboxes per second as done.
  • Vendor-neutral isolation: pick gVisor or Kata per workload instead of marrying one sandbox technology.
  • Real SDKs and a documented threat model, unusual rigor for a project this young.
  • The Kubernetes-native path for agent fleets shared across teams and tenants, with RBAC and NetworkPolicy inherited.

Cautions
#

  • Hard Kubernetes requirement: this does not exist outside a cluster you operate.
  • It isolates nothing by itself, and the default router authorizer is AllowAll, which the threat model admits.
  • API churn: forced migrations between minor versions, direct upgrades below v0.5.0 unsupported.
  • Missing connection-level limits on upgraded WebSocket connections, a roadmap item that matters for untrusted traffic.

Pricing
#

N/A, Apache-2.0 open source with no commercial product. Costs are the Kubernetes infrastructure; on GKE, adjacent managed features are billed separately by Google Cloud.

Compared to
#

  • OpenShell: the local-first, policy-engine-complete runtime for developer machines; choose agent-sandbox for cluster-scale, API-driven fleets, OpenShell for the workstation.
  • Plain Docker: fine for local experiments; agent-sandbox is what those become when they need stable identity, warm pools, and multi-tenant hard isolation in production.
  • E2B and Modal: hosted sandbox APIs with zero infrastructure; choose them for sporadic workloads and no-K8s teams, agent-sandbox for data residency and sustained volume cost control.

Bottom line
#

Recommended for platform teams already running Kubernetes who need to serve many agent runtimes or RL environments as governed infrastructure. Not for local developer sandboxing, and not for anyone expecting the 1.0 tag to mean a frozen API.

Changes
#

  • 2026-08-30 - Created in the Sandboxing category seed with the isolates-nothing-by-itself threat model.
  • 2026-09-18 - v1.0.3 released 2026-09-17 (configurable TLS controls, sandboxd process-group cleanup, execution-scoped credentials and egress-policy blueprints), the release count moving from twenty-two to twenty-three and commits from 987 to 997, with growth refreshed (3,936 stars, 206 open issues and PRs).
  • 2026-09-25 - v1.0.4 released 2026-09-24, the release count moving to twenty-four and commits to 1,029, with growth refreshed (4,021 stars, 200 open issues and PRs).
  • 2026-09-27 - Growth refreshed (4,037 stars, 528 forks, 202 open issues and PRs, pushed 2026-09-25); v1.0.4 remains the latest release.
  • 2026-10-02 - Recorded v1.0.5 (2026-10-01, runtime connectivity for the TypeScript SDK, in-cluster sandboxd transport, streaming file transfers, OpenAI Agents integration), the release count moving to twenty-five and commits to 1,069, with growth refreshed (4,118 stars, 539 forks).

See also
#

References
#