Anthropic Open-Sources sandbox-runtime: A Container-Free Sandbox for AI Agents

When AI Agents Start "Taking Action," Where Are the Boundaries?

AI agents can read and write files, invoke command-line tools, and connect to external tools through MCP servers—the more capable they become, the higher the cost of losing control. Anthropic's open-source sandbox-runtime (srt for short) is aimed squarely at this pain point: it's the OS-level sandbox behind Claude Code, using built-in system security mechanisms to constrain an agent's file and network access without having to spin up a container.

This positioning deserves a closer look. Container solutions (Docker and the like) can provide strong isolation, but at the cost of image builds, runtime dependencies, and extra resource overhead—making them cumbersome for high-frequency, lightweight scenarios like "run a single command." srt chooses to operate directly at the operating system layer, using macOS's Seatbelt and Linux's bubblewrap for restrictions, driving the cost of isolation down to nearly zero.

Dual-Platform Implementation: Seatbelt and bubblewrap

srt's cross-platform strategy is pragmatic—it doesn't reinvent the wheel, but instead reuses two mature kernel-level sandboxing facilities.

On macOS, it invokes Seatbelt (the policy framework behind sandbox-exec), defining through declarative configuration files which paths a process can access and whether it can establish network connections. On Linux, it relies on bubblewrap (bwrap), the unprivileged sandboxing tool long used by projects like Flatpak, which isolates the filesystem and network through namespaces.

Both are "process-level" constraints: no virtualization, no daemon, and minimal startup overhead. For tools like Claude Code that need to frequently execute shell commands and read project files, this lightweight characteristic is key.

Seatbelt is a mandatory access control mechanism in the Apple macOS kernel based on the TrustedBSD MAC framework; the sandbox-exec command is merely one user-space entry point to it. Its policy files use Scheme-like S-expressions (the Sandbox Profile Language), declaratively specifying which paths a process can read and write, which network addresses and ports it can connect to, which system services it can call, and so on. Policies are loaded at process creation, after which any unauthorized operation is directly denied by the kernel and logged. Because policies are declarative, auditors can read the configuration directly to determine the allowed scope rather than guessing at runtime behavior. Seatbelt's limitation is that it mainly constrains the routine system calls of user-space processes, offering limited protection against kernel vulnerabilities or certain low-level primitives.

bubblewrap (bwrap) is an unprivileged sandboxing tool on Linux, originally split out of the Flatpak project and now a low-level component of many desktop and container scenarios. It relies on Linux namespaces (mount, pid, network, user, etc.) and seccomp filters to build an isolated mount view and network environment for a process without root privileges. Unlike container runtimes, bwrap doesn't package images or start daemons—it performs only a single fast namespace switch, so startup overhead is in the millisecond range. It's often used with arguments like --unshare-net and --ro-bind to precisely control which directories are read-only, which are writable, and whether the process has network access.

The Protected Objects Go Beyond the Agent Itself

The original article specifically notes that srt restricts three categories of objects: agents, MCP servers, and CLI tools. This scope division is quite informative.

MCP (Model Context Protocol) servers are now the standard channel through which agents connect to external data, but a misconfigured MCP server can likewise become an entry point for unauthorized access. Bringing MCP processes into the sandbox means the security boundary isn't just the "main agent process" but covers the entire tool-call chain. The same goes for CLI tools—git, npm, and curl invoked by the agent are each a potential file and network exit point.

This "end-to-end containment" approach is far more solid than merely focusing on content filtering of model outputs.

Model Context Protocol (MCP) is a protocol open-sourced by Anthropic in late 2024 for letting AI applications connect to external data sources and tools in a unified way. An MCP server is essentially an independent process that communicates with clients via standard input/output or HTTP/SSE, exposing capabilities such as "resources," "tools," and "prompt templates." At runtime, an agent may launch or connect to multiple MCP servers on demand, each with its own filesystem and network permissions. If an MCP server is misconfigured or maliciously replaced, it could bypass agent-level restrictions to directly access sensitive files or exfiltrate data. Therefore, bringing MCP server processes under the same sandbox policy is a key step in closing the side door of the tool-call chain.

The Significance of Open Source: Sandboxes Shouldn't Be Black Boxes

That srt is released as open source is itself a signal. If an AI agent's security policy is implemented entirely as a vendor black box, enterprises find it hard to audit "what exactly is being restricted" and even harder to adjust policies to their own compliance requirements. Open source makes the security boundary inspectable, customizable, and reproducible.

For developers, this also means srt can be embedded in their own agent frameworks without being tied to Claude Code. Given that Anthropic previously open-sourced MCP and drove it to become a de facto standard, srt's open posture is consistent with that: first define the tool-calling protocol, then provide the secure foundation for executing those calls.

The Trade-offs of Lightweight Isolation

OS-level sandboxing is not without cost. It isolates file and network access while sharing the kernel—compared with virtual machines or strongly isolated containers, its protection surface against kernel-vulnerability-class attacks is narrower. In other words, srt addresses high-frequency risks such as "unauthorized access caused by agent misoperation or prompt injection," not "strongly adversarial multi-tenant isolation."

This trade-off is reasonable for most development scenarios. Production environments that truly need hard isolation can still layer on containers or microVMs. srt's value lies in pushing the secure default one step forward: you don't have to adopt a heavyweight solution first to keep your agent in a cage.

How Developers Should View It

If you're building or using a coding agent, srt offers three directly actionable insights: first, bring MCP servers and CLI tools under the same security policy—don't just protect the main process; second, prioritize OS-native mechanisms as the first line of defense, as they're low-cost and easy to audit; third, security policies should be written as explicit configuration rather than relying on the agent to "behave itself."

The expansion of agent capabilities won't stop, and boundary design must keep pace. srt is hardly the ultimate answer, but it turns "secure by default" from a slogan into a few lines of configuration.

One-line Summary

Anthropic open-sources the OS-level sandbox srt, using native system mechanisms to lightly constrain AI agents' file and network access.

Paragraph Summary

Anthropic's open-source sandbox-runtime (srt) is the OS-level sandbox behind Claude Code. It doesn't rely on containers but instead reuses macOS's Seatbelt and Linux's bubblewrap for process-level isolation, confining file and network access within declarative policies. Its protection scope covers three categories of processes—AI agents, MCP servers, and CLI tools—achieving end-to-end containment of the tool-call chain. Lightweight is the core advantage: no image builds, no daemons, suitable for coding agents that frequently execute shell commands. The trade-off is a shared kernel—it guards against misoperation and prompt-injection-class unauthorized access, not strongly adversarial multi-tenant isolation. Being open source makes the security boundary auditable and customizable, and developers can embed it in their own agent frameworks.