MCP Server Security Checklist for the 2026-07-28 Specification

As of October 2026 the current MCP specification revision is 2026-07-28, and its security best practices page names attacks including confused deputy, token passthrough, server-side request forgery (SSRF), local server compromise, state handle hijacking and over-broad scopes. The controls are concrete: per-client consent, audience-checked tokens, blocked private IP ranges, sandboxed local servers, and a progressive least-privilege scope model. This article turns them into a checklist. It covers the protocol's guidance, not every vulnerability in every server.

MCP does not enforce safety in the protocol, and it says so. The overview of the specification sets out three principles: user consent and control, data privacy, and tool safety. It states that hosts must obtain explicit user consent before invoking any tool, and that descriptions of tool behaviour, such as annotations, should be considered untrusted unless obtained from a trusted server. It also says that MCP itself cannot enforce these principles at the protocol level, so implementors should build consent flows, access controls and clear documentation.

Read that as a division of labour. The protocol gives you the plumbing; the host application and the server operator own the controls. If you run an agent that connects to third-party servers, you are the host.

The security best practices page is written for developers implementing authorization flows, server operators and security reviewers. These are the attacks it describes, with the control it prescribes.

Confused deputy and token passthrough

These two are about who a token is for. In the confused deputy case, the spec describes an MCP proxy that fronts a third-party API with a fixed client ID. If the third party has already set a consent cookie in the user's browser, an attacker who registers a malicious client can send the user a crafted link, skip the consent screen and receive an authorization code at their own address. The required mitigation is that the proxy keeps its own per-client consent, shows the requesting client's name, the scopes and the redirect URI, and validates redirect_uri by exact string match.

Token passthrough is simpler. The spec says MCP servers must not accept any tokens that were not explicitly issued for the MCP server. Accepting a token meant for another service breaks the audience boundary, lets callers bypass rate limits and monitoring on the downstream API, and muddies your audit trail, because logs show the wrong caller.

SSRF through discovery

During OAuth discovery, a client fetches URLs supplied by the server. A hostile server can point those at internal addresses, including cloud metadata endpoints such as 169.254.169.254, which the spec names as a risk for credential exposure. The guidance is to require HTTPS in production, block private, loopback and link-local ranges, validate every redirect hop and, for server-side deployments, route requests through an egress proxy. It also warns against hand-written IP validation, because encoding tricks defeat custom parsers, and notes that DNS rebinding can make a check pass and the request fail.

Local servers

A local MCP server is a program you download and run. The spec lists arbitrary code execution, no visibility into the executed command, and data loss as risks. For clients that offer one-click setup, it requires showing the exact command without truncation, flagging it as potentially dangerous, and requiring explicit approval. It recommends running servers in a sandbox with restricted file system and network access, and using the stdio transport or restricted local sockets so other processes on the machine cannot reach the server.

Use this sequence on any server you operate or plan to connect. It takes an hour for a small server.

The scope minimization section is the one teams most often skip, and the spec is direct about the cost. A token carrying broad scopes such as files:* or admin:* turns any log leak into lateral access. The recommended pattern is a minimal initial scope covering low-risk discovery and read operations, with targeted WWW-Authenticate challenges to elevate when a privileged operation is first attempted. The listed mistakes include publishing every scope in scopes_supported, using omnibus scopes like all or full-access, and bundling unrelated privileges to avoid future prompts.

Tool poisoning, where hostile instructions hide in a tool description or a tool result, is a model-level problem that the spec handles by telling hosts to treat descriptions as untrusted. Defence in depth still falls to you: approvals for risky calls, output filtering, and least-privilege credentials. Prompt Injection, Explained covers the attack side, and AI agent identity covers giving each agent its own narrow credentials.

Security researchers and vendors have published further MCP vulnerability findings in 2026. We did not verify the specific CVEs or counts reported in secondary write-ups for this article, so check the CVE records and the relevant vendor advisories directly before citing them.

Run the audit above on your most-used server, and write the findings down. Then fold the approval question into your agent design, because the controls that matter most are the ones that put a human in front of risky calls. If you are new to the protocol, start with What is MCP?.

What is the current MCP specification version? As of October 2026 the specification site publishes revision 2026-07-28 as the latest. Check the MCP specification for newer revisions.

What is the confused deputy problem in MCP? It is an attack on MCP proxy servers that use a static client ID with a third-party authorization server. A consent cookie from an earlier approval lets an attacker skip the consent screen and capture an authorization code. The fix is per-client consent held by the proxy.

What is token passthrough and why is it forbidden? It is when an MCP server accepts a token not issued for it and forwards it to a downstream API. The spec forbids it because it bypasses security controls, breaks audit trails and creates trust boundary problems.

How should I secure a local MCP server? Show the full command before the first run, require explicit approval, run the server in a sandbox with minimal privileges, and prefer the stdio transport or restricted sockets so other local processes cannot connect.

Does the protocol stop tool poisoning? No. The spec says tool descriptions should be treated as untrusted unless they come from a trusted server, and that MCP cannot enforce safety at the protocol level. Approvals, filtering and least-privilege credentials are your controls.

How many scopes should an MCP server request? As few as possible. The spec recommends a minimal initial set and incremental elevation when a privileged operation is first attempted.