Concepts

Non-amplification

Agents delegate. A planner hands a step to a worker; a worker calls a tool that calls another service. The risk in any hand-off is that authority quietly grows along the way, so the worker ends up able to do more than the planner was ever allowed to. auth51’s answer is a rule with a plain name: authority can go down a chain, never up.

The grant is the ceiling

Every registered agent has a grant: the set of scopes it may mint tokens for, plus a smaller set of step-up scopes it may reach only after an explicit escalation. When the agent asks the authority to mint a token, the request has to fall inside that grant. Ask for a scope outside it and the mint is refused. Ask for a step-up scope and you need an approved escalation first. The grant is set when you register the agent and enforced at mint time, not audited after the fact.

Note

Grants roll out in two modes. A freshly seeded grant starts in 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 start blocking. Enforcement is real; it’s just opt-in per agent so adoption is safe.

Delegation can’t widen the envelope

Because every agent is bounded by its own grant, a hand-off can’t manufacture authority. A worker invoked by a planner still mints against the worker’s grant, not the planner’s. When a run follows a registered workflow, the authority also checks the step against the workflow definition (its declared scopes, its dependencies, and any approval gates) before it mints. A step can’t claim scopes the workflow didn’t give it, and it can’t run before the steps it depends on have completed.

AUTHORITY ONLY NARROWS — EACH HOP ⊆ THE LASTsupervisorrepo:* deploy:*plannerrepo:writepatcherrepo:write · 1 file
Figure 1. Down a delegation chain, each agent mints against its own grant and the authority only narrows. The token that reaches a resource is a subset of every grant above it, never a superset.
What the authority actually checks at each mint

When a request carries a delegation_context, the authority validates the chain before it mints: every agent named in the chain is registered, the chain is a path each parent actually authorized, and the requesting agent is the last link. draft-goswami-agentic-jwt §4.3.4

For a workflow run it adds step checks: prerequisite steps must be complete, approval gates for high-privilege steps must have been passed, and a step can only claim the scopes its workflow definition granted it. No skipping ahead, no widening.

Delegation depth is bounded to stop runaway chains, and if a parent agent is found compromised, the whole delegation chain beneath it can be revoked at once. draft-goswami-agentic-jwt §9.3

Where this is headed

Today the ceiling is enforced per agent and per workflow step, which is what stops amplification in practice. The protocol draft goes further: a formal, checkable guarantee that a token derived across a hop is a strict subset of the one it came from, verifiable independently at each resource. That deeper cross-hop enforcement is being hardened alongside the verifier. The model is fixed; the machinery is landing.