API token theft has become one of the most reliable paths to compromise in modern systems. A stolen bearer token — lifted from a logfile, an exposed environment variable, a misconfigured CI pipeline, or a compromised developer laptop — is fully usable by anyone who holds it. The token is the credential. There's nothing binding it to the legitimate client, which is why incidents like the Heroku/Travis CI OAuth breach, the CircleCI compromise, and countless npm-token leaks keep producing the same outcome: attacker exfiltrates a token, attacker becomes the user.

This post argues for adopting Proof of Possession (PoP) as a pragmatic fix. The idea is old in cryptographic circles but underused in everyday API design: instead of presenting a bearer token, the client proves it holds a private key bound to the token. Each request carries a short-lived signature over the request details (method, URL, body hash, timestamp), and the server verifies the signature using a public key registered when the token was issued. Steal the token alone, and you have nothing — the matching private key never leaves the legitimate client.

Why this deserves a technical audience's attention:

• It's standards-track, not theoretical. RFC 9449 (DPoP) and RFC 8705 (mTLS-bound tokens) formalize PoP for OAuth 2.0. Browser-side, the WebAuthn ecosystem already demonstrates the model works at scale.
• It defangs the most common exfiltration paths. Logs, error reports, SSRF, and accidental git commits stop being game-over events. The attacker needs the key material too, which lives in a TPM, secure enclave, or HSM if you've done it right.
• It's incrementally deployable. You don't need to rewrite your auth stack — PoP can layer on top of existing bearer-token flows, with servers accepting both during a migration window.

The honest tradeoffs are real: clients need key management, signature verification adds CPU cost, and clock skew becomes a correctness concern. But these are tractable problems with known solutions, and the industry has been paying the cost of bearer-token theft for over a decade. Anyone designing an API in 2026 — especially one issuing long-lived tokens to agents, CI systems, or LLM-driven clients (where token exfiltration risk is arguably higher than ever) — should at least understand why DPoP exists and when it's worth the complexity.