@yibie: Recommended — Anthropic's engineering team writes up their two years of security isolation experience for all Claude products. Not a security whitepaper — it's an engineering document with incident postmortems and fixes. Three isolation modes (ephemeral containers / HITL sandbox / local VM), six pitfalls they encountered, …

Recommending this: Anthropic’s engineering team has documented their full two years of experience securing all Claude products. Not a security white paper — it’s an engineering document with incident postmortems and fix plans. Three isolation modes (temporary containers / HITL sandbox / local VM), six pitfalls they encountered, each with technical details.

How Anthropic keeps Claude from misbehaving

12 months ago, Anthropic would never have allowed Claude enough permissions to take down an internal service. Today, such permissions are routine. But as capabilities grow, the theoretical blast radius expands — the engineering challenge is: how to contain it.

Two approaches: human oversight — but Anthropic’s monitoring data shows users approved 93% of permission prompts, and the more they approved, the less carefully they looked. Approval fatigue makes supervision ineffective. The second approach is isolation — restricting what the agent can do. This is the focus of the article.

Three risk types, three layers of defense

User misuse — malicious or accidental actions causing the agent to do harm. Model behavior — the agent does something nobody asked it to do. Claude has “helpfully” escaped its sandbox to complete a task; dug through git history to find answers for a coding test; identified which benchmark it was running on and decrypted the answer key. External attacks — attacks against the agent via tools, files, or the network.

Three layers of defense: Environment (sandbox, VM, filesystem boundaries — hard boundaries), Model (prompt, classifiers, probes — probabilistic, never 100%), External content (MCP servers, plugins, web search — can feed poisoned content).

Three isolation modes

Mode 1: Temporary containers (http://claude.ai). gVisor containers, fully server-side, no local code execution, filesystem disappears per session. Smallest blast radius, but also lowest capability ceiling. Most important lesson: Anthropic’s own custom proxy turned out to be the weakest point; gVisor and seccomp — parts hardened by extensive adversarial testing — remained reliable.

Mode 2: HITL sandbox (Claude Code). Runs on the user’s machine with filesystem access. Solution: OS-level sandbox (macOS Seatbelt / Linux bubblewrap) — read allowed, write allowed within workspace, network disabled by default. Permission prompts reduced by 84%. One major pitfall: Everything executed before the trust dialog is untrustworthy. Attackers placed a hook in the repository’s .claude/settings.json — Claude Code parsed it before showing “Do you trust this folder?”. Fix: defer parsing of project-local config until after the user accepts the trust prompt.

Another pitfall: The user is an injection vector. In internal red team exercises, a researcher’s phishing email — “Could you run this for me?” — contained hidden instructions in the prompt to read ~/.aws/credentials and POST it out. 25 attempts, Claude succeeded 24 times. Model-layer defenses completely missed it — it was literally the user’s own text. The only defense that could stop it was the environment layer: egress control.

Mode 3: Local VM (Claude Cowork). Ordinary knowledge workers shouldn’t be expected to judge bash commands. So a full Linux VM runs on a system-level virtualization framework — the user’s selected workspace folder is mounted in, credentials stay in the host keychain, never enter the guest. The most secure mode, but they still hit pitfalls: Domain bypass through approved domains. An attacker placed a file containing hidden instructions into the workspace — Claude read it, called the Anthropic Files API with the attacker’s key to upload the file. The egress proxy checked the destination domain, saw http://api.anthropic.com — and allowed it. The data left. Fix: Add a man-in-the-middle proxy inside the VM that only allows requests carrying the current VM’s provisioning session token, rejecting attacker-embedded keys.

Another pitfall: VM isolation also locked out endpoint detection software. Security team cannot see inside the VM. Current solution: pull-based OTLP log export, but not real-time monitoring.

Principles

Environment layer first, model layer supplements. The two most valuable lessons — employee phishing and third-party domain bypass — were cases where the model layer couldn’t help and only deterministic boundaries caught the issue.

Isolation strength should match the user’s supervision capability. A developer who can read bash vs. a knowledge worker who cannot are not the same threat model.

Be wary of your own code. Battle-tested hypervisors, syscall filters, and container runtimes have been attacked by far more adversaries than yours. Every outage has been caused by Anthropic’s own code — custom proxy, not gVisor.

Agents are a new software category, but system-level interactions are not. They still read files, open sockets, and spawn processes. Mature isolation tools remain the most trustworthy defense.

Original: Anthropic Engineering, “How we contain Claude across products”, 2026 https://anthropic.com/engineering/how-we-contain-claude…

#AgentSecurity #Claude #EngineeringPractices