Anthropic’s agent sandbox trades constant approvals for a boundary you must actually configure
Approve, not Run, is the most dangerous control in an AI agent’s day. It gets pressed for the fortieth time before lunch, long after anyone is reading the diff.
Anthropic has been direct about that habit. Constant approve clicks slow the work, and they make people less careful. The proposed trade is a preset boundary: the agent moves freely inside it, and a person is interrupted only at the edge. In its public writing on Claude Code sandboxing, Anthropic describes the result as “drastically fewer permission prompts.” That is the company’s own account of internal use. The write-up does not publish a baseline, a sample size, or a measurement window. Take the direction as theirs. Do not promote a missing number into a benchmark.
The mechanism behind the trade is now an open-source beta research preview called sandbox-runtime, usually shortened to srt. It is the runtime under Claude Code’s sandboxed bash tool. Anthropic says the same wrapper can sit around other agents, local MCP servers, and ordinary commands. The install command is the easy part. The business decision is whether anyone can explain the fence the agent is about to run inside.
A fence, not a new machine
The business point is two locks, used together: what files the process may touch, and which hosts it may reach. Seatbelt, bubblewrap, and the Windows Filtering Platform are how those locks are built. The tools do not make the decision.
A container or microVM starts something closer to a separate machine. Anthropic describes srt as wrapping a process you were already going to run, without starting a container. One correction. There is no separate guest operating system and no microVM. On Linux, though, the fence is bubblewrap, which is still a container-like namespace boundary. A platform team that hears “no container” and pictures a policy file taped to an ordinary process has the wrong picture of that path.
The limits are meant to cover the wrapped process and the scripts and subprocesses it spawns. The whole process tree, not just the first binary. Network access starts closed. Writes start closed. Reads do not. That last sentence is where unread boundaries leak.
Why either lock alone fails
Anthropic’s case for both boundaries is prompt-injection containment. Untrusted text, a bad dependency, or a poisoned document tries to redirect the agent. On the research page “Sandboxing: A Safer and More Autonomous Approach”, the failure modes are paired this way. Without network isolation, a compromised agent could exfiltrate files such as SSH keys. Without filesystem isolation, it could escape and gain network access.
The project README currently assigns those failures the other way. Without file isolation, sensitive files including SSH keys can be exfiltrated. Without network isolation, the process can escape and gain unrestricted network access.
Research page: no network isolation, and files such as SSH keys can leave. No filesystem isolation, and the process can escape to the network.
README: no file isolation, and sensitive files including SSH keys can be exfiltrated. No network isolation, and the process can escape to unrestricted network access.
Both stories are plausible. They are not the same claim. If you are writing a risk note for an automation program, cite the page you actually read. Do not stitch the two documents into one sentence. The mismatch is a reason to pin the commit you run. It is not a reason to dismiss the tool.
A second mix-up is worth avoiding. Inside Claude Code, Anthropic describes a product policy that allows read and write in the current working directory and blocks modification outside it. The command that turns that product sandbox on, /sandbox, is a different object from the library defaults. srt’s built-in reads are wider: read anywhere unless a path is denied, and write nowhere outside the paths you allow. Say which one you deployed.
What the defaults actually do
The built-in posture is easy to misremember, and the misremembering usually runs in the dangerous direction.
Reads are allowed everywhere unless denied. Writes are denied everywhere unless allowed. An empty write allowlist means no writes. An empty domain allowlist means no network. That is a sensible start for an agent that installs packages and calls APIs. It is not a sealed box. Keys, tokens, and customer exports are readable until someone denies them.
Precedence is not “last line wins, ” and it is not symmetrical. The README says denyWrite beats allowWrite. On reads, allowRead beats denyRead, except that a more specific deny inside an allowed region stays denied. Apply that to paths before you brief anyone:
- Writes, empty allowlist: nothing can be written. The closed default is the safe one.
- Writes, overlap: allow . and also deny .env. The deny wins, so .env stays unwritable even though it sits inside the allowed directory. The README’s own sample shape is an allow of . and a deny of ~/sensitive-folder. Any overlap is resolved the same way, in favor of the deny.
- Reads, no denies: ~/.ssh is readable. That is the default, not a corner case.
- Reads, allow inside a broader deny: deny /srv and allow /srv/app. /srv/app is readable, because an allow beats a deny.
- Reads, specific deny inside an allow: allow /srv/app and deny /srv/app/secrets. The secrets directory stays unreadable. The exception is the more specific deny, not the allow.
If your policy is a spreadsheet of paths, test those three interactions on the version you run. A rule you have not tried is a rule you cannot explain.
Settings live in ~/.srt-settings.json. –settings points at another file, and that path must exist. The failure mode here is one of the better security details in the project, and it is easy to miss. If the settings file is absent, srt uses the built-in defaults: no network, no writes outside the default write paths, unrestricted reads. If a settings file is present but empty, unreadable, or invalid, srt exits. It does not quietly fall back. A fallback would drop deny rules, allow-read rules, and credential rules without anyone noticing. Loud failure is the safer bug.
If you are the one deploying it
Skip this if you only need the operating model. The two locks are the decision. These are the mechanisms.
On macOS, srt generates a Seatbelt profile and applies it through sandbox-exec. The profile lets the process talk only to a specific localhost port, where host-side proxies listen.
On Linux, srt uses bubblewrap and removes the network namespace. Traffic is steered to host proxies over Unix sockets bind-mounted into the sandbox. Anthropic’s higher-level description of network isolation is written in those Unix-socket terms. That is the Linux path, not a universal design.
On Windows, sandboxed commands run as a dedicated local account, srt-sandbox. A Windows Filtering Platform egress fence is keyed to that account, alongside a write-restricted token and explicit access-control entries on the working tree. Same two boundaries. Different construction. Do not brief it as the Unix design with a new logo.
Outbound traffic is deny-by-default on every platform. HTTP and HTTPS go through an HTTP proxy. Other TCP goes through a SOCKS5 proxy. Those proxies enforce the domain allowlist and denylist. Anthropic also says the proxy can be customized to apply arbitrary rules to outgoing traffic. That is a stronger control than a list of hostnames. Design that part on purpose.
There is a control channel, –control-fd, for people who assume they can retighten a running command. Three facts matter. Each update has to be a complete config, not a patch. Network rules can change on the next request. Filesystem rules cannot. They were already baked into the Seatbelt profile, the bubblewrap arguments, or the Windows access-control entries. On Windows, a later file-access change does not replace the access granted at startup. The README says a changed set is only noted for debugging.
Two operator details sit beside that, not in the board slide. The descriptor has to be 3 or higher. If the channel dies before the first update, the command comes down. If it dies later, the last applied config keeps running.
The dial that actually moves risk
The security control is how wide the policy is. A sandbox merely being present does not do the job. An unread allowlist is how autonomy becomes a faster leak.
A coding agent that cannot reach a package registry will fail at the first install. A coding agent allowed to reach the internet, more or less, can still carry data out through a host you meant as a convenience. Too tight, and ordinary agent work breaks. Too loose, and the attacker inherits spare authority. No OS primitive makes that trade disappear. Allowlists that quietly become allow-all stop working as a boundary. They turn into a permission prompt you stopped reading.
Cosmonic, a Wasm-sandbox vendor, has argued the same point from the other direction in its own analysis, not a neutral bake-off. OS controls such as Seatbelt and bubblewrap are a fence around an existing process, not a new machine. A carefully configured container can beat a sloppy virtual machine. Hardware isolation can still boot a wide-open operating system inside the stronger wall. Excess authority is the blast radius.
Cosmonic groups Claude Code and OpenAI’s Codex as full-featured coding harnesses with built-in OS sandboxes, and argues that the tools those harnesses call, especially MCP servers, should sit in narrower sandboxes of their own. That matches the awkward truth about general agents. You often cannot pre-declare every host and path, because the task is not fixed. Least authority is still the right aim. Pretending a coding agent has a closed tool list is how the allowlist rots into allow-all.
For an agent that opens tickets or calls internal APIs, the practical version is dull and correct. Decide which systems it may read, which it may change, and which domains are a sanctioned path rather than an open pipe. Interrupt at that edge. Do not interrupt on every step inside it, or your operators will approve the one request that mattered.
Where this fence has gaps
Anthropic has claimed that a successful prompt injection “is fully isolated, and cannot impact overall user security.” Treat that as the company’s security claim. Nothing in the public materials here is an independent escape test, a published threat model, or a residual-risk study.
The README is the strongest available note on what remains, and it is still vendor documentation. On Windows, the filtering-platform rules do not follow a sandboxed process that puts a different token on a thread before it creates a socket. They also do not cover traffic a system service carries on that process’s behalf. Those gaps are not reconciled, in the public materials, with the “fully isolated” sentence. They are reasons a Windows deployment needs its own review, and reasons a high-consequence agent may belong in a microVM or a remote sandbox even when srt is good enough for a developer laptop.
Keep Claude Code on the web in a separate sentence. That product is a cloud session: git credentials and signing keys stay outside the sandbox, and a proxy checks a scoped git credential before a request reaches GitHub. Local srt is a host-OS fence around a process on a machine you already trust to some degree. Using one story to describe the other overstates what the open-source runtime does.
Pin the repo as carefully as the policy. Anthropic’s research page links https://github.com/anthropic-experimental/sandbox-runtime. The README discussed here lives at https://github.com/anthropics/sandbox-runtime, and that README points to an engineering page, https://www.anthropic.com/engineering/claude-code-sandboxing, rather than the research URL. Related is not proven identical. Clone the repository you mean to run, and pin the commit. A blog URL is not a release.
Questions worth asking before you roll this out
- Is srt a container I can drop in front of every agent?
No. It is an OS-level wrapper around a process and its children. macOS uses Seatbelt. Linux uses bubblewrap, which is a container-like namespace boundary, not a separate guest or a microVM. Windows uses a dedicated account with filtering and file permissions. Anthropic’s “no container” description does not mean “no isolation machinery.”
- Do filesystem limits and network limits both have to be on?
Anthropic argues yes: either boundary alone fails against a prompt-injected agent. Its two public write-ups currently describe those single-boundary failures in opposite ways. Cite the page you read, and run both locks anyway.
- Are the defaults already tight enough for customer data?
Network starts closed and writes start closed. Reads do not. Anything sensitive has to be denied on purpose, and a wide domain allowlist can still carry data out.
- What happens if the settings file is wrong?
A missing file falls back to the built-in defaults, including unrestricted reads. A file that is present but empty, unreadable, or invalid makes srt exit, rather than silently dropping the rules you thought were loaded.
- Can we tighten the sandbox while a command is running?
Network policy can be replaced through the control channel, but only as a full config, and only on the next request. Filesystem rules are fixed at startup. On Windows, a later file-access change does not replace the access granted when the process began.
- Is the Windows version the same isolation as the Mac and Linux versions?
It aims at the same two boundaries, with a different mechanism. The README documents filter gaps around thread tokens and system-service traffic. Do not brief it as equivalent isolation, and do not treat “fully isolated” as a test result.
- Does this replace a cloud sandbox or a microVM for high-risk agents?
No. Local srt and Claude Code’s cloud session are different designs. OS fencing is a useful inner layer. It is not, by itself, a hardware boundary.
- What if the task cannot be pre-declared, so the allowlist pressure is toward everything?
Then “everything” is not a control. Keep a short sanctioned list, interrupt at the edge, and put narrower fences on the MCP servers and side tools. If the work can reach production credentials or customer data, move that agent to a stronger boundary than a host-OS profile.
What to do with it on Monday
If your teams already let agents install dependencies, open tickets, and call internal APIs, approval fatigue is how a control fails, not a developer-experience quibble. A fixed boundary, with a prompt only at the edge, is a better operating model than a dialog every thirty seconds.
srt is a concrete way to build that boundary on a laptop or a CI box without standing up a microVM for every command. Deny the paths that hold credentials. Keep the domain list shorter than your engineers will like, and review it the way you review a vendor’s outbound access. Put narrower fences on the MCP servers and side tools, not only on the agent that calls them. If the blast radius includes production credentials or customer data, do not stop at an OS profile because the demo felt autonomous.
Autonomy inside a boundary you can explain is useful. Autonomy inside a boundary nobody has read is just a faster way to leak.