Kubernetes lifecycle for one-agent machines
Agent Sandbox fills a gap between ordinary pods and full virtual-machine platforms. A coding agent, notebook, or browser session often needs one long-lived container, one stable address, persistent files, and an explicit pause or deletion lifecycle. Deployments assume replaceable replicas. StatefulSets assume numbered sets.
This project packages that state machine as Kubernetes custom resources. The core Sandbox represents one stateful pod with a stable hostname, network identity, optional persistent storage, scheduled deletion, and pause or resume controls. Extension controllers add reusable SandboxTemplate definitions, SandboxClaim requests, and SandboxWarmPool capacity that is prepared before a user asks for it. A claim can adopt an already-running pod from a pool instead of waiting for an image pull and runtime startup.
That is a clean Kubernetes abstraction, especially for platforms serving many short-lived agent sessions. Go and Python SDKs give applications a higher-level entry point, and an optional router sends HTTP traffic to the correct pod without creating a separate externally managed route for every sandbox.
Orchestration is not the security boundary
The project's most important sentence is easy to miss: Agent Sandbox is a sandbox orchestrator. It does not implement low-level isolation. A basic KinD quickstart uses normal containers and explicitly says it has no added container isolation. Operators running untrusted, model-generated code should configure a RuntimeClass backed by gVisor, Kata Containers, or another suitable runtime. The repository includes examples for both, including cloud-specific Kata configurations, but the platform team owns their installation and verification.
The threat model is refreshingly direct about the rest of the boundary. Templates can default service-account token mounting off and can produce managed network policies that restrict ingress to the router and block internal address ranges and cloud metadata on egress. Administrators still need to limit CPU, memory, and storage, enforce RBAC around every custom resource, and check sidecar ports because default network policy can break their health checks. Bare Sandbox resources need admission controls if the same safe defaults must be mandatory.
Routing also needs surrounding infrastructure. The router validates sandbox identifiers and rejects local or restricted literal IPs, but its default authorizer is AllowAll for Python-client compatibility. The threat model recommends a custom authorizer for namespaces and addresses. Rate limits and upgraded-connection limits belong at the ingress, gateway, or proxy layer because the Go router does not currently provide them for cases such as WebSockets. A controller manifest alone does not create a safe multi-tenant service.
Installation starts easy, then becomes platform work
The core and extension controllers can be installed from a versioned release asset with kubectl apply. A Helm chart is available for source-based installs and exposes worker counts, Kubernetes API rate controls, leader election, tracing, profiling, pod scheduling, and extension toggles. That is a good operational surface for a young project.
A functional SDK path adds several steps. Operators deploy the router, create a template for the workload image, configure a namespace, and optionally maintain warm pools. A secure path first prepares the cluster with gVisor or Kata and confirms the template selects that runtime. Production then needs ingress, authentication, quotas, monitoring, persistence classes, image policy, network rules, and cleanup behavior.
Upgrades require attention. Helm does not upgrade CRDs from its crds directory, so operators must apply them manually. The move from v1alpha1 storage to v1beta1 also requires a migration script and documented sequence. Release v0.5.5, published August 13, 2026, raises the minimum Python version for the main SDK and integration packages from 3.10 to 3.11. One secure quickstart still lists Python 3.9, so use release notes and package metadata over that prerequisite line.
Useful machinery with live edge cases
Warm pools are the main differentiator over a hand-built singleton pod controller. They maintain ready capacity, claims adopt a matching pod, and refill controls can delay or rate-limit replenishment after bursts. The latest release added refill shaping, reduced unnecessary metadata writes, and a metric for client-to-ready latency. Examples cover JupyterLab, browser automation, Aider, LangChain, reinforcement learning, Ray, policy engines, gVisor, Kata, and cloud identity simulation.
The active issue queue shows where caution belongs. Issue #1367 reports that a stale informer cache can lead a claim reconciler to create a sandbox that already exists, treat the resulting error as fatal, and fail to bind. Issue #1375 says the example Python runtime executes blocking subprocesses inside an asynchronous endpoint with no timeout, allowing a hung command to stop readiness responses indefinitely. Issue #1376 asks the Python client to stream file-like uploads rather than buffering every payload in memory. These are specific problems, not reasons to reject the controller, but examples and client helpers should be tested like product code before reuse.
Several attractive capabilities remain roadmap items: automatic suspend on inactivity, first-class router packaging, a TypeScript SDK, an MCP server, dynamic identity, claim-time network policy attachment, scale to zero, and a web dashboard. The README's desired-characteristics list also uses exploratory language for some runtime-dependent features. Buyers should distinguish the current CRDs from the larger platform vision.
Health and the decision
The repository was pushed on August 14, 2026, hours after the v0.5.5 release. GitHub reported 128 open issues and 113 open pull requests. That queue is enormous, but recent release credits span many contributors and current discussions show maintainers triaging detailed controller, SDK, performance, and security work. Kubernetes SIG Apps governance, Apache 2.0 licensing, generated API references, a written threat model, migration guidance, benchmarks, and extensive examples all improve confidence.
Agent Sandbox is a credible choice when a platform team wants Kubernetes to be the control plane for persistent agent environments. It offers the lifecycle pieces that raw pods lack and avoids pretending those pieces replace a secure runtime. The price is an assembly job across cluster security, networking, storage, routing, and API migration. For teams already equipped to own that stack, the project is unusually promising. For application teams that only want an endpoint that safely runs code, a managed sandbox service is the more honest purchase.