Securing The Model Context Protocol: Tool Poisoning, Rug Pulls And The Spec

The Model Context Protocol, usually shortened to MCP, is an open standard for connecting AI applications to tools and data. An application such as a coding assistant acts as the host. It runs MCP clients, and each client talks to an MCP server that offers tools, resources or prompts. A server can run on the user’s own machine or as a remote service.

MCP spread quickly because it makes adding a tool almost effortless. That ease is also the security problem. Every server a user installs adds text the model will read and actions the agent can take. This article covers the two kinds of MCP risk, the attacks seen so far, and what the current specification requires. It refers to protocol version 2026-07-28, which is the current version as of October 2026.¹

Two Different Kinds Of Problem

It helps to separate two classes of risk, because they need different fixes.

The first is about trust. Tool names, descriptions and results are text that goes straight into the model’s context. A model can be steered by that text just as it can by a malicious web page. The specification cannot fully solve this, because it is a property of how language models work. It is mostly up to the host application and the people who choose which servers to install.

The second is ordinary software security. MCP servers, clients, proxies and developer tools are programs, and they have had familiar bugs: command injection, missing authentication on local ports and weak token handling. The specification and its security guidance address many of these directly.

Tool Poisoning And Rug Pulls

In April 2025, Invariant Labs published an early description of a tool poisoning attack. Instructions were hidden in an MCP tool’s description, where the user would not normally see them but the model would read them.² In one demonstration, a harmless-looking tool installed alongside a trusted email server carried hidden instructions that redirected the agent’s outgoing email, even when the user named a different recipient. Invariant called this “shadowing”, because one server’s description changes how the agent uses another server’s tools.

The same post described the rug pull. A server can change its tool definitions after the user has approved it, turning a safe tool into a harmful one without any new approval. Invariant recommended showing full tool descriptions to users, pinning server versions with checksums, and enforcing stricter boundaries between servers.²

OWASP’s incident tracker lists a September 2025 case that Koi Security reported as the first malicious MCP server found in the wild.³ A package called postmark-mcp on the npm registry impersonated the email company Postmark. According to Postmark, the publisher released 15 clean versions before version 1.0.16 added code that secretly sent a blind copy of outgoing emails to an outside server.⁴ Postmark had no involvement with the package. It shows how a supply chain attack and a rug pull combine: trust built over time, then a quiet change.

Implementation Bugs

The second class of problem is more familiar to security teams. Two examples from 2025 show the pattern.

• MCP Inspector. The developer tool used to test MCP servers had no authentication between its browser client and its local proxy in versions before 0.14.1. An attacker could cause it to launch commands on the developer’s machine. It was published as CVE-2025-49596 in June 2025 and rated critical.⁵
• mcp-remote. A widely used client-side proxy was open to operating system command injection when connecting to an untrusted MCP server. It was rated 9.6 out of 10 and fixed in version 0.1.16 in July 2025.⁶

More MCP-related vulnerabilities have been disclosed since. Treat any MCP component, including developer tools, as software that needs patching and review.

What The Current Specification Requires

The 2026-07-28 revision changed several security-relevant details. The protocol is now stateless, with no protocol-level sessions.⁷ Each request declares its protocol version, and every server must offer a discovery method that returns its versions, capabilities and identity, although clients are free to skip it.¹ Revisions dated 2025-11-25 and earlier used a handshake and session IDs, so security advice written in 2025 may describe mechanisms that no longer apply.

Authorisation is optional in MCP. Where it is used over HTTP, MCP builds on OAuth 2.1, which is still an IETF draft. The MCP server plays the part of the resource server, meaning the service that checks access tokens, and the MCP client plays the OAuth client.⁸ The key rules are:

• clients must name the server they want a token for, using RFC 8707 resource indicators, and servers must check that each token was issued for them;
• servers must not accept or pass on any other tokens, which rules out token passthrough;
• servers publish Protected Resource Metadata (RFC 9728) so clients can find the right authorisation server;
• clients must apply the issuer checks from RFC 9207 to each authorisation response before using it, which guards against mix-up attacks where a response from one authorisation server is passed off as coming from another;
• Client ID Metadata Documents, also an IETF draft, are the recommended way for clients to register, and Dynamic Client Registration is now deprecated;
• servers should ask for precise scopes, meaning the specific permissions a token carries, and support step-up authorisation that adds permissions only when needed, rather than granting everything at once.

Local servers that use the stdio transport should not use this flow and take credentials from their environment instead.⁸ The separate Security Best Practices page covers confused deputy proxies, token passthrough, server-side request forgery, state handle hijacking, local server compromise, authorisation URL validation and scope minimisation.⁷

Practical Steps

For organisations using MCP, as of October 2026, a sensible baseline is to keep an approved list of servers and versions, review tool descriptions before approval, and alert on any change. Run local servers in a sandbox with explicit file and network grants. Give each remote server the narrowest scopes it needs. Avoid combining a server that reads untrusted content with one that holds private data and can send it out, in line with the Rule of Two covered earlier in this group. Keep developer tools such as inspectors and proxies patched and never expose them on open network interfaces.