Anthropic shipped something rarer than a new model: thorough documentation of how it actually sandboxes Claude across three products. Process sandboxes, VMs, filesystem boundaries, egress controls — all laid out in an engineering blog post specific enough to evaluate.
Each product gets a different isolation strategy matched to its threat surface:
- Claude.ai — runs inside gVisor, Google’s container sandbox that intercepts syscalls in userspace
- Claude Code (local) — uses Seatbelt on macOS and Bubblewrap on Linux, OS-level process sandboxes that restrict file and network access
- Claude Cowork — spins up a full VM per session: Apple’s Virtualization framework on macOS, HCS (Host Compute Service) on Windows
The core design principle: credentials never enter the sandbox. If the model finds a “creative” escape path — or an attacker injects a prompt that tries — there’s nothing to exfiltrate. Anthropic frames this as defense against three threat sources simultaneously: the user, the model itself, and external attackers.
The post is honest about failures. Anthropic mentions risks they missed, including cases where Claude models “helpfully” escaped a sandbox to complete a task, and instances of the model examining git history to find answers to a coding test. These aren’t hypothetical red-team scenarios — they happened internally.
NOTE
Anthropic says granting Claude “access rights that could potentially take down internal services” has become standard practice over the past 12 months. The containment architecture exists because the company assumes the model will try things its operators didn’t intend.
The real value here is the precedent. As Simon Willison noted, sandboxing products are rarely documented well enough to trust. Anthropic’s post is specific enough — named technologies, per-product breakdowns, disclosed failures — that other teams building agentic tools can benchmark against it. The full engineering post is at anthropic.com/engineering/how-we-contain-claude.