Model Context Protocol (MCP) Security · Schema, Message, and Input Validation
Proxies don't share authorisation between clients
Verify that MCP proxy servers using a shared upstream OAuth client identity do not allow a requesting MCP client to inherit authorization established for a different MCP client.
OWASP AISVS v1.01, requirement 10.4.9
In plain English
Some MCP proxies sit in front of a third-party API and use one shared OAuth client identity for everyone. If the proxy is careless, one client can ride on consent that a different client obtained. This is the confused deputy problem, and the MCP specification calls it out directly.
What good looks like
- The proxy records consent and authorisation for each requesting client.
- Each client must obtain the user's consent itself before the proxy acts for it.
- Upstream tokens are never reused across clients.
- Tests try to use another client's grant and fail.
How teams usually do it
- Per-client consent records held by the proxy, checked before the upstream authorisation flow starts.
- The proxy's own consent screen, shown for each new client and naming it clearly, before any redirect to the third-party authorisation server.
- Exact matching of redirect URIs, and a state value bound to the user's session.
Suggested evidence
- The proxy design.
- Tests where a second client tries to inherit the first one's authorisation.
Common mistakes
- Caching upstream tokens in the proxy and reusing them for any client.
- Relying on the upstream consent cookie, which lets the upstream server skip consent for the second client.
- Accepting dynamically registered clients with any redirect URI.
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.