Model Context Protocol (MCP) Security · Schema, Message, and Input Validation
Bind consent to the approved MCP endpoint
Verify that MCP clients bind each approved MCP server's granted consent and authorization to the connection endpoint approved for that server, and require user re-approval before any further interaction once that endpoint changes.
OWASP AISVS v1.01, requirement 10.4.10
In plain English
When a user approves an MCP server, the approval belongs to the address they approved. If the server's address changes, the client must stop and ask again before doing anything else. Otherwise an attacker who can change a configuration entry or a redirect inherits the trust.
What good looks like
- Consent and authorisation are stored together with the approved endpoint.
- The client compares the endpoint before every connection.
- If it has changed, no requests are sent and no tokens are presented until the user approves again.
- Redirects to a different origin count as a change.
How teams usually do it
- Store the endpoint URL with the grant and compare origin and path on connect.
- Do not follow cross-origin redirects automatically for MCP endpoints.
- Key stored tokens by endpoint, so a token for one address is never sent to another.
Suggested evidence
- Tests in which the endpoint changes, showing the re-approval prompt and no traffic before it.
- Client storage design.
Common mistakes
- Following a redirect to a new endpoint under the old approval.
- Keying approval by the server's display name, which the server chooses.
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.