Sandboxing — contain the blast radius
Assume the agent will eventually do something wrong. Sandboxing is how you make that a small mistake instead of a catastrophic one.
The threat
An agent running as your OS user can read your SSH keys, delete your files, publish to your GitHub, and charge your credit card. The probability of a serious mistake over a year of use is not low — the question is how much damage it can do when it happens.
What to do about it
-
1. Run agents as a dedicated non-root user
On Linux/macOS, create an 'agent' user. The agent can't read your home dir, your SSH keys, or your browser profile.
-
2. Use containers for stateful work
Docker/Podman with read-only root filesystem and a dedicated data volume. Agent goes rogue? Kill the container.
-
3. Use a sandboxed runtime for production-adjacent agents
NemoClaw's OpenShell sandbox, IronClaw's WASM sandbox, Kilo Code's optional OS sandbox, Hermes' Docker backend, or your own container or VM. Prefer one that denies network access by default, so the agent can only reach what you allowed rather than whatever it can talk you into.
-
4. Never give an agent sudo or admin
If a task needs privileged access, you do that part. Full stop.
-
5. Make the network allowlist fail closed, not prompt
An allowlist that asks permission is only a boundary while someone is watching. Claude Code v2.1.219 (July 25, 2026) added sandbox.network.strictAllowlist, which denies non-allowlisted hosts for sandboxed commands without prompting. Previously an unexpected host produced a prompt, so an unattended run either stalled or got approved by whoever was nearest; strict mode fails closed instead. If you run any agent unattended (scheduled jobs, CI, a self-hosted runner), set it before you automate, not after an exfiltration attempt teaches you why.
Applies to
← Back to the security hub · See also the hardening checklist.