Agent permissions and sandboxing
Start every agent read-only. Add write access tool by tool, run code in sandboxes with no network and limited time and memory, keep agents out of production environments unless that's their explicit job, block destructive commands, and require human approval for anything irreversible. Excessive agency is its own risk category (LLM06 in OWASP's list), and the fix is permissions in code, not better prompts.
Why agents need tighter permissions than people
A person with database access rarely drops a table by accident, and almost never because a web page told them to. An agent can misread an instruction, loop, or follow text injected into a document, at machine speed. The question isn't whether the agent is smart enough to behave, it's how much damage it can do on its worst run.
Controls
| Control | Example |
|---|---|
| Read-only by default | The agent can query but not modify |
| Write access tool by tool | create_ticket allowed, delete_customer not offered |
| Command blocklist | rm -rf, DROP TABLE, git push --force blocked or require approval |
| Sandboxing | Containers or micro-VMs per run, destroyed afterwards |
| Network limits | No network, or an allowlist of hosts |
| Resource limits | Time, memory, CPU and step limits per run |
| Environment separation | Development agents never hold production credentials |
| Approval | Pause before irreversible actions |
| Audit | Every action logged, with who approved it |
Levels of action
Classify every tool:
- Read: fetching data. Usually safe to allow, within access control.
- Reversible write: drafts, tickets, comments, staging changes. Allow with limits.
- Irreversible or external: sending, paying, deleting, deploying, publishing. Require approval.
See the tool registry pattern for enforcing this in the orchestrator.
Coding agents
Coding agents with shell access can delete files, drop databases or push to main if nothing stops them. Most coding tools ask before running commands, and let you allow commands permanently. Be careful with broad permissions:
- Run unfamiliar tasks in a container or a separate checkout.
- Keep production credentials out of the development environment entirely.
- Block or require approval for destructive commands.
- Commit before each task, so you can see and undo what changed.
See coding agents.
Audit what exists today
List every permission each agent has today, and remove the ones no task needs. Then track the number of permissions per agent (it should fall), and the number of risky actions blocked or approved each week.
From the floor
In DevFix, we added a safety guard with rule-based filters, so the code the agent generated couldn't include calls that remove files, execute arbitrary commands or evaluate strings, and a human approval step, so the run only moved forward when we said yes. I showed a then-recent story of a coding agent deleting a user's data after being told not to, as the reason these controls go in from the first version, not after an incident.