security

38 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Server isolation principle: no whole-conversation access

An MCP design principle states servers should not be able to read the whole conversation nor see into other servers: servers receive only necessary contextual information, full conversation history stays with the host, each server maintains isolation, cross-server interactions are controlled by the host, and the host process enforces security boundaries.

Issuer validation of authorization server metadata

After retrieving an authorization server metadata document, MCP clients MUST validate it per RFC8414 Section 3.3 or OpenID Connect Discovery Section 4.3: the `issuer` value in the document MUST be identical to the issuer identifier used to construct the well-known URL. If they differ, the client MUST NOT use the metadata. For example, a document fetched from `https://attacker.example/.well-known/oauth-authorization-server` containing `"issuer": "https://honest.example"` MUST be rejected.

Confused deputy: consent required per dynamically registered client

MCP proxy servers that use static client IDs MUST obtain user consent for each dynamically registered client before forwarding to third-party authorization servers, to prevent confused deputy attacks where stolen authorization codes yield access tokens without user consent.

Mix-up attack mitigation via authorization response validation

An attacker controlling one authorization server an MCP client uses may try to make the client send it a code or token issued by a different honest authorization server (mix-up attack, RFC 9207 Section 1). The required mitigation is specified in the Authorization Response Validation section of the MCP authorization specification.

Token passthrough to upstream APIs is forbidden

If an MCP server makes requests to upstream APIs it may act as an OAuth client to them, but the token used upstream must be a separate token issued by the upstream authorization server. The MCP server MUST NOT pass through the token it received from the MCP client.

Secure token storage and refresh token rotation requirements

MCP clients and servers MUST implement secure token storage and follow OAuth 2.1 Section 7.1 best practices to mitigate token theft. Authorization servers SHOULD issue short-lived access tokens, and for public clients authorization servers MUST rotate refresh tokens as described in OAuth 2.1 Section 4.3.1.

HTTPS required for authorization endpoints and redirect URIs

Implementations MUST follow OAuth 2.1 Section 1.5 Communication Security. Specifically: (1) all authorization server endpoints MUST be served over HTTPS; (2) all redirect URIs MUST be either `localhost` or use HTTPS.

Icon security requirements

Consumers of icon metadata MUST take security precautions: treat icon metadata and bytes as untrusted; ensure the icon URI is an HTTPS or `data:` URI and MUST reject unsafe schemes and redirects such as `javascript:`, `file:`, `ftp:`, `ws:`, or local app URI schemes; disallow scheme changes and cross-origin redirects; be resilient to resource exhaustion from oversized images, large dimensions, or excessive frames (consumers MAY set size limits); fetch icons without credentials (no cookies, Authorization headers, or client credentials); verify icon URIs come from the same origin as the server; be cautious rendering payloads that MAY contain executable content such as SVG with embedded JavaScript (consumers MAY disallow file types or sanitize); and validate MIME types and file contents before rendering, treating declared MIME type as advisory, detecting content type via magic bytes, rejecting mismatches or unknown types, and maintaining a strict allowlist of image types.

Bound composition keywords to prevent schema DoS

Composition keywords (`anyOf`, `oneOf`, `allOf`, `if`/`then`/`else`) and `$defs` can be expensive to validate, so implementations SHOULD apply reasonable bounds such as a maximum schema depth, a cap on the total number of subschemas, or a per-validation time budget, to prevent a malicious schema acting as a denial-of-service vector against the validator.

clientInfo and serverInfo are unverified and must not drive behaviour

`io.modelcontextprotocol/clientInfo` and `io.modelcontextprotocol/serverInfo` are self-reported by the sender and are not verified by the protocol. They are intended for display, logging, and debugging; implementations SHOULD NOT use them to change client or server behaviour and SHOULD NOT rely on them for security decisions.

$ref network dereferencing is forbidden by default

JSON Schema 2020-12 permits `$ref` to point at an absolute URI, but MCP implementations MUST NOT automatically dereference `$ref` values that resolve to a network URI. Implementations MAY offer an opt-in mode that fetches non-local `$ref`s, but it MUST be disabled by default and SHOULD enforce a host allowlist or at minimum reject loopback, link-local and private network addresses, apply timeouts and size limits, and log dereferenced URIs. Schemas that fail to validate due to an unresolved external `$ref` SHOULD be rejected rather than silently treated as permissive.

Replay protection contents for requestState

To prevent replay, servers SHOULD include inside the integrity-protected `requestState` payload and verify on receipt: the authenticated principal (rejecting state presented by a different principal), a short expiry/TTL (rejecting lapsed state), and an identifier for the originating request such as the method name and a digest of its salient parameters (rejecting state presented on a non-matching request). These measures bound the replay window and prevent cross-user and cross-request reuse but do not guarantee single use; servers requiring a `requestState` to be consumed at most once (e.g. one-time redemptions) MUST enforce that invariant server-side.

requestState is attacker-controlled: integrity protection MUST

If a client request contains a `requestState` field, servers MUST treat it as attacker-controlled input. If `requestState` influences authorization, resource access, or business logic, servers MUST protect its integrity (e.g. HMAC or AEAD) and MUST reject state that fails verification. Integrity protection MAY be omitted only when tampering can cause nothing worse than request failure.

Elicitation state storage MUST be user-bound and protected

Elicitations do not require the server to maintain state thanks to the multi round-trip requests (MRTR) mechanism, but if state is stored, servers MUST securely associate it with individual users: state storage MUST be protected against unauthorized access, and for remote MCP servers user identification MUST be derived from credentials acquired via MCP authorization when possible (e.g. the `sub` claim).

Servers MUST NOT trust client-provided user identification

Servers MUST NOT rely on client-provided user identification without server verification because it can be forged; instead servers SHOULD follow security best practices. Non-normative: treating user input like 'I am joe@example.com' as authoritative is incorrect; relying on MCP authorization to identify the user is correct.

Form mode MUST NOT be used for sensitive information

Servers MUST NOT use form mode elicitation to request sensitive information such as passwords, API keys, access tokens, or payment credentials, and MUST use URL mode for interactions involving such information. 'Sensitive information' means secrets and credentials granting access or authorizing transactions; general contact/profile data (name, email, username) is not categorically prohibited.

Client MUST requirements for elicitation UI

MCP clients MUST provide UI that makes clear which server is requesting information, MUST respect user privacy and provide clear decline and cancel options, MUST for form mode allow users to review and modify their responses before sending, and MUST for URL mode clearly display the target domain/host and gather user consent before navigating to the target URL.

Elicitation security requirements list (MUST vs SHOULD)

Security requirements for elicitation: servers MUST bind elicitation requests to the client and user identity; clients MUST provide clear indication of which server is requesting information; clients SHOULD implement user approval controls; clients SHOULD allow users to decline elicitation requests at any time; clients SHOULD present requests in a way that makes clear what information is requested and why. Additionally, clients SHOULD validate all responses against the provided schema and servers SHOULD validate received data matches the requested schema.

Safe URL handling: server MUST NOT / SHOULD rules

Servers requesting elicitation MUST NOT include sensitive information about the end-user (credentials, PII) in the URL of a URL mode elicitation request; MUST NOT provide a URL pre-authenticated to access a protected resource (it could be used to impersonate the user by a malicious client); SHOULD NOT include clickable URLs in any field of a form mode elicitation request; and SHOULD use HTTPS URLs outside development environments.

Safe URL handling: client MUST NOT / MUST / SHOULD rules

Clients implementing URL mode elicitation MUST NOT automatically pre-fetch the URL or any of its metadata; MUST NOT open the URL without explicit user consent; MUST show the full URL to the user for examination before consent; MUST open the URL in a secure manner that does not enable the client or LLM to inspect the content or user inputs (e.g. iOS SFSafariViewController is acceptable, WKWebView is not); SHOULD highlight the URL domain to mitigate subdomain spoofing; SHOULD warn about ambiguous/suspicious URIs such as those containing Punycode; and SHOULD NOT render URLs as clickable in any elicitation field except the `url` field of a URL elicitation request.

Phishing mitigation: server MUST verify the user who opens the elicitation URL

URL mode elicitation returns a URL an attacker could forward to a victim. The MCP server MUST verify the identity of the user who opens the URL before accepting information, ensuring the user who started the elicitation is the same user who completes the authorization flow (e.g. compare the authoritative `sub` claim from the MCP authorization server to the subject in the browser session cookie). The server MUST ensure the identity mechanism is resilient to attacks where an attacker modifies the elicitation URL. Without this, a malicious user can have a victim complete a flow whose tokens get bound to the attacker's identity, causing account takeover.

Roots SHOULDs for servers and clients

Servers SHOULD handle cases where roots become unavailable, respect root boundaries during operations, validate all paths against provided roots, check for the roots capability before usage, and cache root information appropriately. Clients SHOULD prompt users for consent before exposing roots, provide clear root-management interfaces, validate root accessibility before exposing, and monitor for root changes.

Roots are informational, not access control

Roots inform servers about directories and files the client considers relevant so servers can focus operations; they are informational guidance rather than an access-control mechanism, and the protocol does not enforce that servers stay within roots.

Roots security MUSTs for clients

Clients MUST only expose roots with appropriate permissions, validate all root URIs to prevent path traversal, implement proper access controls, and monitor root accessibility.

Human in the loop for sampling requests

For trust & safety and security there SHOULD always be a human in the loop with the ability to deny sampling requests. Applications SHOULD provide UI that makes it easy and intuitive to review sampling requests, allow users to view and edit prompts before sending, and present generated responses for review before delivery. The protocol itself does not mandate any specific user interaction model.

Sampling security requirements (SHOULD/MUST list)

Sampling security considerations: clients SHOULD implement user approval controls; both parties SHOULD validate message content; clients SHOULD respect model preference hints; clients SHOULD implement rate limiting; both parties MUST handle sensitive data appropriately. With tools: servers MUST ensure that when replying to a stopReason of "toolUse", each ToolUseContent item is answered by a ToolResultContent item with a matching toolUseId and that the user message contains only tool results; both parties SHOULD implement iteration limits for tool loops.

MCP cannot enforce security at the protocol level; implementor SHOULDs

The specification notes that MCP itself cannot enforce its security principles at the protocol level. Implementors SHOULD: build robust consent and authorization flows into their applications; provide clear documentation of security implications; implement appropriate access controls and data protections; follow security best practices in their integrations; and consider privacy implications in their feature designs.

Security principles: user consent, data privacy, tool safety

MCP security key principles state: (1) User Consent and Control — users must explicitly consent to and understand all data access and operations, and must retain control over what data is shared and what actions are taken; (2) Data Privacy — hosts must obtain explicit user consent before exposing user data to servers, and must not transmit resource data elsewhere without user consent; (3) Tool Safety — tools represent arbitrary code execution and must be treated with caution, descriptions of tool behavior such as annotations should be considered untrusted unless obtained from a trusted server, and hosts must obtain explicit user consent before invoking any tool.

Prompts implementation and security requirements

Servers SHOULD validate prompt arguments before processing; clients SHOULD handle pagination for large prompt lists; both parties SHOULD respect capability negotiation. Implementations MUST carefully validate all prompt inputs and outputs to prevent injection attacks or unauthorized access to resources.

Resource security requirements (MUST/SHOULD list)

Resource security requirements: (1) servers MUST validate all resource URIs; (2) access controls SHOULD be implemented for sensitive resources; (3) binary data MUST be properly encoded; (4) resource permissions SHOULD be checked before operations; (5) servers MUST sanitize file paths to prevent directory traversal attacks when serving file:// resources.

Tool annotations are untrusted

For trust & safety and security, clients MUST consider tool annotations to be untrusted unless they come from trusted servers.

Tool security MUST list for servers

Servers MUST validate all tool inputs, implement proper access controls, rate limit tool invocations, and sanitize tool outputs. Clients SHOULD prompt for user confirmation on sensitive operations, show tool inputs to the user before calling the server, validate tool results before passing to the LLM, follow the `$ref` resolution requirements when validating against inputSchema/outputSchema, implement timeouts for tool calls, and log tool usage for audit purposes.

Human in the loop for tool invocation

Tools in MCP are model-controlled: the language model can discover and invoke them automatically. For trust & safety there SHOULD always be a human in the loop able to deny tool invocations, and applications SHOULD provide UI showing which tools are exposed to the model, insert clear visual indicators when tools are invoked, and present confirmation prompts. The protocol does not mandate any specific user interaction model.

Choosing cacheScope public or private

`"public"` is appropriate for lists of tools, prompts, and resource templates when they are identical for all users. `"private"` is appropriate for `resources/read` results that depend on the authenticated user, or for filtered list results that vary per user.

Security: public cacheScope can leak across authorization contexts

Servers MUST be aware that responses marked `cacheScope: "public"` may be shared between callers even when returned from an authenticated endpoint; e.g. an authenticated `tools/list` result with public scope may be cached and reused across different access tokens. Server implementors should ensure `cacheScope` correctly reflects intended visibility, MUST apply appropriate per-primitive access controls, and MUST NOT rely on `cacheScope` alone to prevent unauthorized access to primitives.

Completion MUST-level security requirements

Completion implementations MUST validate all completion inputs, implement appropriate rate limiting, control access to sensitive suggestions, and prevent completion-based information disclosure.

Logging security MUST NOT rules

Log messages MUST NOT contain credentials or secrets, personal identifying information, or internal system details that could aid attacks. Implementations SHOULD rate limit messages, validate all data fields, control log access, and monitor for sensitive content.

serverInfo is unverified — clients SHOULD NOT rely on it

`serverInfo` returned from discovery is self-reported by the server and is not verified by the protocol. It is intended for display, logging, and debugging. Clients **SHOULD NOT** use it to change their behavior, and **SHOULD NOT** rely on it for security decisions.

Give your agent this brain