Claude AI Sandboxing: Principle of Least Privilege
LLM agents pose a unique risk class: they can execute arbitrary commands, exfiltrate data, and modify systems at your trust level. Sandboxing isn't optional—it's attack surface reduction for your terminal.
Risks Addressed
| Threat Vector | Mitigation |
|---|---|
Credential theft (~/.aws/, ~/.ssh/) |
Read restriction via filesystem deny/allow |
| Lateral movement across home directory | Scoped access to project root only |
| Command injection via prompt | OS-enforced sandbox wall |
| Accidental destructive operations | Approval workflow modes |
Configuration
Per-Project Enforcement
.claude/settings.json
Out-of-the-box macOS sandboxes grant read access to the entire disk except blacklisted directories—including credential stores.
This violates least privilege. The above configuration implements zero-trust filesystem access: deny everything, then explicitly whitelist only the project root (. resolves to working directory in project settings).
Global Baseline
~/.claude/settings.json
Operational Modes
Access via /sandbox panel:
| Mode | Behavior | Security Posture |
|---|---|---|
| Auto-allow | Commands run without prompts | Recommended the OS wall is your real protection, not approval UI |
| Regular permissions | Prompts on every command | Defense-in-depth layer, but UX friction may lead to disabling sandbox |
Auto-allow + hardened filesystem rules. The approval prompt creates a false sense of security when the actual boundary is the kernel-enforced sandbox.
Verification Checklist
- Confirm
~/.claude/settings.jsonhas sandbox.enabled: true - Verify per-project
.claude/settings.jsondenies home directory reads - Test: attempt to read
~/.ssh/keysfrom within sandboxed session (should fail) - Validate credentials are inaccessible in agent logs or outputs