# Agent Sandboxing > Containment architecture for agent products that execute code, browse, or call tools, distilled from Anthropic's \"How we contain Claude across products\". Use when designing or reviewing sandboxing, isolation, permission systems, egress controls, or untrusted-content handling for an agent, or when choosing between container, OS-sandbox, and VM isolation patterns; provides a threat-model checklis… - **Type:** Skill - **Install:** `agentstack add skill-archive228-lab-skills-agent-sandboxing` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [Archive228](https://agentstack.voostack.com/s/archive228) - **Installs:** 0 - **Category:** [AI & ML](https://agentstack.voostack.com/c/ai-and-ml) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [Archive228](https://github.com/Archive228) - **Source:** https://github.com/Archive228/lab-skills/tree/main/skills/agent-sandboxing ## Install ```sh agentstack add skill-archive228-lab-skills-agent-sandboxing ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Agent Sandboxing: Containment Architecture for Agent Products This skill gives you Anthropic's production containment methodology for agentic systems, distilled from how Claude is contained across claude.ai, Claude Code, and Claude Cowork. It covers the three risk classes to threat-model against, the three defense layers and how to order them, three concrete containment patterns matched to user capability, and the specific vulnerabilities Anthropic hit in production (pre-trust-prompt config parsing, credential exfiltration via allowed API endpoints, approval fatigue) so you don't rediscover them. ## When to use Use this skill when: - Designing or reviewing the sandbox/isolation architecture for a product where an agent executes code, runs shell commands, browses, or calls tools. - Writing or auditing a threat model for an agent feature. - Choosing isolation primitives (container vs. OS sandbox vs. VM) or deciding where a permission prompt belongs. - Adding MCP servers, plugins, connectors, or web access to an agent. - Reviewing code that parses project-local config, resolves file paths, or filters network egress for an agent. Do NOT use this skill for: general application security review unrelated to agents, model alignment/training work, or content-policy moderation design. It is about containment of agent actions, not about what the model says. ## Rules 1. **Threat-model against all three risk classes, not just one.** (a) User misuse: users maliciously or carelessly directing the agent toward harmful actions. (b) Model misbehavior: unprompted harmful actions — more capable models make fewer mistakes but are better at finding unexpected paths to a goal, routing around restrictions nobody wrote down. (c) External attackers: compromising the agent through tools, files, or network access — both prompt injection and conventional runtime attacks. A defense that addresses only one class is incomplete. 2. **Design for containment at the environment layer first, then steer behavior at the model layer.** Environmental controls (process sandboxes, VMs, filesystem restrictions, egress controls) are hard boundaries that hold regardless of cause — user, model, or attacker. Model-layer defenses (system prompts, classifiers, probes, training) are probabilistic and will never be 100% effective; they cannot stand alone. 3. **Know the model layer's real numbers and size the environment accordingly.** Reference points from the source: Claude Opus 4.7 prompt-injection success on Gray Swan's Agent Red Teaming benchmark is roughly 0.1% on single attempts but 5–6% after 100 adaptive attempts — adaptive attackers get through eventually. Claude Code auto mode (a model-based classifier for command approvals) catches roughly 83% of overeager behaviors before they execute, blocks roughly 0.4% of benign commands, and misses ~17%. Treat these layers as blast-radius reducers, not barriers. 4. **Keep credentials out of the sandbox entirely.** 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 Anthropic's internal red-team phishing test, a malicious prompt telling Claude Code to read `~/.aws/credentials`, encode the contents, and POST them to an external endpoint completed the exfiltration 24 times across 25 retries. Egress controls and credential isolation are what get hit when everything probabilistic misses. 5. **Default-deny network egress; allowlist explicitly.** Claude Code's OS-level sandbox (Seatbelt on macOS, bubblewrap on Linux) denies network by default and restricts writes outside the workspace — and this produced an 84% reduction in permission prompts, because a hard boundary removes the need to ask. 6. **Do not trust destination-based egress filtering alone; authenticate the requester.** Anthropic's egress proxy saw traffic to `api.anthropic.com` and let it through — but the request carried an attacker-controlled API key planted via hidden instructions in a workspace file, turning the trusted endpoint into an exfiltration channel. The fix: a defensive man-in-the-middle proxy inside the VM that only passes requests carrying the VM's own provisioned session token; attacker-embedded keys are rejected. 7. **Establish the trust boundary before parsing anything.** Three separate vulnerabilities exploited code that ran before user consent: input from a not-yet-trusted directory was parsed before the trust boundary was established. Defer parsing and execution of project-local configuration until after the user accepts the trust prompt. Give project-open, config-load, and localhost listeners the same suspicion you would give unsolicited traffic arriving from the internet. 8. **Match isolation strength to user capacity.** A developer who can read bash and a knowledge worker who can't are not running the same threat model. The three patterns: - **Ephemeral container** (claude.ai code execution): fully server-side, gVisor container on isolated infrastructure, per-session ephemeral filesystem, no code on the local machine. Minimal blast radius. - **Human-in-the-loop OS sandbox** (Claude Code): OS-level sandboxing plus approvals for operations that cross the boundary — appropriate when the user can evaluate what they're approving. - **Sealed virtual machine** (Claude Cowork): platform hypervisors (Apple Virtualization framework on macOS, HCS on Windows) enforcing absolute, always-on boundaries — required when users cannot evaluate commands, so approval prompts can't carry the load. 9. **Budget for approval fatigue; don't use prompts as your main defense.** Before sandboxing, Claude Code users approved roughly 93% of permission prompts, and experienced users auto-approve roughly twice as often as new users. The more approvals a user sees, the less attention each gets. Reduce prompt volume with hard boundaries; reserve prompts for genuinely boundary-crossing actions. 10. **Prefer battle-tested primitives over homegrown isolation.** "The weakest layer is the one you built yourself" (Anthropic). Mature hypervisors, syscall filters, and container runtimes — gVisor, seccomp — have absorbed years of scrutiny from well-resourced adversaries, far more than any isolation code you will write for an agent product. Concentrate security review on the custom pieces (proxies, glue code), not on reimplementing isolation. Agents still read files, open sockets, and spawn processes, so mature containment tooling applies directly. 11. **Enforce your most critical boundaries outside the guest kernel.** Of the six main isolation mechanisms in Claude Cowork's VM, only two are enforced outside the guest kernel and would survive the agent achieving root inside the VM; the other four are guest-enforced and deliberately minimal because the outer layers carry the rest. The source identifies the sealed VM's outer guard as the vsock host-guest channel plus the hypervisor boundary. Know which of your controls survive full compromise of the sandboxed environment. 12. **Structure the architecture so only code execution needs the strongest isolation.** Claude Cowork initially ran the entire agent loop inside the VM, then moved the loop outside while keeping code execution inside — this fixed reliability problems (a VM startup failure no longer bricks the product) with minimal security impact, since the VM still enforces filesystem and network controls over the code the agent executes. Local MCP servers were also moved outside the VM: inside, they were harder to audit, broke when the VM updated, and could not reach the local processes (such as databases) they needed. 13. **Offer graded filesystem access and resolve symlinks before validating paths.** Claude Cowork's mount modes are read-only, read-write, and read-write-no-delete. Resolve any symlink first and validate the resolved target — if you validate the path before resolving it, a symlink sitting inside an authorized folder can silently redirect access outside it. 14. **Treat every external resource as two risks at once:** a code-execution risk in the traditional supply-chain sense, and a prompt-injection vector. This applies to files, tool results, MCP servers, and plugins alike. 15. **Distinguish local from remote tools when granting trust.** A locally installed tool is auditable; a remote tool (hosted MCP server, cloud connector) can change behavior at any point after approval — the install-time trust decision may no longer apply. Treat anything outside your vetted set as untrusted: exercise it on fake data inside a contained environment before it ever touches real data. 16. **Limit tool permissions granularly to shrink blast radius.** An agent holding read-only database access is deployable in far more places than one that can write to production. And remember: "an audited connector isn't the same as audited data" (Anthropic) — a clean connector can still deliver poisoned content. 17. **Inspect tool output live, not in post-hoc log review.** Once a poisoned tool return has steered the agent into exfiltrating data, all the log records is a normal, authorized API call — nothing remains for after-the-fact review to catch. Tool output is an attack surface even when the tool is trusted. 18. **Plan for host security tooling visibility early.** Strong isolation cuts both ways: from a host EDR's perspective, Claude Cowork is an opaque hypervisor process, so the same boundary that contains the agent also blinds endpoint detection. Anthropic's current mitigation is pull-based OTLP exports that let administrators retrieve event logs after the fact. If you're building something similar, budget for this conversation with security teams early. 19. **Watch the emerging risks.** (a) Persistent memory poisoning: as more agent context persists across sessions, an injection landing in product memory or workspace state gets reloaded on every startup. (b) Multi-agent trust escalation: if a sub-agent's output is treated as higher-trust than raw tool results, sub-agents meant to isolate untrusted content become injection amplifiers. (c) Agent identity: whether agents hold independent principal identity or inherit user permissions is unsettled (see NIST's project on AI agent identity and authorization); the answer may be a blend. ## Checklist Threat model: - [ ] All three risk classes covered: user misuse, model misbehavior, external attackers (prompt injection AND conventional runtime attacks). - [ ] For each control, identified whether it is environmental (hard) or model-layer (probabilistic). - [ ] For each control, identified whether it survives root/full compromise inside the sandbox. Environment: - [ ] Isolation primitive is battle-tested (gVisor, seccomp, Seatbelt, bubblewrap, platform hypervisor) — not homegrown. - [ ] Security review effort concentrated on custom components (proxies, glue), not the mature primitives. - [ ] Credentials, API keys, and tokens never enter the sandbox. - [ ] Network egress is default-deny with an explicit allowlist. - [ ] Egress proxy authenticates the requester (e.g., only the environment's own provisioned session token), not just the destination host. - [ ] Writes restricted to the workspace; filesystem access graded (read-only / read-write / read-write-no-delete where applicable). - [ ] Symlinks resolved before path validation. - [ ] No parsing or execution of project-local config, and no localhost listeners active, before the user accepts the trust prompt. Model layer and permissions: - [ ] Model-layer defenses (classifiers, prompts) treated as risk reduction with measured catch/miss rates, never as the sole barrier. - [ ] Approval prompts reserved for boundary-crossing actions; prompt volume actively minimized (approval fatigue: ~93% approval rates observed without it). - [ ] Isolation strength matched to the user: sealed VM if users cannot evaluate commands; human-in-the-loop sandbox only if they can. External content and tools: - [ ] Every external resource assessed as both supply-chain risk and injection vector. - [ ] Remote tools re-evaluated over time (they can change after approval); new/unvetted tools tested against fake data in a contained environment first. - [ ] Tool permissions minimized (e.g., read-only DB access where possible). - [ ] Tool returns inspected live for injection, not only logged. - [ ] Persistent memory/workspace state treated as an injection surface reloaded each session. - [ ] Sub-agent output NOT granted higher trust than raw tool results. Operations: - [ ] Host security/EDR visibility plan exists (e.g., pull-based OTLP event-log export) and was discussed with security teams early. ## Anti-patterns - Building your own isolation layer instead of using hardened primitives — in Anthropic's own incident, the piece that failed was the custom allowlist proxy, not the mature primitives around it. - Relying on model refusals or classifiers as the only defense; adaptive attackers reach 5–6% success over 100 attempts even against a hardened model. - Destination-only egress allowlists: a trusted API endpoint plus an attacker-controlled key is an exfiltration channel. - Parsing repo/project config, or exposing localhost listeners, before the trust prompt is accepted. - Adding more permission prompts as a security fix — users approve ~93% and attention decays with volume. - Validating paths before resolving symlinks. - Treating install-time approval of a remote MCP server or connector as a durable trust decision. - Assuming an audited connector means audited data. - Trusting sub-agent output more than raw tool output. - Counting on log review to catch injection-driven exfiltration — the record looks like a normal, authorized call. - Shipping the same isolation pattern to developers and non-technical users; they are not running the same threat model. ## Source - How we contain Claude across products — https://www.anthropic.com/engineering/how-we-contain-claude — 2026-05-25 Distilled from the official document(s) above on 2026-08-12. If this skill and the source disagree, trust the source. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [Archive228](https://github.com/Archive228) - **Source:** [Archive228/lab-skills](https://github.com/Archive228/lab-skills) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-archive228-lab-skills-agent-sandboxing - Seller: https://agentstack.voostack.com/s/archive228 - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.