Your delegation chain is in the audit log, not in the decision

Here is a sentence from RFC 8693 that has aged strangely. The actor claim — the act member that records who is acting on whose behalf — can nest, so a token can carry a whole chain of delegation. And then the spec says the nested actors are informational: a consumer "is not to use" them to make an access-control decision. Only the top-level actor counts.

When token exchange was a federation primitive that fired once at a trust boundary, that was a fine rule. The chain was one hop deep. There was nothing to enforce.

Agents broke that assumption quietly. An agent receives a task, decides it needs a sub-agent, hands off. The sub-agent decides it needs a tool that lives behind another agent, hands off again. The chain is now three, four, five hops deep — and it was assembled at runtime by the agents themselves, not drawn on anyone's architecture diagram. The token can describe that chain. The authorization decision, per the spec it came from, looks only at the top.

The two bad options at every hop

Walk a single hop. Agent A holds a token. It needs Agent B to do part of the work. A has exactly two moves:

1. Pass its own token down. B now holds everything A holds. The token that checked flight availability also authorizes charging the corporate card — to borrow the example from the recent IETF draft on this. Overprivileged by default.
2. Mint B a fresh token from the authorization server. Now you've got a network round-trip on every hop (the AS becomes a hard dependency for the whole workflow), and — more subtly — the new token's lineage to A is informational at best. The decision point downstream can't tell that B's authority is supposed to be a subset of A's.

So every hop is a choice between too much authority and no provenance. Pick one. The chain gets longer and you pick again.

WorkOS put it cleanly: the protocol can represent the delegation chain but cannot enforce it. The audit log captures every token exchange. It does not capture — and the decision does not consult — the thing you actually care about, which is whether the authority got narrower as it went down.

Why "narrower as it went down" is the whole game

The property you want has a name in capability systems that predates all of this: monotonic attenuation. Authority can only shrink down a delegation chain, never grow. A child can be handed less than its parent holds. It can never be handed more.

If that property is enforced rather than hoped for, the multi-hop problem mostly dissolves:

• A compromised sub-agent four hops deep can only ever wield a subset of a subset of a subset of the root. The blast radius is bounded by construction, not by audit-after-the-fact.
• The decision point stops needing to trust the intermediaries. It needs to trust one root anchor and then check that each link only narrowed.

This is the same instinct behind macaroons (Google, 2014) — a credential you can hand someone with caveats attached that they can tighten but not loosen. The idea isn't new. What's new is that we finally have a delegation topology — agents spawning agents — where we genuinely need it, instead of treating it as an exotic capability-systems flourish.

What enforcing it actually looks like

The March 2026 draft is the most concrete sketch I've seen, and it's worth reading for the shape even if the wire format changes. At each hop the holder derives a child token, and the derivation has to satisfy subsetting:

• The child's tools must be a subset of the parent's.
• For each tool, the argument constraints must get strictly tighter — an exact stays exact, a range can only narrow, a one_of can only drop members.
• The child's expiry can't exceed the parent's.
• Each link is signed by the parent's key, so the chain is cryptographically linked back to the root.

The verifier then does something the RFC 8693 reader explicitly wasn't allowed to do: it walks the whole chain. Root signature against the trust anchor, then link by link — did this child only narrow its parent? — with no calls to an authorization server. The chain is self-describing and offline-verifiable. The dependency on the AS that made fresh-token-per-hop fragile just goes away, because the authority to attenuate travels inside the token.

That's the inversion worth sitting with. RFC 8693 said: carry the chain, decide on the top. Attenuation says: the chain is the decision.

The actual hard part

It isn't the crypto. Signing a link per hop is cheap and the verification is linear in chain depth.

The hard part is the same one that bites every agent-authorization scheme: defining the subsetting rules for arguments that aren't enums. Tools subset, expiries subset — easy, those are sets and numbers. But "this child may only call send_email with recipients in the same domain as the parent's allowed recipients" is a constraint-subsumption problem, and real tool arguments are strings, paths, query filters, free text. You need a constraint language expressive enough to say "tighter" and decidable enough to check it. The draft gestures at this with constraint types like pattern, range, and cel-style expressions, and that's exactly where the real design work is.

It's still the right place to spend the effort. A delegation chain you can only read after the fact is an incident report. A delegation chain the decision point actually walks is a control.

The token always could carry the chain. We just spent fifteen years told not to look at it.