MCP Security: A Complete Guide to Securing the Model Context Protocol

Install an MCP server and you accept three things at once. You run someone's code, you give it credentials, and you let its output shape what your model does next. Most teams review the first, glance at the second and never think about the third.

Treat this as the anchor page of our MCP coverage. It begins with the protocol revision dated 2026-07-28, pairs each major risk with a control, and routes you to deeper pieces. The material is defensive analysis and no audit. Specification claims cite the page we read, and we flag every place where we go beyond it.

Four surfaces, four kinds of failure

A deployment breaks into a host and client that hold tokens, servers that expose tools, resources and prompts, an authorization layer, and the content that moves through them. Three of those look like routine application security. Content does not, because a description or a result is language the model reads and may follow. Some of the risk is therefore injection, covered in prompt injection attacks and what stops them.

What the current revision changed

The changelog for the 2026-07-28 revision lists several shifts that matter to defenders. It removes protocol-level sessions, so list endpoints no longer vary per connection, and servers that need state across calls mint explicit handles passed as ordinary tool arguments. It makes the protocol stateless, with every request carrying its protocol version and client capabilities. It also requires cache fields on list results, and tells authorization servers to include an issuer parameter that clients must validate (MCP changelog). Our write-up of the security changes goes through them in order. Implementations lag specifications, so check what your SDKs and clients support.

Authorization in one page

Authorization is an opt-in feature. Over HTTP the flow applies; over stdio, credentials come from the environment instead. In OAuth terms the server is the resource server and the client is the client, and discovery goes through the metadata document defined in RFC 9728. Client ID Metadata Documents are the preferred registration route, and Dynamic Client Registration is described as deprecated and kept for compatibility (MCP authorization specification).

One rule deserves memorising: audience validation, meaning a server only accepts tokens minted for it. What goes wrong without it is explained in the token audience and confused deputy article.

Seven risks, each with its control

Proxy servers and consent

The security best practices page describes a confused deputy attack on MCP proxies that front third-party APIs. It needs four conditions at once: a static client ID at the third-party authorization server, dynamic client registration, a consent cookie set by that server, and no per-client consent in the proxy. The countermeasures are consent stored per client on the MCP side, redirect URIs compared exactly and consent pages that cannot be framed (security best practices).

Accepting and forwarding foreign tokens

Token passthrough, where a server accepts a token not meant for it and forwards it downstream, is forbidden. The page names three harms: controls that rely on audience get bypassed, audit trails blur because downstream logs name the wrong caller, and trust boundaries collapse (security best practices).

Request forgery during discovery

During metadata discovery a client follows URLs that a hostile server supplies, and those can point inward or at cloud metadata services. Mitigations include HTTPS only, blocking private and link-local address space, validating each redirect and sending server-side clients through an egress proxy. The page also advises against writing your own IP filters, because encoding tricks fool custom parsers (security best practices).

State handles

With sessions gone, a handle carries state between calls. Holding one must never count as proof of identity. Generate handles from a secure random source, let them expire, and tie each to the verified user (security best practices).

Local servers

Local servers inherit the privileges of the client. Code execution can follow from a tampered startup command, a hostile package or a localhost service left open. One-click installs must show the complete command and obtain approval, and the page suggests a sandbox that starts with almost no privileges (security best practices). A real case is the malicious wallet-key package teardown.

Scopes that are too broad

A server that advertises every scope, paired with a client that asks for all of them, hands an attacker everything on a single stolen token. The preferred pattern starts narrow, escalates through step-up challenges and logs each elevation (security best practices).

Poisoned tool text

This item is our own framing, not specification text. Names, descriptions and results are untrusted input. Freeze descriptions, compare them on each update, and gate consequential tools with approval. Simon Willison's lethal trifecta of private data, untrusted content and an outbound channel is a useful test for any server you add.

Who owns which control

Role	Control	Purpose
Client builder	Validate the issuer; keep credentials per issuer	A code cannot be redeemed elsewhere
Client builder	Show the whole launch command	No silent execution
Server builder	Verify audience; never relay another service's token	Trust boundaries hold
Server builder	Mint random handles bound to the user	Defeats handle guessing
Platform team	Sandbox local servers and restrict outbound hosts	A hostile package has little reach
Platform team	Keep an approved, version-pinned catalogue	Fewer unknown dependencies
Security team	Log calls, elevations and edited descriptions	Evidence and alerts

A real package, a real lesson

Knostic's AgentMesh team analysed an npm package that promised its agent would auto-sign micropayments. According to Knostic, the package performed no local signing and, once a wallet key was configured, copied the raw key into an HTTP header sent to a remote endpoint with each tool call. Knostic reports finding no evidence of stolen funds, and notes that download counts are not victim counts and that static analysis cannot establish intent (Knostic analysis). The lesson is generic: documentation described one behaviour and code did another, in a file short enough to read in minutes.

Reviewing one third-party server

Imagine a request for a server that pulls tickets and drops summaries into a chat channel. One reviewer can finish the assessment in an afternoon:

1. Provenance. Establish the publisher, the source location and a way to report flaws.
2. Behaviour versus description. Read the code behind the two operations. Look for unexpected hosts and environment reads.
3. Credentials. Ask for read access limited to a single project, with a short lifetime where the platform allows it.
4. Isolation. Execute it in a sandbox whose outbound rules name just the two services it needs.
5. Tool text. Record a hash of descriptions so later edits are visible.
6. Logging and exit. Confirm calls are logged and write the steps to disable it and revoke its token.

The scored version of this review is in the pre-install checklist.

Containment before polish

Teams like to start with the OAuth flow, because it is specified, testable and satisfying to get right. For most organisations that is the wrong place to spend the first month. Their exposure sits in local servers installed by developers and in tool text nobody reviews, neither of which an authorization flow touches.

Evidence supports looking at the supply side first. Trend Micro audited 9,695 distinct MCP servers crawled from public sources between November 2025 and March 2026, and in a June 2026 post reported 2,259 servers with confirmed issues, with missing authentication the most common flaw and no reliable link between popularity and security. Anthropic's Claude Code security page states that the company reviews directory listings against its criteria without auditing or managing any MCP server, and encourages writing your own or choosing providers you trust (Claude Code security). Registries are distribution, not review.

The call: inventory every server in use, sandbox the local ones, and restrict egress before perfecting authorization. Anyone who runs remote MCP servers for other people should reorder this. If you publish a server, authorization, audience checks and consent handling are your product's front door and come first. Trend Micro is also a vendor with a stake in the finding, and its crawl covers public servers, so weigh it as one study.

Local or remote: which risks follow you

Question	Local (stdio) server	Remote (HTTP) server
Where does the code run?	On the user's machine, with the user's rights	On the vendor's or your own infrastructure
Main exposure	Code execution, files, environment secrets	Token handling, consent, request forgery, data sharing
Strongest control	Sandbox, pinned version, egress allowlist	Audience validation, narrow scopes, vendor review
Who can inspect it	You can read the code you installed	You rely on the vendor's statements and logs

The table also explains why a single policy rarely fits. A rule written for remote servers says nothing about the package a developer installed last night, and the reverse is equally true.

Mistakes that recur in reviews

• Approving a server on the strength of its listing, its readme or its install count.
• Letting a client request every advertised scope because the consent screen only appears once.
• Storing a long-lived token in a configuration file shared across a team.
• Assuming a gateway reads and judges tool descriptions.
• Skipping the diff when a server updates, so changed tool text reaches the model unnoticed.

Gateways help but do not judge content

One gateway can enforce sign-in, quotas, logging and allowlists in a single place. It cannot tell whether a description is truthful or whether the code behind a server matches its documentation. This gateway analysis sets out the limits.

What to log

Event	Fields	Reason
Connection	Server identity, build, transport	Notice new or altered servers
Tool list fetch	Digest of names and descriptions, freshness hint	Reveal edited tool text; the revision adds freshness hints, so lists can be cached
Invocation	Agent, user, tool, summary of arguments, outcome	Rebuild the sequence of events
Authorization step	Requested and granted scope, audience, issuer	Expose escalation and mismatches
Refusal	Which rule refused it	Refine policy, notice probing

The changelog also documents trace context conventions in request metadata, which helps follow one request across client, gateway and server (MCP changelog).

A rollout in five phases

1. Inventory. Exit test: you can list every server, owner and version.
2. Catalogue. Approved list with pinned versions and a request path.
3. Contain. Sandbox, egress allowlist, secrets through a broker. A test server cannot reach unlisted hosts.
4. Observe. Central logs, with an alert when an unapproved server appears.
5. Rehearse. Disable and revoke one server within a time you set.

Unknowns

• How widely the 2026-07-28 changes are implemented across SDKs and clients.
• How the protocol will treat tool description integrity. The specification does not address description trust directly, and cache fields raise the value of diffing.
• How many malicious servers exist. Vendor reports differ and no reliable count is available.

For identity design around servers and agents, see the identity guide. This page is no substitute for a review by qualified security engineers.

MCP security, answered briefly