Sandbox Runtime

Overview

Sandbox Runtime (srt) is Anthropic’s open-source answer to a problem every agent platform faces: how do you let AI-generated code and MCP servers run on a developer’s machine without giving them access to SSH keys, credentials, and unrestricted network egress? Instead of reaching for Docker or a full VM, srt uses the OS’s own sandboxing primitives to enforce restrictions at the process level. On macOS it generates Seatbelt profiles for sandbox-exec, on Linux it uses bubblewrap with network namespace isolation, and on Windows it creates a dedicated local user account with Windows Filtering Platform egress fences. The result is sub-millisecond overhead with no container runtime to install or maintain.

Key Capabilities

Dual isolation model: Both filesystem and network isolation are enforced simultaneously. Without file isolation, a compromised process could exfiltrate SSH keys. Without network isolation, a process could bypass filesystem restrictions by uploading data to an external server. Srt addresses both attack surfaces in a single wrapper.

Filesystem restrictions use two patterns: reads follow a deny-then-allow model where you block broad regions and re-allow specific paths within them, while writes follow an allow-only model where nothing is writable by default. This means a sandboxed process cannot write anywhere you have not explicitly permitted.

Network restrictions route all traffic through host-side proxy servers. On Linux, the sandboxed process’s network namespace is removed entirely — all traffic must traverse Unix domain sockets bind-mounted into the sandbox. On macOS, the Seatbelt profile restricts communication to a specific localhost port where the proxy listens. Both HTTP/HTTPS and arbitrary TCP traffic (via SOCKS5) are mediated, and domain allowlists and denylists are enforced at the proxy layer.

MCP server sandboxing is a first-class use case. Wrapping an MCP server is a one-line change in your .mcp.json — replace the command with srt followed by the original command. The sandbox configuration lives in ~/.srt-settings.json, keeping security policy separate from server configuration.

Use Cases

The primary use case is sandboxing AI agents and the tools they invoke. Claude Code uses srt internally to restrict what agents can read, write, and connect to. Teams building MCP servers can wrap them with srt to prevent a compromised or misbehaving server from accessing sensitive files or phoning home to unauthorized domains. DevOps teams use it to sandbox build scripts and CI steps that execute AI-generated code. Security-conscious organizations use it as a lightweight alternative to containers when full Docker isolation is overkill for the threat model.

Considerations

Srt is a research preview with evolving APIs and configuration formats. It requires platform-specific dependencies: sandbox-exec is built into macOS, bubblewrap must be installed on Linux, and the Windows implementation has known limitations around thread-level token switching. The tool is process-level isolation, not a full container — it does not provide its own filesystem image, init system, or resource limits (cgroups). For workloads that need complete environment reproducibility, containers remain the better choice. Srt is best understood as a security layer that is lighter and faster than a container but narrower in scope.

Who It’s For

Sandbox Runtime is for developers and platform teams building agent systems who need lightweight, OS-level process sandboxing without the overhead of containers. It suits anyone running untrusted code from AI agents, MCP servers, or build pipelines on developer machines or CI runners, and teams that want a secure-by-default posture with explicit opt-in for filesystem and network access.