MCP Security and Governance

MCP gives AI applications a standard way to reach your data and actions. That makes it useful, and it also means a weak server can be reached by every assistant that connects to it. This resource summarises the security best practices in the MCP specification (2026-07-28) and adds the enterprise governance that sits around them. It is guidance, not a compliance guarantee: check regulatory points with your legal adviser.

Start with the authorisation model

Authorisation is optional in MCP, which is fine for public, read-only content like the GeekMidst MCP server. Any server that touches non-public data should follow the spec's authorisation rules:

• The server is an OAuth 2.1 resource server and must publish RFC 9728 protected resource metadata naming at least one authorisation server.
• On 401 it sends a WWW-Authenticate header pointing to that metadata.
• Tokens arrive as Authorization: Bearer on every request, never in the query string.
• The server must check the token was issued for it (audience, RFC 8707). Invalid or expired tokens get 401; insufficient scope gets 403 with insufficient_scope.
• Clients use PKCE and send the resource parameter. Client ID Metadata Documents are the recommended registration route; Dynamic Client Registration is deprecated in 2026-07-28.

The MCP security and authorisation architecture shows these flows as a diagram.

The spec's named risks

Confused deputy

A proxy-style MCP server that talks to a third-party authorisation server on behalf of many clients can be tricked into granting one client access approved for another. The spec requires such proxies to obtain per-client consent before forwarding to the third-party authorisation server and to validate redirect_uri exactly.

Token passthrough

Forwarding the token a client sent straight to an upstream API is explicitly forbidden: "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server." Passthrough bypasses audience checks, rate limits and audit at the server. Use a separate credential or token for the upstream API, held server side.

Server-side request forgery (SSRF)

Any time a server or client fetches a URL it was given, such as a metadata URL during discovery or a link inside tool arguments, it can be pointed at internal addresses. Allowlist destinations, block private and link-local ranges, and do not follow redirects blindly. The spec's SSRF section has the detailed guidance.

State handle hijacking

This replaces the older session hijacking section. Servers that implement authorisation must verify every inbound request and must not use sessions or state handles for authentication. Identifiers must be secure and non-deterministic, and should be bound to the user (for example <user_id>:<session_id>).

Local MCP server compromise

Local servers run with the user's own rights, so a malicious or careless install can read files or run commands. Review what a local server can do before installing it, prefer reviewed packages, bind local HTTP servers to 127.0.0.1 and authenticate their connections, as the transport rules advise.

Scope minimisation

Request the smallest scopes for the task and add more only when a tool needs them. Broad tokens turn a small mistake into a large incident. The spec also covers authorisation URL validation, mix-up attacks, localhost redirect URI impersonation and Client ID Metadata Document trust policies; read those sections if you run an authorisation server.

Prompt injection through tool outputs

Tool results and resources are data that the model reads. A document, email or record can contain text written to steer the model ("ignore your instructions and…"). Controls:

• Treat every tool output as untrusted content, and say so in the host's instructions.
• Keep write tools behind human confirmation that shows the exact arguments.
• Split read and write capabilities across servers, so a poisoned read cannot quietly trigger a write.
• Treat tool annotations as hints: the spec says clients must treat them as untrusted unless the server is trusted.

Braze, for example, advises against client "auto-mode" for its server, and Slackbot requires per-call user approval for third-party tools.

Sources

• https://modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices
• https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
• https://modelcontextprotocol.io/docs/2025-11-25/tutorials/security/security_best_practices
• https://modelcontextprotocol.io/specification/2026-07-28/server/tools
• https://developer.salesforce.com/blogs/2026/04/salesforce-hosted-mcp-servers-are-now-generally-available
• https://www.braze.com/docs/developer_guide/mcp_server/setup/