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 IronClaw (or equivalent) for production-adjacent agents
Process-level capability enforcement. Agent can only do what its manifest declares — not what it can convince you to let it do.
-
4. Never give an agent sudo or admin
If a task needs privileged access, you do that part. Full stop.
Real-world examples
- An agent with shell access ran rm -rf ./node_modules — except it was in the user's home directory, and the command expanded differently than the prompt intended.
- A coding agent pushed a feature branch with secrets to the wrong repo (public). Sandbox would have prevented git-push entirely.
Examples are illustrative, composited from public incident reports and community posts.
Applies to
← Back to the security hub · See also the hardening checklist.