MCP security risks: what has gone wrong, and what the spec says

The Model Context Protocol (MCP) gives AI applications a standard way to connect to tools and data through servers. That makes it easy to give an agent new abilities. It also means every server you add is code you trust and text your model reads. This guide covers what has gone wrong so far, what the MCP specification itself says about security, and what to check before connecting a server.

What has already gone wrong

These are the MCP-related cases in our register, each checked against the original disclosure.

• Research demodisclosed June 5, 2026·AML.CS0067

  CI secret read through a coding agent's file tool

  Microsoft researchers hid instructions in GitHub issue and pull request text processed by Anthropic's Claude Code GitHub Action. Secret scrubbing covered shell commands, but the agent's in-process Read tool could open /proc/self/environ and expose the workflow's API key.

  Microsoft reported it on April 29, 2026 and Anthropic fixed it on May 5 by blocking sensitive /proc files (Claude Code 2.1.128). Microsoft's advice: never give one workflow untrusted input, secrets and outbound communication at the same time.

  risks: Prompt injection, Hidden context exposure, Excessive agency

  Sources: Microsoft Threat Intelligence; MITRE ATLAS AML.CS0067

• Incidentdisclosed Sept. 25, 2025·AML.CS0053

  Fake Postmark MCP server copied every email to an attacker

  Someone published an npm package called postmark-mcp that posed as an MCP server for the Postmark email service. After 15 harmless versions, version 1.0.16 added a backdoor that blind-copied outgoing email to an external server.

  Postmark says it had nothing to do with the package. It told users to remove it, check email logs and consider rotating any credentials sent by email while it was installed.

  risks: MCP and agent tool poisoning, AI supply chain compromise

  Sources: Postmark; MITRE ATLAS AML.CS0053

• Research demodisclosed April 1, 2025·AML.CS0054

  Hidden instructions in an MCP tool description

  Invariant Labs put instructions in the description of an innocent-looking add tool. In Cursor, the agent then read the user's MCP config file and SSH private key and sent them out through a hidden tool parameter. The confirmation dialog did not show the full input.

  The researchers also described rug pulls (a server changes a tool after approval) and shadowing (one server's tool description changes how the agent uses another server's tool). They recommend pinning server versions and showing users full tool descriptions.

  risks: MCP and agent tool poisoning, Sensitive information disclosure

  Sources: Invariant Labs; MITRE ATLAS AML.CS0054

The three cases fail in different places. The Postmark case is an ordinary supply chain attack that happened to target an MCP package. The Invariant Labs demonstration abuses the fact that tool descriptions go straight into the model’s context. The Claude Code case shows an MCP connection used as the way out: Microsoft lists the GitHub MCP server’s ability to post issue comments among the routes a stolen secret could leave by.

Risks the MCP specification names

The specification’s security best-practices document (version 2025-11-25) is written for people building MCP clients and servers. The risks it covers, in plain terms:

• Confused deputy. An MCP proxy server that uses one static client ID with a third-party authorization server can let an attacker obtain authorization codes without the user’s consent, by reusing a consent cookie from an earlier legitimate login.
• Token passthrough. A server that accepts a client’s token and forwards it to another API without checking it was issued to the server. The authorization specification forbids this. It bypasses downstream controls and breaks audit trails.
• Server-side request forgery. During OAuth discovery, a malicious server can supply URLs that make the client request internal addresses or cloud metadata endpoints. The document says clients should require HTTPS for these URLs in production.
• Session hijacking. Servers that implement authorization must verify every inbound request and must not use sessions for authentication. Session IDs must be secure and non-deterministic.
• Local MCP server compromise. A local server is a program on the user’s machine running with the client’s privileges, so a malicious startup command or package can run anything.

For that last risk the specification is specific. A client that offers one-click setup of a local server must show the exact command without truncation, mark it as potentially dangerous, and require explicit approval. It should also run servers sandboxed with minimal file system and network access.

▶ play · 5:37

A checklist before you connect a server

This list combines the specification, OWASP’s Agentic Top 10 and the researchers’ recommendations. Each line links back to a source on this page.

1. Know who published the server. The postmark-mcp package impersonated a real vendor, and Postmark had nothing to do with it.
2. Pin the server and tool versions, and re-check them on update. OWASP’s agentic supply chain entry (ASI04) recommends allowlisting and pinning by content hash. Invariant Labs recommends pinning so a tool can’t change after approval.
3. Read the full tool descriptions and the full arguments of each call before approving. In the Invariant Labs demonstration, the confirmation dialog hid the SSH key being sent.
4. Run local servers sandboxed, with the least file system and network access they need, as the specification recommends.
5. Give the agent’s credentials the narrowest scope that works, short-lived where possible. OWASP’s ASI02 guidance recommends per-tool least privilege and just-in-time credentials.
6. Don’t give one agent untrusted input, access to secrets and a way to send data out, all at once. Microsoft’s advice after the Claude Code case, and OWASP’s LLM01:2026 guidance, both call this the Rule of Two.
7. Log every tool call, so you can reconstruct what an agent did.

The register entry on MCP and agent tool poisoning keeps these controls with their sources, and the register builder adds them to an exportable list.