The tool list
Every tool the agent may call, named individually. Not a role, not a scope group — the enumerated list, because a role is a promise about a set that changes without anyone re-reading it.
Insights · Agent harnessing
An authority model for agents that call tools
The moment an agent can call a tool, it is a principal in your system. Most estates never write down what it is allowed to be.
A new class of principal
Identity systems are built around two kinds of actor: a human, and a service acting on a fixed, predictable set of operations. An agent is neither. It holds credentials like a service, but the operations it performs are decided at runtime from an input channel that an attacker can write to.
Handing that a service account with broad scopes is the default because it is what makes the demo work. It is also the reason the security review stalls, and the reviewer is right.
What an authority model contains
The grant per tool
For each one: read or write, against which resources, with which filters. Write access to one table is not write access.
The approver
A named person who approved that grant, and when. This is the field that turns a diagram into a control.
The irreversible set
Which of those calls cannot be undone. Everything in this set sits behind a human checkpoint, named, with the authority to stop it.
The escalation path
What the agent does when it needs something outside the list. The answer is stop and ask, and the point of writing it down is that the alternative is invent.
The review trigger
What event forces the model to be re-read: a new tool, a new data source, a new model version.
Why it comes before the agent
Writing the authority model first is cheap, because saying no to a capability costs nothing before anything depends on it. Writing it afterwards means removing access from something that already works, which is a negotiation rather than a decision.
It also changes the design. An agent scoped to one job with an enumerated tool list is a different, simpler system than one given broad access and asked to behave. The constraint improves the thing.
What it does not do
An authority model does not stop a prompt injection. It bounds the blast radius of one. That distinction matters, and overstating it is how these documents lose their credibility with the people who have to sign them.
It also does not replace a threat model. The authority model says what the agent may do; the threat model says what an attacker would try to make it do. You need both, and they are written by different people looking for different things.
Where this fits
Step four of the path, and the artifact you keep from it. It is written alongside the threat model, because the authority model is an agent decision and a security decision at the same time.
Send us the problem
Describe what is stuck. We will come back with an architecture, a timeline and the first commit.