Sandbox Runtime
Container-free OS-level sandboxing for AI agents and processes
About Sandbox Runtime
Sandbox Runtime is a lightweight tool from Anthropic for restricting what a process can read, write and reach on the network, enforced at the operating system level and without requiring a container. It was built for Claude Code and released open source as a research preview, on the argument that safer agents are a problem the whole ecosystem needs solved rather than a competitive advantage worth hoarding.
The technical choice that makes it interesting is the absence of a container. It uses what the operating system already provides, sandbox-exec on macOS and bubblewrap on Linux, combined with a filtering proxy for network access. That keeps startup cheap and the footprint small, which matters because the alternative, wrapping every agent invocation in Docker, is heavy enough that people skip it and then run agents unrestricted instead. The things it can constrain are exactly the things worth worrying about right now: agents, local MCP servers, and arbitrary bash commands an agent decides to run. Two caveats deserve stating plainly. It is a research preview under an experimental organisation, so interfaces can move. And OS-level sandboxing is a meaningful boundary but not the same guarantee as a virtual machine, so match it to your actual threat model rather than assuming it is equivalent to full isolation.
You wrap the process you want constrained and declare what it is allowed to touch: which paths are readable or writable, and which network destinations are reachable. On macOS that policy is enforced through sandbox-exec, on Linux through bubblewrap, and network rules are applied by proxying traffic rather than trusting the process to behave. The wrapped process runs normally inside those limits and fails when it steps outside them. Because there is no container image to build or daemon to run, applying it to a single bash command an agent wants to execute is cheap enough to actually do, which is the difference between a control that exists and a control that gets used.
- •No Container Required - Uses native OS sandboxing, so the overhead is low enough to apply per command
- •Filesystem Restrictions - Explicit control over which paths a process may read and write
- •Proxy-Based Network Filtering - Outbound access is filtered rather than left to the process's good behaviour
- •Works on Agents, MCP Servers and Bash - Covers the three things that most often run with more access than intended
- •Apache-2.0 and Readable - The enforcement boundary can be audited, which matters for a security tool
Anyone running coding agents with real filesystem access on a machine that holds anything valuable, and anyone running local MCP servers whose permissions they have never actually examined. It suits developers who want a control they will realistically apply rather than a heavyweight one they will skip. Teams building agent products can use it as a building block for their own isolation. If you need hard multi-tenant isolation between untrusted customers, this is the wrong layer and you want virtual machines or a service such as a hosted sandbox provider instead.
Pricing
From $0/mo
Free and open source under Apache-2.0. Released as a research preview, so treat it as evolving rather than settled.
Checked 2026-09-07
