kubernetes-sigs/agent-sandbox

If you already run Kubernetes and need a repeatable way to hand each agent or training job its own persistent, addressable container, agent-sandbox is worth a look. If you are looking for a ready-made agent orchestrator or a turnkey isolation product, it is not that.

The problem

Before: a team wants to give each AI agent or RL worker its own environment with a fixed hostname, surviving restarts, and storage that does not disappear with the pod. Deployments are built for replicated stateless pods, and StatefulSets carry an ordinal identity model that does not match a one-off long-running singleton. So teams end up writing bespoke controllers or glue around bare Pods. After: a Sandbox resource describes that single stateful pod declaratively, and the controller reconciles it. The result is a stable hostname and optional persistent storage managed through the Kubernetes API the team already operates.

What's different

The core idea is a CRD scoped to one stateful, singleton workload rather than a replicaset or an ordinal set. The README positions it as a lightweight, single-container VM-like experience built from Kubernetes primitives, with stable network identity and storage that survives restarts. That is a narrower abstraction than a general workload controller, and the narrowness is the point: it maps cleanly onto "one sandbox per agent session."

The extensions layer adds reuse and pooling. SandboxTemplate defines reusable definitions for many similar sandboxes; SandboxWarmPool plus SandboxClaim lets consumers request a sandbox from a pre-warmed pool without handling the underlying configuration, and the claim's name and UID are exposed as pod metadata for external services. The trade-off is API surface: adopting the extensions means learning several interacting resource types, and the separation between core and extensions means you must decide which install profile you want. Isolation itself is not created by this project; a commenter on the launch thread noted that RuntimeClass already provided gVisor/Kata pods for years and framed the interesting part as making this workload type easy to deploy (comment, 2026-07-31). That is a fair framing: the controller standardizes lifecycle and identity, while the isolation strength still comes from the runtime you configure.

Who should try it

Good fit: a platform team running Kubernetes that already has, or plans to add, an isolation runtime such as gVisor or Kata, and needs many short-lived but stateful agent environments with predictable names and storage. The pooling extensions are most useful when agent sessions start frequently and cold-start latency matters.

Poor fit: a single developer who wants to run an agent locally, or anyone without a cluster to install CRDs into. It is also a poor fit if you expect the project to supply the sandbox runtime, model serving, or agent logic; the README describes an API and controller, not those pieces. The commenter's real pain point was fast interactive verification of untrusted code, and while a persistent sandbox can host that loop better than batch CI, the project does not itself provide a verification service.

Requirements and limitations

You need an existing Kubernetes cluster and permission to install cluster-scoped CRDs and controllers. Installation is a manifest apply, either the combined core-plus-extensions bundle or separate components, and Helm is also documented (getting started, project instructions). The documentation recommends pinning a version for production and GitOps rather than using latest.

The uninstall path deserves attention before you begin: deleting the CRDs cascade-deletes every custom resource of those types across all namespaces, so the README tells you to inventory sandboxes, claims, pools and templates first (project instructions). Ongoing care means tracking the controller version and your chosen runtime class; the security model is documented separately, and isolation guarantees depend on that runtime rather than the CRD alone (threat model).

HotRepo's take

HotRepo's only daily-board observation is 2026-10-28, when the project had 4,429 stars and gained 19 that day. With a single recorded date, persistence of interest cannot be judged; the repository itself dates from 2025-08-12. Before investing, check the roadmap and the security threat model to confirm that the planned scope and isolation model match how you intend to run untrusted agent code.