Implementation guide
OWASP AISVS v1.01
Model Context Protocol (MCP) Security · Secure Transport
Sender-constrained MCP tokens
Verify that access tokens between the MCP client and server are sender-constrained using mTLS or DPoP.
OWASP AISVS v1.01, requirement 10.3.5
In plain English
An ordinary bearer token works for anyone who holds it. Bind access tokens to the client they were issued to, using mutual TLS or DPoP, so a stolen token is useless from anywhere else. This is a Level 3 control.
What good looks like
- Access tokens between MCP client and server are sender-constrained.
- The server checks the binding on every request.
- An unbound token, or one presented with the wrong key, is rejected.
- Client private keys are kept in protected storage.
How teams usually do it
- DPoP (RFC 9449): the client proves possession of a private key on each request, and the token carries that key's thumbprint.
- Certificate-bound tokens over mutual TLS (RFC 8705) for service-to-service connections.
- An authorisation server set to issue only bound tokens for these clients.
Suggested evidence
- Authorisation server and MCP server configuration.
- A test using a valid token from a different client, showing rejection.
Common mistakes
- Issuing bound tokens and never checking the binding.
- Accepting both bound and plain bearer tokens, so an attacker simply uses the weaker path.
- DPoP proofs accepted without checking replay or freshness.
Not sure which requirements apply to your system? Take the assessment, or browse every guide in this chapter.
Requirement text from the OWASP AI Security Verification Standard, licensed under CC BY-SA 4.0. This guidance is shared under the same licence.