Wiki · Concept · Last reviewed June 25, 2026

Sender-Constrained Tokens

Sender-constrained tokens are OAuth credentials that can be used only by a client able to prove possession of a bound key or certificate, limiting replay when access tokens leak through logs, connectors, tools, or compromised context.

Category: Concept Updated: June 25, 2026 Tags: AI agents, authorization, OAuth, DPoP, mTLS, token replay

Definition

A sender-constrained token is an OAuth access or refresh token that is useful only when presented with proof from the sender to which the token was bound. It changes the token from "whoever has this string can use it" into "the caller must also prove control of the associated key, certificate, or client credential."

The contrast is a bearer token. RFC 6750 defines bearer-token use for OAuth protected resources and says a party in possession of the token can use it without proving possession of cryptographic key material. That design is simple and widely deployed, but it means token leakage can become token replay.

For AI agents, this matters because connectors, remote tool servers, browser sessions, logs, traces, memory stores, and support artifacts may all touch credentials. Sender constraint does not make a bad agent safe, but it can make a stolen token less portable.

How It Works

The authorization server issues a token with a binding to a sender-controlled proof mechanism. The resource server validates the token and also checks that the request came with the matching proof. If an attacker has only the token string, the request should fail.

RFC 9449 standardizes Demonstrating Proof of Possession, or DPoP. DPoP is an application-layer method: the client signs a proof JWT using a private key and sends that proof with token and resource requests. The proof identifies request details such as method and URI, and replay defense depends on details such as timestamp and unique proof identifiers.

RFC 8705 standardizes OAuth mutual TLS client authentication and certificate-bound access tokens. In the certificate-bound token case, the token or introspection response carries confirmation material that ties it to a client certificate, commonly through the cnf structure and an X.509 certificate thumbprint. The resource server checks the presented client certificate against that binding.

Agent Context

An agent workflow can expose tokens in places ordinary OAuth designs did not expect: prompt logs, tool traces, browser automation state, error reports, retrieval results, connector caches, and human review screenshots. Sender constraint narrows one part of that failure. A copied token should not be enough unless the attacker can also make requests as the bound sender.

The Model Context Protocol shows why this is not a complete answer. The MCP authorization specification requires resource indicators for HTTP authorization flows and forbids token passthrough from client to downstream service. Its security guidance treats token passthrough as an anti-pattern because it breaks audience, accountability, and trust boundaries.

Sender-constrained tokens help with replay. They do not decide whether the agent should make the request. If prompt injection causes the legitimate agent process to sign a harmful DPoP proof or use its own mTLS-bound credential, the token was not stolen; the authorized sender was induced to act. That still requires scopes, approvals, least privilege, tool boundaries, and audit trails.

Governance and Safety

RFC 9700, the OAuth 2.0 Security Best Current Practice, recommends sender-constrained access tokens to reduce replay of captured tokens and also recommends audience restriction so captured tokens cannot be used at the wrong resource server. These are complementary controls: audience says where the token may be used; sender constraint says who may use it.

Governance records should make that distinction visible. An incident review should show the token type, audience, scopes, token lifetime, binding method, key or certificate custody, signer process, downstream resource, approval event, and final action. "The agent had a token" is not enough to reconstruct authority.

For enterprise agents, key custody becomes a governance question. If every tool container, browser session, plugin, and remote connector can sign as the same sender, sender constraint has been weakened into shared ambient authority. If signing keys are isolated by task, tenant, tool, and resource, the blast radius is smaller.

Defense Pattern

Source Discipline

Claims about sender-constrained tokens should identify the mechanism. DPoP, mutual TLS certificate-bound access tokens, audience-restricted tokens, refresh-token rotation, API keys, browser cookies, and service-account credentials are different controls. A security report should say which token leaked, whether the proof key leaked, which resource server accepted the request, and whether the request was replayed or legitimately signed by a compromised workflow.

Spiralist Reading

Spiralism reads sender constraint as a refusal to let possession masquerade as legitimacy. The token is not the whole story. The sender, channel, proof, audience, and purpose matter.

The political lesson is modest but useful: when machines act through institutional credentials, the system should ask not only "is the credential valid?" but "is this the right actor, using the right proof, for the right resource, in the right context?"

Open Questions

Sources

Return to Wiki