Concepts
Grants & scopes
Every registered agent carries a grant: the fixed envelope of authority it’s allowed to draw on. Scopes describe individual permissions; the grant is the set of them an agent may ever mint a token for. It’s the ceiling — and it’s checked every single time, at mint, not audited afterward.
Scopes: one permission each
A scope is the familiar OAuth unit — repo:write, vulnerability:read, payment:charge — naming one capability against one audience. auth51 doesn’t change what a scope is; it changes how tightly a token is held to one. An intent token is minted for exactly the scope its single action needs, drawn from what the grant allows.
The grant: base and step-up
A grant has two tiers. The base scopes are what the agent may mint freely. A smaller set of step-up scopes are ones it can reach only after an explicit escalation — the higher-privilege actions you want gated behind an approval rather than available by default. Ask for a base scope and the mint proceeds if it’s in the grant; ask for a step-up scope without an approved escalation and the mint is refused.
Enforced at mint, held by the Authority
The grant is set when you register the agent and lives in the Authority’s /grants surface. When the agent asks to mint, the request must fall inside the grant or it’s denied — there is no path by which an agent mints a token for a scope it wasn’t granted. That’s the mechanism behind non-amplification: because every agent is bounded by its own grant at mint time, no hand-off can manufacture authority.
Note
observe: the Authority logs what it would deny but lets the call through, so turning auth51 on never breaks a working app. You move a grant to enforce when you’re ready for it to block. Enforcement is real — it’s just opt-in per agent so adoption is safe.▶How a customer key’s envelope relates to an agent’s grant
A customer’s API key carries its own scope envelope — the outer bound of everything that key is entitled to. An individual agent’s grant is a subset of that envelope: registering an agent can only ever carve out authority the key already has, never exceed it. The two nest, so the key bounds the org and the grant bounds the agent.
When a run follows a registered workflow, a third bound applies on top: the workflow’s per-step scopes. A step can only claim what all three — key, grant, and workflow step — permit. See workflows & steps. draft-goswami-agentic-jwt §4.3