Agents, lesson 9
Limits on what an agent may do
Permissions, approvals and sandboxes.
You know the agent loop, and that your code, not the model, runs every tool call ("Observe, decide, act").
Part 1. Only the tools this task needs
An agent that reads failing build logs and explains them needs to read logs, read code and post a comment. It doesn't need to delete branches, change settings or send email. If those tools aren't there, no confused plan and no sneaky web page can make it use them.
Your turn
The agent's tools only read data. But the API token your code uses for them has full admin rights. What's the risk?
fetch(url) tool with an admin token can hit admin URLs. Give each tool credentials that allow only its own job, so a mistake in one layer is caught by the other.Least privilege
Give the agent only the tools, and each tool only the permissions, that this task needs. The list of permitted tools is its allowlist; anything not on it is refused.
In practice that means one credential per tool, scoped as tightly as the service allows: a GitHub token limited to one repository that can write only to pull requests, a database user that can read three tables and nothing else, cloud keys that expire when the run ends. When a tool's credential can't do the damage, a confused plan or an injected instruction can't either.
Part 2. Undo-able or not
Keep going with Pro
You've done the first part. Pro opens the rest of this lesson, and every other one.
- Undo-able or not
- Budgets and an off switch
- Sandboxes
Agents overviewSpotted a mistake? Tell us.