MCP Rug Pull Protection Mechanisms Across Leading Tools

An MCP rug pull happens when a tool's definition changes after an agent has already approved it, turning something a human signed off on into something nobody signed off on, with no warning and no new approval prompt. The name comes from DeFi, where a project draws in investment and then drains the liquidity and vanishes. The MCP version works the same way in spirit, but it operates on meaning and text instead of money.

The root cause sits in the protocol itself. Under the MCP specification (dated November 25, 2025), a server's tools/list response can change between calls, and nothing in the spec requires re-approval or an integrity check when it does. There's no cryptographic content-addressing, no version pinning on tool descriptions in the base spec. A server that got a clean audit at time zero can behave completely differently an hour later, and the protocol has no built-in way to notice.

This is worse than it sounds because tool descriptions are just text. A malicious update doesn't need a compiled binary or a native library slipped into a dependency tree. One added line in a docstring does the job. Most MCP clients bind trust to a tool's name, not its actual content, and this is the cause: it lets the "approved" status stick around across sessions even while the definition underneath quietly changes. Prompt-injection payloads buried in a tool description get read by the model just fine. They almost never appear in the client's UI, so the person using the tool never sees the injected instructions on screen.

Everything covered from here on is a workaround for something the protocol doesn't hand you for free.

The attack's fifteen-month path to becoming a documented threat class

Invariant Labs put a name to this in April 2025 with the Tool Poisoning Attack paradigm, backed by a public proof-of-concept showing a single poisoned tool description could pull private repository contents and message histories out of a system with zero user interaction.

The academic naming followed in June. Bhatt, Narajala, and Habler at Cisco published "ETDI: Mitigating Tool Squatting and Rug Pull Attacks in Model Context Protocol (MCP) by using OAuth-Enhanced Tool Definitions and Policy-Based Access Control" on arXiv (2506.01333) on June 2, 2025, the first paper to formally classify rug pulls and tool squatting as primary MCP threats.

Then came the real-world cases, one after another.

The postmark-mcp npm package quietly BCC'd every email it processed to an attacker's address, before anyone caught it. The package had built up fifteen clean versions of trust before the payload turned on. In July 2025, Check Point researchers disclosed CVE-2025-54136, dubbed MCPoison, CVSS score 8.8, showing Cursor kept trusting an approved config key even after the command behind it had been swapped out. That's the rug pull pattern, formalized against a shipping production client. Then in January 2026, a project called Clawdbot picked up 60,000 GitHub stars in 72 hours, and when security researchers went and scanned the install base that spun up around it, they found over 2,000 exposed MCP instances leaking API keys and full conversation histories.

By 2026, the scale gets uncomfortable. Censys counted 12,520 internet-accessible MCP services, with roughly 40% of remote servers exposing tools with no authentication whatsoever. Over 40 CVEs have been logged against the ecosystem, tied to a substantial number of affected downloads in early 2026 alone. The MCPTox benchmark found a 72.8% attack success rate against o1-mini across 45 real-world MCP servers. Even one of the most resistant models in that test still failed to refuse the attack the overwhelming majority of the time.

Invariant Labs named the attack in April 2025, and by July 9, 2026, Vercel had shipped a native detection primitive into its AI SDK, showing the pattern in the dates. Call it fifteen months, start to finish, for a threat to move from a security researcher's blog post to a formal academic paper to vendor guidance to actual code sitting in a default toolchain. Enterprises evaluating defenses today are picking among mechanisms that matured at very different points along that same fifteen-month arc.

The four points a protection mechanism must catch

The attack breaks down into its mechanics, revealing four separate checkpoints, each one a place a defense can intervene.

Identity: can the system verify the tool actually comes from whoever it claims to come from?

Definition integrity: can it detect that the approved definition changed between sessions, or even between two calls in the same session?

Re-approval trigger: once a change is detected, does the workflow force a human to make a new decision before the tool runs again, or does it just log the change and move on?

Runtime enforcement: even for a tool that's unchanged and fully approved, can the system limit what it's actually allowed to do the moment it's invoked?

No single mechanism covers all four. Cryptographic signing nails identity and integrity but has nothing to say about what happens at runtime. Behavioral scanning is good at catching semantic manipulation, the kind of thing a signature can't see, but it can't enforce least-privilege access on its own. Runtime policy enforcement can block an unsafe call in the moment, but it depends on a governance layer that most teams simply haven't built yet, and without that layer, enforcement alone falls short.

A team running just one of these has a partial defense, not a real one. The sections below map exactly which point each tool covers and which one it leaves wide open.

A single malicious server can, through tool-name shadowing, weaponize every other trusted server an agent is connected to at once, filesystem-mcp, github-mcp, whatsapp-mcp, stripe-mcp, all of it, so blast radius across servers is another dimension worth testing every mechanism against. A single malicious server can, through tool-name shadowing, weaponize every other trusted server an agent is connected to at once, filesystem-mcp, github-mcp, whatsapp-mcp, stripe-mcp, all of it. A defense that only watches one server in isolation is guarding a perimeter that doesn't actually exist in a multi-server setup.

ETDI: the cryptographic approach that addresses the gap at the protocol level

ETDI comes from the same Cisco team, Bhatt, Narajala, and Habler, arXiv:2506.01333, published June 2, 2025 and also presented at the IEEE Cyber Awareness and Research Symposium (CARS) that year. It's a proposed security extension to MCP, not part of the core spec, built around cryptographic identity verification, immutable versioned tool definitions, and explicit permission management using OAuth 2.0.

Every tool's manifest, its JSON schema, permissions, and metadata, gets signed with the provider's private key. The MCP host checks that signature both when the tool loads and again at invocation. Changing one character of the tool's definition makes the existing signature stop matching, which forces a new signature and a fresh, explicit authorization before the tool can be used again. Immutable version tags do the same job from a different angle: any functional change needs a newly signed version, so the host can tell right away that what it originally approved no longer matches what the server is actually serving.

ETDI also proposes stretching into Point 4 by wiring in a policy engine, something like Amazon Verified Permissions using the Cedar policy language, or Open Policy Agent, to evaluate tool actions dynamically at runtime rather than just at approval time. The full workflow imagines signed tool manifests sitting in a registry, with approval becoming version-aware instead of name-bound.

None of this is shipping in the core MCP spec today. ETDI is academic and research-grade, and putting it into practice requires a public key infrastructure and a signed-manifest ecosystem that most MCP server publishers just don't have yet. Its runtime policy piece is a proposal on paper, not a working feature anyone can install. Teams that want the spirit of ETDI right now are approximating it: keeping hashes of approved tool descriptions by hand, borrowing code-signing tooling from other parts of the stack, or reaching for something like MCP-Scan, which implements hash-based pinning as a rough stand-in for what ETDI describes formally.

MCP-Scan (Invariant Labs / Snyk): hash-based tool pinning and cross-server shadowing detection

MCP-Scan comes out of Invariant Labs, now folded into Snyk's Agent Security line after Snyk's 2025 acquisition of the company. It's open source, past 2,000 GitHub stars, and runs with a single command: uvx mcp-scan@latest. It covers Claude Desktop, Cursor, Claude Code, Gemini CLI, and Windsurf.

Its core defense against rug pulls is Tool Pinning: it computes a hash of each tool's description the moment it's approved, then flags drift whenever that hash changes later. That's a practical, low-friction stand-in for the immutable versioning ETDI describes, minus the PKI overhead. It also scans specifically for cross-server shadowing, catching cases where a malicious server's tool name overlaps with a trusted tool from another server in the same multi-server setup, a blind spot that pure signature checking misses.

Mechanically, MCP-Scan pulls tool descriptions straight from a client's MCP config file, analyzes the text locally and through Invariant's Guardrails API, and hashes the results. That makes it a static or near-static scan rather than a live, continuous monitor. In an April 2026 audit of 33 servers, MCP-Scan turned up 96 server mutations and 11 cases of tool-name shadowing, concrete numbers that show both drift and shadowing are actively happening in real deployments, not hypothetical.

What it misses follows directly from how it works: it catches drift when a scan actually runs, but if an agent calls a tool between scans, the malicious call happens before anyone's looking. There's also no behavioral code analysis comparing what a tool's documentation says against what its implementation actually does. Snyk's broader Agent Security line covers pre-deploy scanning, runtime MCP proxying, and agent behavior controls. MCP-Scan is the entry point into that stack.

Cisco MCP-Scanner: YARA rules and LLM-as-judge analysis against known-bad patterns

Cisco's own open-source tool, released under Apache 2.0 and hosted at github.com/cisco-ai-defense/mcp-scanner, comes from the Cisco AI Defense team. It runs three detection engines side by side. YARA rules catch known-bad strings and patterns fast and deterministically. An LLM-as-judge layer semantically evaluates whether a tool description reads as manipulative, catching new phrasing that YARA hasn't seen before. And Cisco's AI Defense Inspect API does behavioral code analysis, flagging cases where a tool's documentation claims one thing and its actual implementation does another.

Deployment is flexible: it can scan a live remote server, a stdio connection, or a pre-generated JSON file offline, and it can optionally sandbox and check PyPI or npm packages, running pip-audit against known dependency CVEs along the way. The behavioral mismatch check, docs versus code, is the piece aimed most directly at the rug pull pattern: tools that started out legitimate and got quietly updated with something worse.

The numbers reveal the catch. That same April 2026 audit of 33 servers, which MCP-Scan found to contain 96 server mutations and 11 tool-name shadows, illustrates how real deployments surface a mix of genuine issues and noise that requires human triage. A team that acts on every YARA alert without a confirmation step risks spending significant investigation time on noise. The practical fix is treating YARA as a first-pass triage layer, with the LLM-as-judge step used to confirm before anyone escalates, rather than letting YARA alone gate a deployment decision. Like MCP-Scan, this is still a point-in-time scanner. It doesn't watch continuously between scans, and the false-positive rate means it needs human review, which becomes a real bottleneck once an enterprise is running this across hundreds of servers.

Vercel AI SDK fingerprintTools and detectToolDrift: runtime integrity checking baked into the developer toolchain

Vercel shipped this in AI SDK version 7.0.19, on July 9, 2026, making it the newest mechanism in this comparison. fingerprintTools computes a fingerprint over the server-controlled parts of an MCP tool set, establishing a trust baseline. That fingerprint becomes the trust baseline. detectToolDrift later diffs a fresh fingerprint against that stored baseline, which reveals an injected description or a quietly widened schema before the tool definition ever reaches the model. The check happens inside the SDK layer, ahead of the LLM, not after the fact.

What makes this one different is location. A developer building on the Vercel AI SDK gets drift detection without standing up a separate scanner or maintaining a separate audit pipeline. It's built into the toolchain itself, not a product someone has to go procure and run in parallel.

In terms of the four-point framework, this covers Point 2, definition integrity, cleanly, and it can feed a re-approval trigger at the application layer, touching Point 3. It doesn't touch cryptographic identity verification (Point 1) at all, and beyond simply blocking on detected drift, it doesn't constrain runtime behavior (Point 4) either. There's also a real gap in coverage: if a rug pull changes only the server-side implementation logic and leaves the description, schema, and title untouched, the fingerprint never moves, and the change slides through undetected. Cross-server shadowing sits outside its scope. Still, the architectural significance is hard to overstate: once drift detection ships in a default SDK, the baseline expectation for every new MCP-powered app shifts with it. Teams still on older SDK versions, or building outside the Vercel toolchain, need to go find that protection somewhere else.

Straiker: continuous red-teaming and runtime policy enforcement as a combined layer

Straiker approaches the problem from a different angle than the scanners above. Rather than treating rug pull detection as a one-time or periodic scan, its Agentic Risk Framework and STAR Labs research push toward continuous red-teaming, actively probing MCP tool behavior over time instead of checking it once at approval and calling it done, paired with runtime policy enforcement that constrains what an approved tool is actually allowed to do when it's invoked.

Straiker combines continuous red-teaming with runtime policy enforcement, which sets it apart from the scanning tools. Continuous red-teaming picks up gradual, in-the-wild behavioral drift that a static hash check or a one-time YARA pass would never catch between scan intervals, while runtime policy enforcement gives it a lever to actually stop a bad call in the moment, touching Point 4 in a way that most of the mechanisms above don't reach.

Taken together, the field of mechanisms covered here splits cleanly along the four points laid out earlier. ETDI addresses identity and integrity cryptographically but remains largely theoretical. MCP-Scan and Cisco's scanner both catch drift and manipulation at scan time, with real tradeoffs in latency and false positives. A tool-level check from another vendor brings drift detection into the default developer path. Straiker pushes into continuous monitoring and runtime enforcement. No individual tool closes the whole gap alone, which is precisely the case for a centralized governance layer that coordinates identity checks, integrity checks, and runtime policy across every MCP server an organization runs, rather than leaving each check to whichever individual tool happens to be watching. MCPManager's approach to this works at the gateway level, monitoring and auditing AI data access so that these checks aren't scattered across a handful of disconnected point tools but enforced consistently as one system, across every server and every agent connected to it.

Fifteen months got the industry from a proof-of-concept blog post to a native SDK primitive. Closing the remaining gap, cryptographic identity that actually ships, runtime enforcement that doesn't require a bespoke policy engine, cross-server visibility that doesn't stop at one config file, is the work still ahead.