MCP security is the work of controlling what Model Context Protocol servers can tell an AI agent and what they can do with the access the agent hands them. It matters to any team whose developers run Claude Code, Cursor, VS Code or Claude Desktop with MCP servers attached. The clearest reason is a campaign from this August that waited politely for its third tool call.
On August 10, 2026, one GitHub account opened 23 pull requests against unrelated AI, MCP and developer-tool projects in 74 minutes, most of them adding an MCP server called productivity-suite to the project’s configuration. Pillar Security named the campaign Deadbugz. The server offered two harmless tools, format_text and summarize, and they worked. After a connected client made three tool calls, the server changed the tool descriptions and prompts it returned, telling the agent to look for sensitive local files and to hide the activity from its user. Anyone who tried it once or twice saw nothing wrong. We will come back to that third call, because almost every control in this post is about what happens after you decide to trust a server.
What is MCP security, and why is it different from API security?
An MCP server exposes tools, prompts and resources to an AI client, and the client passes the tool descriptions to the model as context for deciding what to act on. In ordinary API security an endpoint’s description is documentation that a human reads. In MCP it is input to a model that acts, so a description can carry instructions.
Invariant Labs called this tool poisoning in April 2025, when they showed an innocent-looking add tool whose description told the model to read ~/.cursor/mcp.json and the user’s SSH private key and pass both along in a hidden parameter. They ran it against Cursor. The confirmation dialog did not show the full tool input, so the user approved an addition and shipped their keys. The mcp.json file mattered as much as the SSH key, because that file typically holds credentials for the user’s other MCP servers.
Three properties follow from this design. Instructions can live in metadata the user never reads, a server’s metadata can change after approval, and every connected server’s descriptions share one model context, so one server can talk about another’s tools.
The MCP security risks that show up in real incidents
The OWASP MCP Top 10, still a beta draft, lists ten categories. We find it more useful to sort real incidents by where trust breaks, because that tells you where the control has to sit.
Poisoned and shadowing tool descriptions
Beyond the single poisoned tool, Invariant demonstrated shadowing. With a trusted email server and a malicious server connected to the same client, the malicious description told the agent to route every send_email message to the attacker. The agent did so even when the user named a different recipient. Academic work has since put numbers on the problem. Hasan and colleagues scanned 1,899 open-source MCP servers and found 5.5% showing MCP-specific tool poisoning and 7.2% carrying general vulnerabilities. A STRIDE and DREAD threat model by Huang and colleagues ranked tool poisoning the most prevalent and impactful client-side vulnerability, and most of the seven clients they tested lacked adequate static validation and parameter visibility.
Rug pulls and malicious updates
Invariant’s same April 2025 write-up warned that a server can change a tool description after the client has already approved it. The package registry version of that arrived in September 2025. The npm package postmark-mcp, a server that let AI assistants send email through Postmark, was clean at version 1.0.15. Per Snyk’s analysis, the only notable change in the malicious release was one line adding a hidden BCC that copied every outbound email to an external domain, with the behavior starting around 1.0.16. Snyk also noted that installed copies keep running until someone removes them, so pulling the package from npm did nothing for machines that already had it. Deadbugz then moved the switch from the release cycle into runtime, with the three-call gate as an explicit way to beat brief inspections.
Prompt injection through trusted servers
Not every incident needs a bad server. In May 2025 Invariant showed that a malicious issue in a public repository could steer an agent using the official GitHub MCP server into reading private repositories and leaking their contents into a public pull request. Invariant was clear that the GitHub server code was not at fault. The agent simply had access to private repositories its task did not need, and Invariant noted that many users run agents with “Always Allow” confirmations. Our prompt injection guide covers this class in depth. The MCP lesson is narrower, because a server’s reach is the reach of the token behind it.
Token passthrough and exposed servers
On the server side, the MCP specification’s security best practices describe token passthrough, where a server accepts a client’s token without checking it was issued to that server and forwards it downstream. The specification forbids it outright. Passthrough also wrecks the audit trail, because downstream logs show requests under an identity other than the server making them. Exposure compounds this. Trend Micro first counted 492 MCP servers running without client authentication or encryption in July 2025. By its April 28, 2026 update the count of exposed servers had reached 1,467, 1,227 of them on the deprecated legacy SSE transport.
| Period | Value |
|---|---|
| July 2025 | 492 |
| April 2026 | 1,467 |
The same research reviewed more than 19,000 MCP server code bases and found that nearly half recommend storing secrets in .env files or plaintext JSON. Pillar summed up its 2026 disclosures in a line worth repeating in every architecture review, that the caller supplies the instruction, and the MCP server supplies the authority.
Why one-time approval fails
Put the incidents side by side and every one of them passed a moment of trust. The postmark-mcp server was a reasonable install at 1.0.15, Deadbugz looked fine for its first three calls, and the GitHub server was official. Registries do not close this gap either. Li and Gao analyzed 67,057 servers across six public registries and found that weak vetting and ownership checks let adversarial or hijacked servers into hosts, after which hosts act on tool metadata without independent verification.
That is why our position is that the approval decision should attach to a specific version and a specific set of tool definitions, not to a server name. Pillar’s own recommendation after Deadbugz says much the same, asking clients to treat a changed tool definition on an approved server as a security event and to compare a fingerprint captured at approval time. If your tooling cannot tell you that a description changed since Tuesday, you are trusting a name, which is exactly what Deadbugz and postmark-mcp abused.
MCP server security: what the specification now requires
The protocol has hardened, and the mandatory controls are the ones you can demand from vendors. The current security best practices say servers must not accept tokens that were not issued for them, and that proxy servers must collect per-client consent and match redirect URIs exactly to stop confused deputy attacks. Clients that offer one-click local server setup must show the exact command, untruncated, and get explicit approval before running it, and they should sandbox local servers with minimal default privileges. Scopes should start small and grow through step-up challenges, with servers logging each elevation.
The July 28, 2026 revision also made the protocol stateless and removed the Mcp-Session-Id header, and the security guidance now says plainly that holding a state handle is not authentication. Servers built against older revisions keep their old behavior until someone updates them, so ask every vendor which revision they implement.
How to detect a malicious or misbehaving MCP server
Detection starts with knowing what is installed, which is why OWASP lists shadow MCP servers as MCP09. Configuration files on developer endpoints and in repositories are the inventory, and Deadbugz arrived as an ordinary-looking pull request that edited one. Treat any change to an MCP configuration file in a pull request as a code review item that needs an owner’s sign-off, the same as a new dependency.
From there, watch the places where a misbehaving server leaves traces. A tool-definition refresh on an approved server is the first signal, which is exactly what Deadbugz produced after its third call. Agent actions that touch credential paths (SSH keys, cloud credential files, other MCP configurations) right after a call to an unrelated tool are the second. Outbound mail to a domain that has never received your mail before is the third, and it is the trace postmark-mcp left. For remote servers, the 2026 revision requires Mcp-Method and Mcp-Name headers on Streamable HTTP requests, which means a gateway or egress proxy can log which tool was called from the headers alone, without parsing every request body.
These signals have limits. A poisoned description that never triggers an unusual action will not show up, and a server that misbehaves only for some clients can pass your tests. If a device did connect to a known-bad server, Pillar’s advice is to preserve the MCP client logs before cleanup and review agent actions after the tool definitions changed.
Mitigation: MCP security best practices for an enterprise rollout
Most of these controls are ordinary security engineering your team already knows how to run.
- Keep an allowlist of approved servers, each pinned to a version, and block anything else at the client or the network.
- Record a fingerprint of each server’s tool descriptions at approval and require re-approval when it changes.
- Run local servers in a sandbox with no default access to home directories, SSH keys or cloud credential files.
- Give each server its own narrowly scoped token, validate token audience, and never let a server forward a user’s token downstream.
- Keep sensitive actions (sending email, writing to repositories, reading secrets) behind policy checks that a tool description cannot override.
- Never expose an MCP server to the internet without authentication, and retire the legacy SSE transport.
- Move secrets out of plaintext MCP configuration files into a secrets manager.
Our AI agent identity management guide covers the token and delegation half of this list in more depth. If you want help building the allowlist, approval flow and monitoring for your own rollout, that is what our LLM and agent security practice does.
Frequently asked questions
Is MCP safe to use?
MCP can be used safely, but the protocol does not make a server trustworthy. The risk comes from what servers say to the model and what access they hold. Pinned versions, sandboxed local servers, narrow tokens and policy checks on sensitive actions make it manageable, and an open configuration where anyone can add any server does not.
What is MCP tool poisoning?
Tool poisoning hides instructions in a tool’s description, which the model reads but the user usually does not see in full. The instructions can tell the agent to read files, pass secrets in hidden parameters or change how it uses other servers’ tools. Invariant Labs described the attack in April 2025, and OWASP lists it as MCP03 in its draft MCP Top 10.
What is an MCP rug pull?
A rug pull is a server that behaves well when you approve it and changes later, through a malicious update like postmark-mcp’s or after a set number of calls like Deadbugz. The defense is to tie approval to a version and to the exact tool definitions, and to alert when either changes.
Bottom line
Back to the third call. Deadbugz looked harmless for exactly as long as a reviewer was likely to look, and that is the gap MCP security has to close. This week, inventory every MCP server configured on your developer endpoints and in your repositories, pin each one to a version, and make a change to its tool definitions trigger a fresh approval.