agent-sandbox vs sandbox-runtime: a Kubernetes orchestrator against a process wrapper

An orchestrator in a cluster against a wrapper around a process

Both projects answer the same question, how do you keep code you do not trust away from the things it should not touch, but at different scales and in different layers. agent-sandbox is a Kubernetes project under SIG Apps. It defines a custom resource and a controller, and its README is explicit that it is a sandbox orchestrator which delegates low-level container isolation to secure sandbox runtimes such as gVisor or Kata Containers, by managing pods configured to use them through a RuntimeClass. sandbox-runtime, called srt in the README, is a small command line tool and library that takes one process on your machine and places filesystem and network restrictions around it using native OS primitives, with no container involved. One schedules and supervises workloads. The other confines a process. Neither replaces the other, and they rarely meet in the same process, because srt cannot serve as the RuntimeClass under an agent-sandbox pod.

agent-sandbox gives every pod a stable identity

The core object is the Sandbox custom resource, and it exists for a workload shape that Kubernetes handles awkwardly by default: a single, stateful pod with a stable identity and optional persistent storage. The README places it between two existing models, saying it suits workloads that fit neither the stateless replicated model of a Deployment nor the numbered stable model of a StatefulSet. Three features carry that idea. Each Sandbox gets a stable hostname and network identity. Sandboxes can be given persistent storage that survives a restart. And the controller manages the lifecycle, including creation, scheduled deletion, pausing and resuming, which is what an agent runtime or a reinforcement learning environment needs when a run has to be resumed rather than restarted from nothing. Extensions build on that base: SandboxTemplate for reusable definitions, SandboxClaim for allocating one from a pool, and SandboxWarmPool for keeping pre-warmed Sandboxes ready.

sandbox-runtime narrows what a process can reach

srt works from the opposite end. You wrap a command and it runs under restrictions that apply to the entire process tree. On macOS that means sandbox-exec with a dynamically generated Seatbelt profile. On Linux it means bubblewrap, with the network namespace removed entirely so that all traffic has to pass through proxies running on the host. On Windows the process runs under a dedicated local user account, with a machine-wide Windows Filtering Platform fence keyed on that account's identifier. The rules live in a settings file, and the defaults matter more than the syntax. Read access follows a deny-then-allow pattern, so a broad deny can be followed by a narrow allow. Write access and network access are allow-only: an empty allowWrite list means no writes at all, and an empty allowedDomains list means no network access. That is the detail to test first, because a settings file that reads as permissive can deny everything.

Getting each one running for the first time

agent-sandbox installs the way Kubernetes components install. You choose a release tag, export it as VERSION, and apply a bundled asset with kubectl, using sandbox-with-extensions.yaml for the controller and extensions together, or the core and extension files separately when you want them split. You can also render the manifests from source with kubectl kustomize. Afterwards, kubectl get crd sandboxes.agents.x-k8s.io tells you whether the custom resource definition is already present, and Go and Python SDKs give you a client. srt installs with a single global npm command, npm install -g @anthropic-ai/sandbox-runtime, and the first call is a shell command in quotes. The settings file lives at ~/.srt-settings.json and is edited by hand. Both are quick, and they assume different things: one assumes a cluster and a runtime class, the other assumes your account can use sandbox-exec or bubblewrap.

What each one costs to operate afterwards

agent-sandbox's running cost is Kubernetes itself. You now have a custom resource definition, a controller and pods with persistent storage claims in a cluster, and all of those belong to whoever already operates that cluster. Our analysis of agent-sandbox asks you to confirm that the sandbox-with-extensions.yaml asset exists for the tag you pin, and to check for a previous install before you apply, which is the kind of step that only matters on a cluster other people also use. What you get in return is the warm pool, since pre-warmed Sandboxes shorten the wait before a new one is allocated to a user. srt's running cost is a policy surface instead. Every process you wrap needs its own entry in the settings file, and enforcement depends on the platform primitives behaving as documented, so our analysis of sandbox-runtime says to verify on your own machine that the platform path works, that your allowlist blocks what you expect, and that the settings file parses the way you intended.

Same Apache-2.0 licence, very different release lines

Both are Apache-2.0 licensed, so either can be used inside a commercial product without a copyleft obligation, and the licence is no reason to pick one over the other. The release lines are a different matter, because they tell you how much each project expects its interface to move. The last push to agent-sandbox was on 2026-10-21, with v1.0.0 and v1.0.1 published in late August and early September 2026, which reads as an API that is settling. The last push to sandbox-runtime was on 2026-10-21 as well, and its releases are v0.0.75, v0.0.76 and v0.0.77 from September 2026, which reads as an interface that is not. The README of sandbox-runtime says the same thing in its own words, calling the project a beta research preview and warning that APIs and configuration formats may evolve.

Where each choice is the weaker one

agent-sandbox is the weaker choice when the workload is a replicated stateless service, which a Deployment already models, or when you expected the project to supply the isolation itself and it does not, since the README's own scope note puts that job in the runtime's hands. It is also the weaker choice outside Kubernetes, where there is no custom resource, no controller and no warm pool. sandbox-runtime is the weaker choice when you need isolation on many machines at once, when you need a configuration contract that will not move under you in production, which its beta label says plainly, or when you need a credential vault and per-sandbox egress policy of the kind a cluster platform provides. The summary is that these are tools for two altitudes. Use srt to make one command on your machine safe, and use agent-sandbox to keep many stateful agent pods running safely in a cluster.

Bottom line

On a workstation, sandbox-runtime is the smaller step, and you should verify that your allowlist blocks what you expect before you trust it. In a cluster, agent-sandbox is the one that fits, and you should confirm that a RuntimeClass such as gVisor is already installed. Neither substitutes for the other: one confines a process, the other supervises pods.

Sources

1. kubernetes-sigs/agent-sandbox repository
2. kubernetes-sigs/agent-sandbox README
3. anthropics/sandbox-runtime repository
4. anthropics/sandbox-runtime README