Anthropic Documents How It Isolates Claude in Its Products

One of the chronic problems in the world of sandboxing software is that products rarely document in detail how their isolation mechanisms work. Without documentation, the trust you place in them is, at best, blind faith. That is exactly what Simon Willison pointed out on his blog on May 30, highlighting that Anthropic has just published a notable exception to that rule.

Anthropics engineering team has published a technical overview of how they contain Claude in its three main environments: Claude.ai, Claude Code, and Claude Cowork. The document is neither an academic whitepaper nor a press release, but rather a functional description of the isolation layers they apply and why they chose them.

What technique each product uses

The differences between environments are significant and respond to very different execution contexts:

• Claude.ai uses gVisor, Google's user-space kernel, to isolate server processes without needing a full VM. It is a solution proven in production environments at scale.
• Claude Code, which runs locally on the user's machine, employs Seatbelt on macOS and Bubblewrap on Linux. Both are native sandboxing mechanisms for each operating system, which makes sense when the runtime is the developer's own computer.
• Claude Cowork, the collaborative workspace environment, goes a step further and spins up a full VM: Apple's virtualization framework on macOS and HCS (Host Compute Service) on Windows.

The logic underlying all of this is summarized clearly in Anthropic's own document:

> Constrain where and how an agent can act with process sandboxes, VMs, filesystem boundaries, and egress controls. The goal is to set a hard boundary on what an agent can reach. For example, if credentials never enter the sandbox, they can't be exfiltrated, regardless of whether the cause is a user, a model finding a "creative" path, or an attacker.

In other words, if credentials never enter the sandbox, they cannot leave it, regardless of whether the vector is a user, the model itself, or an external attacker. The design is based on assuming that failure can come from any direction.

Why this matters now

This publication comes at a time when Claude Code agents, with the ability to execute commands, read file systems, and call external tools via MCP servers, are being deployed in real production environments. The question of what an autonomous agent can and cannot do on a system is no longer theoretical.

The threat model Anthropic describes is relevant precisely because it contemplates scenarios that security teams have begun to take seriously: prompt injection from external sources, unexpected model behavior when exploring "creative" paths, and deliberate attacks against the agent as an access vector. Covering all three surfaces with layered controls—process, filesystem, network—is a sound approach.

Who finds this information useful

Teams integrating Claude Code into CI/CD workflows or building agents on top of Anthropic's API benefit most from this level of transparency. Understanding what Seatbelt or Bubblewrap do by default, and what network limits Anthropic applies in its managed environments, allows informed decisions about what work to delegate to the agent and what to keep out of its reach.

It is also useful for those evaluating Claude Cowork in corporate environments: the fact that it spins up a full VM, rather than relying solely on process-level sandboxing, directly addresses the typical objections from enterprise security teams.

---

From our perspective, the assessment is straightforward: Anthropic publishing this does not guarantee that sandboxing is perfect, but it does mean you can audit it, question it, and demand concrete improvements. That is already considerably more than most comparable products offer.