Concepts
Intent tokens
A conventional access token allows its bearer to act as a client. The token may be broad, reusable, and valid for an extended period. Anyone who copies it can exercise its permissions while it remains valid. For an agent making frequent calls, that creates persistent authority that must be carefully protected.
Auth51 exchanges that credential for an intent token: a short-lived token minted for one action when the agent is ready to perform it.
One token, one intent
Before an agent accesses a resource, such as charging a card, reading a repository, or deleting a row, the client mints a token for that specific operation. The token identifies the agent, carries the action’s scope, and names the intended audience. It remains valid for minutes rather than hours or days, and the resource server verifies it before performing the authorized action.
Bound to a key the agent can’t hand over
Each intent token is bound to an ephemeral key held inside the agent’s process through proof-of-possession, implemented with DPoP in the specification. A caller must prove that it holds the corresponding key when it presents the token. Copying the token from a log is therefore not sufficient to use it, and the token also expires shortly afterward.
What the resource server actually sees
On the wire, the intent token is an inspectable JWT. It carries the agent identity, one scope, the intended audience, a short expiry, and the key binding. The nested intent and agent_proof objects contain the evidence that connects the action to a verified agent and its delegation path.
▶The claims, one by one
Standard JWT claims provide the common token semantics: iss (the Authority), aud (the one resource this token is for), sub (the agent), and scope (the single permission). Two are especially relevant to agent requests: exp is iat + 300s (five minutes), and jti is a unique identifier a resource server can remember in order to reject a replay.
cnf.jkt contains the DPoP key binding: the thumbprint of the key the caller must prove it holds. See proof-of-possession for the verification flow.
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 delegates work to another, or one call fans out into several, a derived token remains a subset of the token from which it was created. It cannot become a superset. Auth51 calls this property non-amplification and enforces it when the token is minted.
▶How the token proves the path wasn’t tampered with
Two claims make the execution path independently verifiable. 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, carried as delegation_chain. Completed workflow steps are hashed the same way into step_sequence_hash.
The Authority rejects a request when its chain or step sequence does not match the workflow. Including the hashes in the token allows a resource server to detect a skipped step or an altered delegation chain without calling back to the Authority. draft-goswami-agentic-jwt §4.4.4