agent-sandbox

What it is

agent-sandbox is a Kubernetes-native controller for running isolated, stateful, singleton workloads — the kind of thing a Deployment or StatefulSet isn't built for. Think one pod per AI agent session, with persistent state, strong isolation boundaries, and a lifecycle model that treats "one instance, always the same one" as a first-class guarantee rather than something you bolt on with ordinal indexes and PVC templates. The target use case is explicit: AI agent runtimes — code interpreters, per-user agent sessions, sandboxed execution environments that need to survive restarts and keep their state without being part of a replicated set.

It's a Kubernetes CRD + controller pattern, written in Go, following the standard operator model: define a custom resource, reconcile it, manage the underlying pod/PVC/networking lifecycle on your behalf.

Who builds it and why

This lives in the kubernetes-sigs org, which tells you the primary audience: people already running Kubernetes who got tired of misusing StatefulSet (designed for N-replica quorum workloads like etcd or Kafka) to represent single-instance sandboxes. 93 contributors and 3,038 stars is a healthy signal for a project this narrow — this isn't a weekend fork, it has real multi-org engagement, which is typical of infra emerging out of production pain at companies running agent workloads at scale (the kind of problem you hit once you're running thousands of isolated LLM-agent sessions and Kubernetes' native primitives don't map cleanly).

No public founding date or backing org list. Treat this as a community-driven SIG-adjacent project rather than a single-vendor initiative until proven otherwise.

Production readiness signal

v0.5.0 — pre-1.0. No CNCF maturity level (sandbox, incubating, graduated) is publicly listed, so don't assume any formal governance or API stability guarantees. Commit activity is current and contributor count is solid for the space, which suggests active iteration rather than an abandoned experiment. But pre-1.0 on a workload-management controller means: expect CRD schema changes, expect breaking changes between minor versions, and don't wire this into critical-path production infra without pinning versions and testing upgrades in staging first.

Who should use this

• Teams building AI agent platforms that need per-agent or per-session isolation with persistent state (code execution sandboxes, long-running agent memory, per-tenant agent runtimes).
• Kubernetes-native shops that don't want to run a separate sandbox orchestration layer (Firecracker fleet manager, custom VM scheduler) alongside their existing cluster.
• Platform teams that have already outgrown "one Deployment per agent" or "abusing StatefulSet for singletons" and need a purpose-built primitive.

Who should NOT use this

• Anyone needing horizontally scaled, stateless workloads — this is not a Deployment replacement, don't use it for that.
• Teams running genuine multi-replica stateful systems (databases, message queues) — StatefulSet is still the right tool there.
• Organizations that can't tolerate pre-1.0 API churn in core infra — wait for a 1.0 or at least a documented stability commitment.
• Anyone not already on Kubernetes — this buys you nothing if you're not running k8s; the isolation model is entirely dependent on the cluster's pod/PVC primitives.
• Teams needing hard security isolation (multi-tenant untrusted code execution) without additional sandboxing tech underneath — agent-sandbox manages lifecycle, it doesn't replace gVisor/Kata/Firecracker for the isolation boundary itself.

Alternatives

• Kata Containers / gVisor + custom controller — stronger isolation primitives, but you build the lifecycle management yourself.
• Firecracker-based orchestration (Weave Ignite, firecracker-containerd) — microVM-level isolation for agent sandboxes, heavier operational lift, not Kubernetes-native by default.
• E2B / Modal — hosted, non-Kubernetes sandbox-as-a-service for agent code execution; good if you don't want to own cluster infra at all.

Pricing

Fully open source, Apache-2.0. No paid tier, no managed control plane, no vendor lock-in. You run it, you own the ops burden.