intermediate · Interactive lab
Tool Authority
An agent is exactly as dangerous as the tools it holds. Each request has three numbers — the authority asked for, the authority needed, and how many records one call could touch — and the gap between them is the accident waiting to happen.
By the end: Measure a request against the task rather than against the tool's documentation: authority, scope and reach.
Your challenge
Start here. This lab opens with every request allowed, which is the wrong starting point and how most agent pilots are actually wired. Four of these should be granted in a narrower form, one should wait for a person, and one is genuinely fine as asked — and refusing the last one would only stop the work.
See it happen
Asked for, needed, and what it could touch
- The agent → The task
- The task → Tool surface
- Tool surface → The system
An agent is its tool surface
The agent asks the Tool surface for what it needs. Everything it can do to The system is on that surface, and nothing about how it was prompted adds to it or takes away.
Learn more
Why this pattern exists
An agent that can reason beautifully and holds a single read-only tool cannot do much harm. The same agent holding a bulk update over every record in the tenant can ruin an afternoon in one step, and nothing about how it was prompted changes that. So the first question in an agentic design is not what the model can do; it is what the tool surface allows. And a tool appearing in the agent’s list is not the same as the agent being allowed to use it that way: what it can see, what it asked for and what it is granted are three different things, and only the third one is a decision anybody made. Each request here carries three things: the authority the agent asked for, the authority its task actually needs, and how many records one call could touch. Where those disagree, the difference is not a style preference — it is the size of the worst plausible accident. And the answer is rarely just yes or no: most of these requests should be granted in a narrower form, and one of them should stop and wait for a person.
An agent handles customer-service tasks against the order and payment systems. Seven requests, each showing what the agent asked for, what its task needs, and what one call could touch. The tool surface is the real thing being designed here; the agent's reasoning never appears.
- Measure a request against the task rather than against the tool's documentation: authority, scope and reach.
- Tell a reversible call from a recoverable one and from an irreversible one, and treat the third differently.
- Narrow a grant instead of refusing it, and know when refusing only stops the work.
The rule this lesson applies: Least privilege for agents is the same discipline as for any other principal, with one difference: an agent will use everything it holds, immediately, without the pause a human takes when something looks odd. Three rules carry most of it. Grant the authority the task needs — a task that reads should not hold a write, and a task that writes should not hold a delete. Grant the reach the task needs — the difference between one order and every order in the tenant is the difference between a mistake and an incident. And treat irreversibility as its own axis: a refund and an email leave the system, so they are not undone by a rollback, and they are where a human belongs unless a dry run can show what would happen first. The opposite failure is real too. An agent whose every request is refused does not become safe; it becomes useless, and the team routes around it with a service account that has more authority than anything here. Refusing a request the task genuinely needs is graded as an error in this lesson for exactly that reason.