Sandboxing and Least Privilege
Containers, VMs, scoped credentials, and network rules: limit the blast radius of any agent mistake.
Here's a useful mental exercise: assume your agent will, at some point, run the worst command it's capable of running. Maybe a prompt injection tells it to. Maybe it misreads a task. Maybe it decides that deleting a directory is the fastest way to make a failing test go away. You can't make that probability zero, but you can decide what "the worst command it's capable of" actually is.
That's what sandboxing and least privilege are for. Together they limit the blast radius, how much damage any single mistake can do. In this lesson you'll learn the isolation options from lightweight to heavyweight, run an agent in a locked-down container, restrict its network to an allowlist, and replace broad credentials with narrow, short-lived ones.
Blast radius thinking
Every agent setup has an implicit answer to "what's the worst that could happen?" Make it explicit.
| Setup | Worst realistic outcome |
|---|---|
| Coding agent on your laptop, full permissions | Deletes your files, reads your SSH keys and browser cookies, pushes to any repo you can access |
| Same agent in a container with only the project mounted | Damages the project folder (recoverable from git) |
| Container with no network | Damages the project folder; can't send anything anywhere |
| Ephemeral cloud sandbox with a read-only, single-repo token | Wastes some compute; opens a bad pull request you reject |
The capability of the model is identical in every row. Only the environment changed. That's the key insight: you don't make an agent safe by making it smarter, you make it safe by making its mistakes cheap.
Two principles guide everything below:
- Isolation: the agent runs somewhere separated from things it shouldn't touch.
- Least privilege: within that space, it holds only the permissions its current job requires, for only as long as it needs them.