Concepts
Proof-of-possession
A bearer token has one flaw baked into the name: whoever bears it, wins. Copy it and you are it. That’s fine for a browser session behind a login screen. It’s a poor fit for an agent whose tokens pass through logs, traces, tool outputs, and other processes on their way to a resource.
auth51 makes its tokens sender-constrained. A token is only good if you can prove you hold the key it was bound to.
The key never leaves the process
When the client starts governing an agent, it generates an ephemeral keypair in memory. The public half’s thumbprint goes to the authority when a token is minted; the authority stamps it into the token as cnf.jkt — the confirmation claim from DPoP (RFC 9449). The private half stays in the process and is never sent anywhere.
To use the token against a resource, the caller signs a small proof with that private key. The resource server checks two things: the token is valid, and the proof matches the cnf.jkt inside it. A token without a matching proof is refused.
cnf.jkt. To call a resource, the agent signs a proof with the private key; the resource server accepts only when the proof key matches the thumbprint in the token.▶What’s actually in the DPoP proof
The proof is itself a small JWT — a DPoP proof — that the agent creates fresh for each request and signs with the private key. It carries the HTTP method and URI it is good for (htm / htu), a timestamp (iat), and a unique id (jti) so a captured proof can’t be replayed. Its header includes the full public key (jwk).
The resource server hashes that public key, confirms the thumbprint equals thecnf.jkt inside the intent token, then verifies the proof’s signature and that htm/htu match the request it actually received. Token and proof are cryptographically joined — you can’t present one without the other. RFC 9449
Why MCP tokens are different on purpose
There’s one deliberate exception. When an agent calls a tool through an MCP server, the intent token it hands over is a delegation subject — the MCP server receives it and acts on the agent’s behalf. Binding that token to the agent’s key would be wrong: the agent isn’t the one making the downstream call, the server is. So the Hop-A token carries no cnf. Proof-of-possession moves to the Hop-B token the server mints downstream, bound to the server’s own key. See MCP governance for how that chain works.
▶Why moving the binding doesn’t weaken anything
It would be easy to read “the Hop-A token has no cnf” as a hole. It isn’t. The Hop-A token never travels to the final resource — it stops at the MCP server, which validates it and then mints its own Hop-B token for the real call. That Hop-B token is DPoP-bound, to the MCP server’s key.
So every token that actually reaches a resource is sender-constrained to whoever is making that specific call. The binding follows the party doing the work, hop by hop, rather than being faked onto a party that isn’t. Non-amplification keeps each hop’s authority a subset of the last. draft-goswami-agentic-jwt §4