The MCP spec's own security MUSTs, read by a buyer: five requirements to make any MCP vendor prove
A buyer reviewing an MCP server, client or gateway does not need to invent security requirements. The Model Context Protocol specification already states them in MUST and MUST NOT language. Five of those obligations translate directly into evidence a vendor can be asked to produce: servers must not accept tokens issued for anyone else; proxy servers must obtain per-client consent; servers must verify every request and validate tool inputs; clients must show the exact command before launching a one-click local server; and clients must reject dangerous authorization URLs. Asking for proof of each, in the specification's own words, produces answers that can be tested, which a generic questionnaire rarely does.
Status of the text being relied on
The security guidance cited here is the "latest" specification, which references protocol revision 2026-07-28 (MCP Security Best Practices; MCP Tools). The Security Best Practices page describes itself as complementing the MCP Authorization specification and as addressed to implementers, server operators and "security professionals evaluating MCP-based systems." Two drafting cautions follow.
First, the page mixes normative statements (MUST, SHOULD) with explanatory material. A contract or review should quote the normative sentence, not the narrative around it. Second, the specification changes. Revision 2026-07-28 describes MCP as stateless and replaces the earlier session-hijacking guidance with guidance on state handles; the page points readers of version 2025-11-25 and earlier to the older text. Record the revision a vendor claims to implement.
This is general information about a technical specification, not legal advice; contract language should be reviewed by counsel.
Who each obligation binds
The applicability funnel matters, because a server vendor cannot prove a client obligation and vice versa.
Obligation Binds Ask
------------------------------------------ ---------------------------- ---------------------------
1. No token passthrough MCP servers Server vendors
2. Per-client consent in OAuth proxies MCP proxy servers Server vendors (proxy type)
3. Verified requests, validated tool input MCP servers Server vendors
4. Exact-command consent for local servers Clients with one-click setup Client and gateway vendors
5. Safe authorization URL handling MCP clients Client and gateway vendorsRequirement 1: no token passthrough
The text. "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server." The page explains the failure: a server that does not check the token's audience may accept tokens issued for other services, and if it forwards them downstream, it creates a confused-deputy problem and breaks the audit trail.
Evidence to request. A description of how the server validates the token audience, for example against the audience claim the page cites from RFC 9068; and a test result in which a validly signed token issued for a different resource is presented and rejected.
Red flag. "We pass the user's token through to the upstream API." That is the anti-pattern the specification names and forbids.
Requirement 2: per-client consent in OAuth proxies
The text. Where an MCP server acts as a proxy to a third-party API using a static client ID, it "MUST implement per-client consent." The consent page "MUST" identify the requesting client by name, display the third-party scopes requested, show the registered redirect_uri, implement CSRF protection and prevent framing. The proxy "MUST" validate that the redirect_uri exactly matches the registered one, using exact string matching, and "MUST" follow the stated rules for the OAuth state parameter, including setting it only after consent is approved.
Evidence to request. Screenshots of the consent page showing the four required elements; the redirect URI validation logic or a test showing a changed redirect_uri is rejected; the state lifecycle, including expiry.
Red flag. "Users only consent once to the upstream provider." The specification's attack description rests on exactly that consent cookie being reused for a new, attacker-registered client.
Requirement 3: verified requests and validated tool input
The text. On tools, servers "MUST" validate all tool inputs, implement proper access controls, rate limit tool invocations and sanitize tool outputs. On state, MCP servers that implement authorization "MUST verify all inbound requests" and "MUST NOT treat possession of a state handle as authentication." The page adds that handles SHOULD be generated with secure randomness and SHOULD be bound server-side to the authenticated user.
Evidence to request. The authorization check applied on every tool call; how state handles are generated and bound to the caller; rate-limit settings per tool; and a test in which one user's handle is presented with another user's token and rejected.
Red flag. "The handle is a long random string, so it's secure." Possession of a handle is precisely what the MUST NOT excludes as authentication.
Requirement 4: exact-command consent for local servers
The text. "If an MCP client supports one-click local MCP server configuration, it MUST implement proper consent mechanisms prior to executing commands." The client "MUST" show "the exact command that will be executed, without truncation (include arguments and parameters)," identify it as potentially dangerous, require explicit approval and allow cancellation. The client SHOULD highlight dangerous patterns, warn about sensitive locations, and run servers sandboxed "with minimal default privileges."
Evidence to request. A screen recording of the one-click flow using a long command with arguments, showing it untruncated; the sandboxing model, if any, stated as file-system and network scope.
Red flag. A consent dialog that shows a server name or a shortened command. The obligation is the exact command.
Requirement 5: safe authorization URL handling
The text. MCP clients "MUST" validate authorization URLs, "MUST only allow http:// and https:// schemes" (with http:// acceptable only for loopback during development), "MUST reject javascript:, data:, file:, vbscript:" and similar schemes, and "MUST NOT use shell commands" to open URLs. Separately, MCP clients deployed to a server "MUST consider SSRF risks" when fetching OAuth metadata URLs, and SHOULD require HTTPS, block private and link-local ranges including 169.254.0.0/16, validate redirect targets and consider an egress proxy.
Evidence to request. Test results for a malicious server that returns a javascript: authorization URL, and, for server-side clients and gateways, one that points resource_metadata at a cloud metadata address. Both should fail safely and be logged.
Red flag. "We validate IPs with a regular expression." The page warns against implementing IP validation manually because encoding tricks defeat custom parsers.
Should-level items worth asking about anyway
Scope minimisation is guidance, not a MUST, and a review should label it accordingly. The page lists common mistakes: publishing every scope in scopes_supported, using wildcard scopes such as * or full-access, and returning the entire catalogue in every challenge. Asking a vendor which of these it does is fair. Failing a vendor on a SHOULD as if it were a MUST is not.
The evidence request, ready to paste
MCP SPECIFICATION EVIDENCE REQUEST (revision claimed: ________)
Server vendors
[1] Token audience: describe validation; attach test where a token issued
for another resource is rejected. (MUST NOT)
[2] OAuth proxy only: consent page screenshots (client name, scopes,
redirect_uri, CSRF); redirect_uri exact-match test; state lifecycle. (MUST)
[3] Per-call authorization; tool input validation; rate limits; state
handle binding test across two users. (MUST / MUST NOT)
Client and gateway vendors
[4] One-click local server: recording showing full untruncated command,
danger notice, approve and cancel; sandbox scope. (MUST; sandbox SHOULD)
[5] Authorization URL: rejection of javascript:/data:/file: schemes; no shell
URL opening; SSRF test against link-local metadata address. (MUST; SSRF SHOULD)
For each: owner, date of last test, and how a regression would be detected.Ambiguities a buyer should expect
The specification does not define a certification, so "MCP compliant" is a vendor claim, not an attestation. Implementation varies by client, and some obligations apply only to particular architectures, such as proxies or server-deployed clients. A vendor that answers "not applicable" should say which architectural condition it relies on, and that condition belongs in the contract.
Server identity is the one thing this request cannot settle: whether the package or endpoint you install is the one the vendor answered for. The threat.cafe board records MCP servers that turned out to be impersonations or turned malicious after adoption.