Foundations

Token exchange (RFC 8693)

Of all the existing standards, OAuth Token Exchange already had the closest shape to what agents need. It takes a token you hold and hands back a different, usually narrower one, which is exactly what an agent has to do before each action.

Trading down

Token Exchange (RFC 8693) defines a grant type whose job is to accept a subject token a client already has and return a new token, optionally with a different audience, a different subject, and a reduced set of scopes. The canonical use is a service that holds a broad token and wants a tightly-scoped one to pass to a downstream service, shrinking the blast radius if that downstream token leaks.

That “shrink as you pass it along” direction is what non-amplification is built on. Every intent token is a token exchange in this sense: the client presents what it’s already authenticated with, and asks the authority to exchange it for a token good for exactly one action.

The actor claim: “A acting for B”

Token Exchange also introduced a structured way to record delegation. Its act (actor) claim captures when one party is acting on behalf of another, and those claims can nest, recording a chain such as “C acting for B acting for A.” This is the standards world’s answer to representing a delegation path inside a token.

It’s also where the standard stops. RFC 8693 defines how to record a chain; it leaves to the implementer what to enforce about it. A resource server still receives a bearer token and must parse nested JSON to discover who really acted. Auth51 takes the same idea and makes it enforceable: the delegation path is hashed into the token and validated at mint against the agents and workflow the authority actually knows.

How the agent_checksum grant sits on top

Auth51’s agent_checksum grant is token exchange with one addition: before the exchange happens, the authority verifies which agent is asking, by recomputing its checksum. The exchanged token narrows scope, and it narrows it to a proven agent identity and a single workflow step. The base standard supplies the trade-down and the delegation record while Auth51 supplies the agent proof and the enforcement.

Why not just use RFC 8693 as-is

You could implement a lot of the “narrow the token per call” behavior with vanilla token exchange. What you couldn’t get is the two things agents specifically need: proof of which non-deterministic agent inside a shared client is making the request, and a binding of the token to one concrete action rather than a scope. Vanilla token exchange narrows scope but still treats the client application as the subject and leaves intent implicit.

So Auth51 uses token exchange as the substrate and adds the checksum-verified subject and the intent claim on top, staying wire-compatible with the OAuth token endpoint while restoring the one-token-per-intent semantics agents need. draft-goswami-agentic-jwt §4