MCP Security Best Practices in Plain English

The Model Context Protocol documentation includes a page called Security Best Practices. It is written mainly for people who implement authorization flows, run MCP servers, or assess MCP-based systems for security. This guide reads that page for a different reader: someone choosing, installing or approving MCP servers who wants to know which risks are real and which checks matter. We read the 2026-07-28 version of the page on 29 October 2026. It is a summary, not a security audit, and the original page is the authority.

Local servers: the risk closest to you

A local MCP server is one that runs on your own machine. The page says these servers may have direct access to your system and may be reachable by other processes, which makes them attractive targets. It describes three routes for an attacker: a malicious startup command placed in a client configuration, a malicious payload inside the server itself, and an insecure local server left running on localhost and reached through DNS rebinding.

The risks it lists are arbitrary code execution with the client's privileges, no visibility into what commands run, command obfuscation, data exfiltration, and data loss. For clients with one-click local setup, it says they must show the exact command without truncation, identify it as potentially dangerous, and require explicit approval. It also says clients should run servers in a sandbox with minimal default privileges. Servers meant for local use should guard against misuse by other processes: use stdio, which limits access to the client, or restrict access when using HTTP, for example with an authorization token or a restricted unix domain socket or other inter-process communication channel.

Token passthrough

The page calls token passthrough an anti-pattern: an MCP server accepts a token from a client without validating that it was issued to that server, and passes it on to a downstream API. The risks it names include circumventing security controls such as rate limiting, losing the audit trail because the server cannot tell clients apart, and breaking trust boundaries. The rule is blunt: a server must refuse any token that was not issued explicitly for it. For a person approving a server, the relevant question is whether it asks you to sign in to its own service or simply relays someone else's credentials.

Confused deputy and consent

An MCP proxy server connects clients to a third-party API. The page describes how an attacker can exploit such a proxy when it uses a static client ID with the third-party authorization server, lets clients register dynamically, and lacks per-client consent, while the third-party authorization server sets a consent cookie after the first authorization. The fix it requires is a consent step owned by the MCP server, which names the requesting client, shows the scopes requested, and shows the redirect address where tokens will be sent. When a server asks you to connect an account, expect a screen like that. If you never see one, be cautious.

Scopes: ask for less

The page says poor scope design increases the damage from a stolen token and obscures audit trails. It recommends a progressive, least-privilege model with a minimal initial scope for low-risk read operations and step-up requests when privileged actions are first attempted. Its list of common mistakes includes publishing every scope, using wildcard scopes such as all or full-access, and bundling unrelated privileges. A server that wants broad access up front deserves a second look.

State handles and request forgery

Because MCP in this revision has no protocol-level sessions, servers that keep state hand out explicit handles, such as a cart or workflow identifier. The page warns about state handle hijacking, where someone guesses or obtains a handle and uses it to reach another user's state. Servers must not treat possession of a handle as authentication, and should use non-deterministic handles bound to the authenticated user. Separately, the page covers server-side request forgery, where a malicious server points a client at internal addresses during OAuth discovery. It tells clients to require HTTPS, block private and link-local address ranges, and validate redirects. That mostly concerns people building clients, but it explains why a client should not follow a server's URLs blindly.

A checklist before you install a server (our suggestions)

• Is the publisher known and the source public? Our directory profiles record publisher and transport.
• Does it run locally? If so, read the exact command, run it in a sandbox, and limit which folders it can reach.
• Which credentials does it ask for, and with what scopes? Prefer narrow ones.
• Does it show a consent screen naming the client and scopes when connecting an account?
• Which tools can write, delete or send? Read how to read a tool definition and keep a person approving risky calls, as in agent tool permissions.
• Can you log what it did? See agent security risks for the wider picture.

What this is not

The MCP page is addressed to implementers, and most of its musts are duties of clients and servers, not of the person using them. We did not test any server against it. Many projects will meet some of these points and miss others. Accounts and planned features here are not open yet; see what is planned.