Authority Tokens: How PACT5 Scopes Agent Permissions
The core technical mechanism in PACT5 is the authority token. This post explains what they are, how they work, and why they matter.
An authority token is a scoped, delegatable, revocable permission grant. It defines exactly what an agent is allowed to do. Not what tools it can access — what actions it's authorized to perform.
Scoped. A token specifies the operations it covers. A token scoped to read:repository allows reading code. It does not allow writing, deploying, or deleting. The scope is explicit, not inferred from the agent's tool access.
Time-bounded. Tokens expire. A token granted for a code review session doesn't persist after the review is done. This prevents authority from accumulating — a problem in any system where permissions are granted but never revoked.
Delegatable with narrowing. An agent holding a token can delegate a subset of that token's authority to another agent. Never a superset. If Agent A holds read:repository, write:repository, it can delegate read:repository to Agent B. It cannot delegate deploy:production because it doesn't hold that scope.
Revocable with cascading. Pull a token, and every token delegated from it is automatically revoked. This is critical. If you discover an agent is misbehaving, one revocation action severs its entire delegation tree. No hunting through downstream agents to find and revoke individual tokens.
Attestable. Every action taken under a token is recorded with the token's identity. You can audit exactly what happened, under whose authority, and when. Not for surveillance — for accountability.
The practical effect: agents operate with the minimum authority they need, for only as long as they need it, and every action is traceable to a human who initiated the delegation chain.
This is how you build multi-agent systems you can actually trust.