Concepts
Intent tokens
A normal access token says “the bearer may act as this client.” It’s broad, it’s reusable, and anyone who copies it can do everything the client can, for as long as it’s valid. For an agent making dozens of calls a minute, that’s a lot of standing power to leave lying around.
auth51 replaces it with an intent token: a short-lived credential minted for one action, at the moment the agent takes it.
One token, one intent
When your agent is about to touch a resource — charge a card, read a repo, delete a row — the client mints a token scoped to exactly that: the agent’s identity, the single action, and the audience it’s for. It’s good for minutes, not hours or days. The resource server verifies it and does the one thing it authorizes. There’s no broad, long-lived session sitting around to steal.
Bound to a key the agent can’t hand over
A stolen token is only useful if you can present it. Each intent token is bound to an ephemeral key held inside the agent’s process — proof-of-possession, DPoP in the spec. To use the token you have to prove you hold that key. Copy the token out of a log and it’s inert: you don’t have the key, and it expires shortly anyway.
What the resource server actually sees
On the wire it’s an ordinary JWT you can decode and inspect. It carries the agent’s identity, the single scope and audience, a tight expiry, the key binding, and — nested under intent and agent_proof — the evidence that ties this action to a verified agent and an unbroken delegation path.
▶The claims, one by one
The standard JWT claims do the ordinary work: iss (the authority), aud (the one resource this token is for), sub (the agent), and scope (the single permission). Two matter especially for agents: exp is iat + 300s — five minutes — and jti is a unique id a resource server can remember to reject a replay.
cnf.jkt is the DPoP key binding — the thumbprint the caller must prove it holds (see proof-of-possession).
The intent object carries the action itself:workflow_step (the one step being executed),executed_by, and two integrity hashes —delegation_chain and step_sequence_hash.
The agent_proof object carries agent_checksum — the verified identity fingerprint — and registration_id, the handle used to revoke a compromised agent’s registration wholesale. draft-goswami-agentic-jwt §4.4.2
It can’t grant more than it was given
When one agent hands work to another, or a single call fans out into several, the token can’t quietly widen along the way. A derived token is always a subset of the one it came from, never a superset. auth51 calls this non-amplification, and it’s enforced when the token is minted, not checked after the fact.
▶How the token proves the path wasn’t tampered with
Two claims make the execution path self-verifying. When an agent delegates, the chain of agent ids is joined with pipes and hashed —SHA-256("supervisor|planner|patcher"), truncated to 16 hex chars — and carried as delegation_chain. Completed workflow steps are hashed the same way into step_sequence_hash.
The authority rejects a request whose chain or step sequence doesn’t match what the workflow permits — so a bad path never gets a token. Carrying the hashes in the token means a resource server can independently detect a skipped step or an altered delegation chain too, without calling back to the authority. draft-goswami-agentic-jwt §4.4.4