Chapter 06 · Section III · 10 min read
Sandbox and boundaries
The safest environment for aggressive AI-assisted work is one where the blast radius is small by construction. Sandboxes, containers, disposable VMs — what they buy you and where they stop.
Trust and blast radius are the two dials of AI safety. You can trust the assistant more or less. You can also make the environment it acts in more or less consequential. Adjusting the second dial is often easier than adjusting the first — and it is where sandboxing earns its keep.
What a sandbox buys you
A sandboxed session is one where the assistant cannot affect anything outside a bounded scope. Common shapes:
- A dev container. Codebase mounted read-only or with a scratch overlay. Networking restricted to specific hosts.
- A cloud VM. Cheap, disposable, easy to nuke. No production credentials mounted.
- A local branch of a repo you have already pushed. If Claude makes a mess,
git reset --hard origin/mainis safe. - A GitHub Codespace / DevPod. A prebuilt environment your team uses; not your laptop.
The point is not to prevent Claude from acting. It is to make its actions cheap to undo.
Sandbox mode inside Claude Code
Claude Code has an internal notion of a “sandbox” mode too — a flag that says “for the following block of work, treat everything as reversible.” Under sandbox mode:
- Auto-approval is safer (blast radius is bounded).
- Aggressive exploration is cheap (you can just wipe the environment after).
- Bugs are recoverable (state is disposable).
Not every install exposes exactly this flag with exactly this name, but the concept — “am I in an environment where I can afford to be lax?” — is worth carrying around.
Where the sandbox stops
A sandbox is not a security boundary against a malicious model. It is a scope boundary against a well-meaning-but-imperfect one. Two failure modes worth naming:
- Credentials leak from the sandbox. If your
.envinside the container has real production keys, “sandboxed” is a marketing term. Use fake secrets in dev environments. - The MCP servers you enabled reach outside the sandbox. A Notion server writing to your real Notion workspace does not care that Claude is running in a container. Scope your MCP too.
When the sandbox is worth setting up
- First time trying an autonomous mode. Long-running loop, hooks that run on every save — start in a container.
- Aggressive refactors on a big codebase. You want to be able to bail out.
- Trying an unfamiliar MCP server. Contained blast radius while you evaluate it.
- Any time you feel yourself pre-emptively worrying “what if it does the wrong thing”. That worry is a signal to reduce blast radius.
Check your understanding
Quick check
—