A stolen access token should not be a transferable season ticket to your systems. Yet that is the awkward property of a bearer token: possession is enough to present it, subject to the resource server’s other checks. The server may know what the token permits without knowing whether the presenter is the workload that originally received it.
For an AI agent that can read records and trigger actions, this matters. Tokens pass through runtimes, connectors and operational tooling. Preventing leakage remains essential. Designing as though leakage is impossible is a rather optimistic security budget.
Sender-constrained tokens add a second requirement: the presenter must demonstrate control of an associated private key. DPoP and certificate-bound access tokens using mutual TLS provide different ways to do that. Neither mechanism decides whether the agent’s next action is sensible, authorised in its business context or based on malicious instructions. That boundary deserves as much attention as the cryptography.
What the extra proof buys you
OAuth’s current security guidance recommends sender-constrained access tokens to reduce the misuse of stolen credentials. The useful distinction is between someone who copied a token and someone who can also use the key to which it is bound.
Imagine a fictional purchasing assistant, Parcel, that retrieves supplier quotes. Its connector receives an access token for the supplier-record API. A diagnostic mistake exposes that token in a log. An attacker can read the log but cannot access the connector’s signing key. With a correctly enforced sender constraint, that copied token should not be enough to read supplier records from the attacker’s machine.
Now change one assumption. A malicious document persuades Parcel to request every supplier record through its normal connector. The connector holds the legitimate key and can produce valid proofs. Token-theft resistance has not failed. The request arrived through the authorised holder. The problem is excessive authority or misuse of the permitted workflow.
That is why a useful agent identity record must describe more than the credential type. It needs an owner, purpose and boundaries that the resource can enforce. A better lock does not improve the judgement of everyone who owns a key.
DPoP and mTLS protect different layers
DPoP puts a signed proof into an HTTP request. The proof identifies the method and target URI, includes freshness-related information and, when accessing a protected resource, binds to the presented access token through its hash. The resource verifies the proof and the token’s key binding. DPoP is not, by itself, OAuth client authentication or a complete access-control decision.
OAuth mutual TLS supports certificate-bound access tokens. The resource checks that the certificate used on the mutual-TLS connection matches the certificate binding associated with the token. Authenticating a client with mTLS at the token endpoint and binding the resulting access token are related but distinct functions. Do not assume that enabling the first automatically gives you the second everywhere.
The operational choice follows the path of the request. If the platform already manages client certificates and controls the relevant TLS connections, certificate binding may fit naturally. If the application needs a proof that travels at the HTTP layer through its infrastructure, DPoP may fit better. Both require supported clients, issuers and resource enforcement. Neither is a decorative header you can bolt on at the last moment.
A mixed estate complicates the answer. One connector may support the chosen mechanism while another only accepts bearer tokens. Document the exception as a remaining exposure. Calling the whole agent sender-constrained because one API supports it is like declaring the house waterproof because the kitchen has tiles.
Follow the proof through the proxy
In Parcel’s fictional deployment, requests cross an API gateway before reaching the supplier service. For mTLS, the team must identify where the client certificate is actually verified. If TLS terminates at the gateway, the backend needs a trustworthy architecture for receiving the authenticated identity and enforcing the binding. Accepting an arbitrary forwarded certificate header would defeat the point.
DPoP has its own integration questions. The URI and method observed during verification must correspond to the external request as required by the protocol, despite routing and rewriting. A gateway cannot casually verify one target and then use that success to bless a different action downstream. Decide which component owns validation, which context it forwards and how the next component knows that context is authentic.
Also define who owns the key. A key shared across unrelated agents weakens the granularity of the sender constraint and complicates incident response. A key per workload instance offers finer separation but adds rotation and recovery work. There is no universally correct count of keys. The design should make the blast radius explainable to the person who will be paged when one is exposed.
Replay protection is not transaction approval
A fresh proof is useful because an attacker should not be able to replay a captured request indefinitely. Implementations need the protocol’s validation rules and a deployment-specific strategy for freshness, duplicate proofs and any required server nonce. Those checks need consistent behaviour across replicas, not just a successful demo against one process.
But a valid DPoP proof does not sign every business field. Its base request binding does not cover the request body, and the target URI excludes query and fragment components. TLS remains necessary for transport integrity. If the business needs approval of a particular supplier, amount or destination, bind that approval to those details separately and enforce it where the action happens.
Consider Parcel asking to amend a supplier’s payment destination. Even a perfectly valid credential proof does not establish that the finance owner approved the new destination. The resource still needs current authority, appropriate scope and transaction rules. The action boundary is where this becomes a product requirement rather than a security slide.
Test the claim you intend to make
For Parcel, I would write the assurance claim narrowly: a token copied without the associated private key cannot be used against the protected supplier endpoint. Then I would test that claim separately from business-policy enforcement. These are proposed acceptance tests, not results from a deployed system.
First, the isolated copied-token test should fail. Next, a proof made with another key should fail. Reusing a captured proof, changing the method or directing it to a different protected endpoint should exercise the documented rejection behaviour. Run the same cases through the real gateway path and multiple replicas. A test against a convenient internal port can miss the component that changes the meaning of the request.
Finally, ask the legitimate connector to perform an operation outside Parcel’s permitted business scope. Its credential proof can pass while authorisation denies the action. That result is healthy. It demonstrates that the system has not mistaken cryptographic possession for universal permission.
A failed key service also needs a product decision. The safe response for a sensitive write is usually to stop or defer it, not silently fall back to a bearer-only route. The precise availability policy should be agreed before an outage makes the decision on everyone’s behalf.
Sender constraints make stolen tokens less useful. That is a meaningful improvement. Keep the claim that precise, then build the separate controls that decide what the legitimate agent is allowed to do.
