MCP security risks: tool poisoning, confused deputy and token passthrough

MCP security risks come from two places. The official spec names attacks on the protocol and gives rules for them. The tools you connect add attacks that come from research, such as tool poisoning. You need to cover both.

We checked the Model Context Protocol (MCP) spec on 9 November 2026. The versioning page lists 2026-07-28 as the current version. Spec rules change between versions, so check the version your client and server implement.

What does the MCP spec say about security?#

The spec has an Authorization page and a Security Best Practices page. Authorization is optional for MCP. When a server uses it over HTTP, the server acts as an OAuth 2.1 resource server and these rules apply.

Rules from the 2026-07-28 Authorization page:

• Clients MUST send the resource parameter (RFC 8707) in authorization and token requests, to name the MCP server the token is for.
• Servers MUST validate that access tokens were issued specifically for them as the audience.
• Servers "MUST NOT accept or transit any other tokens."
• Access tokens MUST NOT appear in the URI query string.
• Clients MUST validate the iss value in authorization responses when present (RFC 9207), to stop mix-up attacks.

The Security Best Practices page names these attacks: confused deputy, token passthrough, SSRF, state handle hijacking, local MCP server compromise, OAuth authorization URL validation, stdio transport security in proxy setups, mix-up attacks, localhost redirect URI impersonation, and scope minimization. Earlier versions named session hijacking. The 2026-07-28 version removed protocol sessions, so it describes state handle hijacking instead.

What is the confused deputy problem in MCP?#

The confused deputy problem in MCP is an attack on proxy servers that sit between a client and a third-party API. The attacker gets an authorization code without the user's consent. The spec says the attack needs all four conditions:

1. The proxy uses a static client ID with the third-party authorization server.
2. The proxy lets clients register dynamically.
3. The third-party server sets a consent cookie after the first approval.
4. The proxy does not ask for consent per client before it forwards the request.

The spec's rule is that "MCP proxy servers MUST implement per-client consent." The consent page must name the client, show the scopes and the exact redirect URI, resist CSRF and framing, and tie any consent cookie to the specific client_id. Redirect URIs need exact string matching.

What is token passthrough?#

Token passthrough is an anti-pattern where an MCP server accepts a token from a client without checking that the token was issued to that server, then forwards it to a downstream API. The spec forbids it.

The spec lists four harms: it bypasses controls such as rate limits that depend on the token audience, blurs the audit trail, breaks trust boundaries, and makes later changes harder. The fix is one line in the spec: servers must not accept tokens that were not explicitly issued for them. A server that needs a downstream API should get its own token for that API.

What is MCP tool poisoning?#

Tool poisoning is an attack where malicious instructions sit inside an MCP tool description. The user may not see them, but the model reads them. Invariant Labs published this on 1 April 2025, with updates on 7 and 11 April.

The same post names two related issues:

• Rug pull. A server changes a tool description after the client approved it.
• Tool shadowing. One server's description changes how the model uses another server's tool.

Invariant showed the idea against Cursor and proposed three mitigations: show full tool descriptions to users, pin versions by hash, and apply stricter data-flow boundaries. This is vendor research, not a spec rule. The spec's Security Best Practices page does not list tool poisoning or rug pulls as named attacks (as of the 2026-07-28 version).

The spec's Tools page for 2025-11-25 sets related expectations. There "SHOULD always be a human in the loop with the ability to deny tool invocations," clients "MUST consider tool annotations to be untrusted unless they come from trusted servers," and clients should show tool inputs before the call to avoid exfiltration. We did not re-read that page in the 2026-07-28 spec, so confirm before you cite it for that version.

Can tool output attack the agent?#

Yes. Tool output is untrusted text, and the model may follow instructions inside it. Invariant Labs' GitHub MCP disclosure of 26 May 2025 shows this. A malicious issue in a public repository steered a user's agent to read private repository data and publish it in a pull request on the public repo. The authors wrote that this was "not a flaw in the GitHub MCP server code itself," and that controls belong at system level. The demo needed access to both public and private repos and "Always Allow" confirmations. Invariant sells related security products.

The chain has three parts, and removing any one breaks it: untrusted content in context, access to private data, and a path out. Indirect prompt injection has more cases.

How do you review an MCP server?#

Check the server's code and config source, tool surface, authorization, token handling and runtime limits. The checklist draws on the spec's requirements and the research above.

How do testers assess an MCP deployment?#

Testers test the client, each server, and the agent's behavior with them together. They use test accounts and test data, and they report what they observe.

• Server tests: call tools with another user's identifiers, a token for a different audience, an expired token and a token with fewer scopes. Check the response for each.
• Client tests: point the client at a test server that returns a changed tool description, an odd authorization URL and a long tool output. Check what the user sees and what the client does.
• Agent tests: place a marker instruction in tool output and see whether the agent acts on it. Then check whether a gate stops the action.

Compare the result with the checklist and report which controls held. AI agent permissions and excessive agency cover the permission side. Our scoped MCP security assessment covers servers and clients. We test only with written authorization from the system owner.

No checklist makes MCP safe. It lowers the chance and the impact of known attacks, and it gives you evidence for your own risk decisions.