What Is DPoP (RFC 9449)? Sender-Constrained Tokens for AI Agents Explained DPoP, the sender-constraining mechanism defined in RFC 9449, binds OAuth 2.0 access tokens to a client-held private key so that a leaked token cannot be used without a matching proof JWT, addressing a risk the RFC's explainer says is acute for AI agents whose tokens pass through prompts, tool outputs, transcripts and telemetry. Each request carries a proof in a DPoP header containing a jti with at least 96 bits of randomness, the htm method, the htu target URL, an iat timestamp and, for API calls, an ath claim holding the base64url SHA-256 hash of the access token; the authorization server ties the token to the key via the cnf.jkt confirmation claim and returns token_type "DPoP". Servers can demand a nonce, replying with HTTP 400 and the use_dpop_nonce error plus a DPoP-Nonce header (401 from a resource server), and Personal Agent Protocol Draft 0.1 binds its short-lived session tokens to a DPoP key while allowing bearer tokens only for MCP servers, which it flags as less secure. What Is DPoP RFC 9449 ? Sender-Constrained Tokens for AI Agents Explained DPoP RFC 9449 ties an OAuth access token to a key so a stolen token fails: proof JWTs, cnf jkt, server nonces, and how PAP, FAPI 2.0 and MCP servers use it. DPoP, short for Demonstrating Proof of Possession, is defined in RFC 9449 https://www.rfc-editor.org/rfc/rfc9449.html . The RFC's abstract calls it "a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level." In plain terms: an access token stops being a password-like string that works for whoever holds it, and becomes a token that only works together with a private key the legitimate client keeps. The problem: bearer tokens A normal OAuth access token is a bearer token. Anyone who gets a copy can use it until it expires. Tokens leak through logs, error reports, URLs, browser extensions and compromised servers. This is a particular concern for AI agents, whose tokens can pass through prompts, tool outputs, transcripts and telemetry. DPoP does not stop a leak. It makes a leaked token far less useful. How it works, step by step 1. The client makes a key pair and keeps the private key. 2. For each request, it signs a short proof a JWT and sends it in a DPoP header. 3. The authorization server binds the token to the key. The token response has token type: "DPoP" , and the access token is tied to the public key through a confirmation claim, cnf.jkt , which is a thumbprint of that key RFC 9449 section 6.1 . 4. The client calls the API with Authorization: DPoP