Mental model
The model proposes intent; an independent policy enforcement point authorizes the exact action. Tool availability never implies permission.
Learning outcomes
- Explain the mechanism and ownership boundaries behind Tool Authorization.
- Compare the main design alternatives and their operational trade-offs.
- Diagnose common failures and select evidence for a production decision.
Theory
Authorization should bind the actor, tenant, tool, operation, resource, parameter constraints, purpose, expiry, and approval state. Recheck at execution because credentials and resource state can change after planning.
Trade-offs
Fine-grained authorization limits blast radius but increases policy complexity and denial handling. Broad credentials simplify integration but turn prompt injection into privilege escalation.
Failure modes and misconceptions
Authorizing only at login; passing user tokens into model context; trusting tool names; allowing confused-deputy calls; and failing open when policy services are unavailable.
Decision scenario
A support agent may read any ticket but refund only tickets assigned to the current operator. Design the per-call authorization decision.
Why must tool authorization be evaluated after the model chooses parameters rather than when the conversation begins?
Primary sources
oauth-security-bcpnist-zero-trust