The MCP Agent Gateway now speaks DPoP (RFC 9449, sender-constrained tokens). A stolen token stops being a working token. One environment variable turns it on, and the naive MCP behind the gateway still never learns any of it happened.
Every token in an MCP chain is normally a bearer token: whoever holds it can use it. Short lifetimes and instant revocation shrink the window, but inside that window a copied token works from anywhere. DPoP closes the window entirely. The token is bound at issuance to a private key, and every use of it must carry a short-lived proof signed by that key. Copy the token without the key and it is inert.
It is one setting, TOKEN_BINDING_MODE, and it is off by default so the drop-in promise
holds:
Two modes, opt in as far as you want
outbound binds every token the gateway receives from the identity provider to the
gateway's own key (invisible to your callers, zero client changes). full goes further:
the gateway becomes a DPoP resource server and requires every caller to sign a proof on every request.
none is the default and behaves exactly like before.
Per-call token exchange and rich authorization. Every action is checked by policy before it runs.
Continuous evaluation. Abuse or a suspicious verdict kills the session tenant-wide, live.
The token is cryptographically tied to a key. Possession, not just presentation, is required.
● newValidated end-to-end against a real IBM Verify tenant with a real user login:
token_type: DPoP with cnf.jkt equal to the signing key.
401 missing_dpop_proof.
Almost always. It hardens the credentials the gateway issues with no work for your callers and no change to the tool contract. If you want binding with zero friction, this is the switch.
When callers can sign proofs and the user token is high-value, longer-lived, or crosses networks you do not fully trust. This is the mode that makes a stolen session token worthless.
When you need pure drop-in for arbitrary clients that cannot sign proofs yet. Stay on outbound, and move to full when your client fleet is ready. Nothing is lost by staging it.
| Typical MCP gateways today | This gateway (DPoP on) | |
|---|---|---|
| Token model | Plain bearer. Holder is treated as the user. | Sender-constrained. Holder must prove key possession. |
| A stolen access token | Works from anywhere until it expires. | Rejected. No key, no proof, no call. |
| A leaked downstream credential | Usable for its full lifetime. | Bound to the gateway key via cnf.jkt. |
| A replayed request | Accepted. | Caught by the proof replay cache. |
| Standard behind it | Bearer handling (RFC 6750) or proprietary. | RFC 9449 DPoP, an open standard. |
| Cost to your clients | None, because nothing is bound. | None in outbound; proof signing only in full. |
| Defense posture | Perimeter, sometimes revocation. | Perimeter, revocation, and binding. |
Most MCP gateways on the market move plain bearer tokens: the managed gateway services from the large cloud and identity vendors, the connector platforms that funnel a thousand-plus integrations through one policy boundary, and the API gateways rebadged for MCP. Short-lived, in many cases. Sender-constrained, in almost none. That is the gap this closes.