Vetting and Rug Pull Protection for Third-Party MCP Servers in Enterprise Agent Pipelines

Third-party MCP servers can pass every security check at installation, but they can still turn malicious months later, because MCP binds trust to a server's name, not to its content. A one-time approval gate, no matter how thorough, cannot catch a server that mutates after it has already been trusted.

Why MCP servers are structurally unlike traditional software dependencies

MCP agents discover new or updated tool definitions at runtime, without a human in the loop. A server can advertise one set of capabilities on Monday and a different set on Friday, and the agent will accept the update automatically. That single design fact is the root of nearly every security problem that follows. An MCP server has a fixed state only until its author pushes a change.

MCP was built to make agents capable, not to make them governable. Anthropic transferred governance of MCP to the Agentic AI Foundation under the Linux Foundation in December 2025, co-founded with Block and OpenAI. Security maturity did not keep pace.

The structural gap between MCP and a conventional dependency comes down to one fact: trust in MCP attaches to the server's name, not to what the server actually does. None of them was built for a system where behavior can change after approval.

MCP relies on dynamic capability advertisement, where agents pull in new or updated tool definitions at runtime, and that is why conventional dependency scanning falls short here. Code signing and SBOM give a security team a snapshot of trust at one moment. Some gateways approach this by treating server trust as something that has to be re-earned continuously rather than granted once: they monitor capability changes as they happen, checking what a server is actually advertising to the agent at each interaction rather than relying only on what it promised when it was first approved.

None of this is a failure of discipline on the part of security teams. A developer can wire a new MCP server into Claude or Cursor in minutes. Adoption has outrun oversight, and it was always going to.

The four attack classes that exploit this trust model

Security researchers have named four attack classes that exploit MCP's trust model, and each one hits the server at a different point in its life cycle. Grasping how each one works is the only way to understand why approving a server once, at the start, can never be enough.

Tool poisoning happens at the point of first contact. MCP has no native mechanism to catch this kind of injection. The OWASP MCP Top 10, the first OWASP framework built specifically for this attack surface, ranks tool poisoning as MCP03:2025, the third risk category across MCP deployments.

Rug pulls happen later, after trust has already been granted. Because trust binds to the server's name rather than its content, the agent has no way of noticing that what it trusted yesterday is not what it's running today. The term "rug pull" for this pattern comes from Elena Cross, and it spread widely after Simon Willison amplified it.

Tool shadowing and typosquatting both exploit how agents select which server to call. Typosquatting relies on a near-identical server or tool name tricking the model into picking the wrong one.

Confused deputy attacks and cross-server cascades close the loop. When several MCP servers share a pipeline, a compromise in one has been documented to propagate at a high rate across the others, so a single entry point can take down the full agent environment.

Standard AppSec tooling is blind to all four classes for the same reason: SAST and software composition analysis were built to read source code, and the malicious content in a tool-poisoning attack lives in metadata fields a source-code scanner has no reason to open. Runtime agent-to-server interactions sit entirely outside what most existing AppSec tools were designed to watch. The OWASP MCP Top 10 project exists specifically to track this gap, and it names privilege escalation via scope creep (MCP02) as one of the top risks in the framework. The blast radius of any single compromise scales directly with how much access the agent was handed in the first place, which is exactly the pattern the incidents below make concrete.

Six confirmed incidents that show what rug pulls and tool poisoning cost in practice

Every attack class in that taxonomy has already produced a confirmed incident or a named CVE. These cases trace a line from one developer's stolen credentials to hundreds of thousands of compromised production environments.

Postmark MCP, September 2025, stands as the clearest rug pull on record. A package called postmark-mcp impersonated the legitimate Postmark email integration and shipped fifteen clean versions before it did anything wrong, and that is how it built the trust history a rug pull needs. The trust that accumulated over fifteen clean releases was the entire attack surface.

The GitHub MCP incident in May 2025 shows how tool poisoning and over-privileged access can compound each other. An agent scoped to read-only access on support data would have had nothing to exfiltrate.

CVE-2025-6514 affects the widely used mcp-remote proxy package, and it shows what supply chain compromise can look like when it scales. The vulnerability carried a CVSS score of 9.6 and touched more than 437,000 installed environments. No individual organization's approval decision was involved in that exposure at all; the compromise reached developer machines through the package itself.

The SANDWORM_MODE campaign, identified in February 2026, shows typosquatting working at operational scale. Once installed, those servers exfiltrated SSH keys, AWS credentials, npm tokens, and other secrets through prompt injection.

Read together, these incidents trace a widening arc. The attack surface doesn't grow one server at a time. It grows through cascade, where a single ungoverned addition to a pipeline can expose every system that pipeline touches.

What a rigorous pre-adoption vetting process covers

Pre-adoption vetting is the checklist a security team runs before any third-party MCP server gets approved for production. It closes the install-time attack surface, and it is necessary. It is not, on its own, enough.

Tool description and schema inspection comes next. An opaque or unusually verbose description is a flag that requires manual review. The Cloud Security Alliance recommends that you record each tool's description, schema, and permission set at the moment of deployment. Every later monitoring check will compare back to that record.

Source code review follows: audit for shell execution capabilities, broad filesystem access, and hardcoded credentials, and review the full dependency tree for transitive risk. A dynamic security assessment found that most audited MCP servers had no OAuth authentication, and hundreds of individual tool instances exposed shell execution capabilities with no access controls. A candidate server missing these basics should not pass review: the absence is disqualifying.

Version pinning and a sandboxed trial run come after that. The Postmark MCP incident moved through fifteen clean versions before the malicious one landed. Pinning to a specific commit hash, rather than trusting a version range, would have limited the damage to teams that explicitly approved the update rather than everyone pulling the latest release automatically.

An authentication baseline check closes the list. If a server falls short of this baseline, it shouldn't clear pre-adoption review for production use, no matter how clean its code looks otherwise.

Even a server that passes every one of these checks can be updated after approval to introduce malicious behavior, as happened with Postmark. Pre-adoption vetting establishes a clean starting point. Continuous monitoring after approval is therefore mandatory, since what happens next is what pre-adoption vetting cannot cover.

Continuous monitoring controls that catch behavioral change after a server is approved

A server that passes pre-adoption review can still be updated at any later point to introduce malicious behavior, and agents won't re-check trust when that update arrives. Continuous monitoring of tool definitions and runtime behavior is the only control positioned to catch a rug pull after the server has already shipped to production.

Schema pinning and drift detection form the backbone of this layer. The OWASP MCP Top 10 makes the same recommendation: pin tool definitions with cryptographic hashes so a change is detectable even when the description text looks nearly identical to the human eye.

Real-time observability over agent-to-server interactions matters because an audit log reviewed after the fact is a postmortem, not a defense. Real-time visibility into what a server actually returns is the mechanism that surfaces these attacks before they reach production, flagging unexpected shifts in tool schemas or response patterns as they occur.

A private registry holding verified snapshots adds a structural backstop. If you treat every MCP server update as a code deployment, with diff review and explicit sign-off required, a compromised upstream server can't silently propagate into production. The Shai-Hulud campaign spread through the official MCP Registry itself. A private internal registry with its own integrity controls functions as a mitigating control against registry-level compromise.

Behavioral anomaly detection rounds out the layer: watching for tool calls that fall outside an agent's expected operational envelope, unusual data access, unexpected external network calls, or invocations outside an approved allowlist. The agent's calls were technically legal under the permissions it held, but exfiltrating salary data was nowhere near a reasonable operational expectation for that agent's job.

Access controls and identity binding that limit blast radius when a server does turn malicious

A compromise's blast radius scales directly with how much access the agent was granted.

Least-privilege scoping for agent credentials means an agent carries only what its task requires, so any broad credentials granted during development get scoped down before that agent reaches production. Ungoverned over-permissioning is a policy failure, not a default setting that happened on its own.

The CSA's Agentic MCP Security Best Practices guide places tool allowlists and per-agent least privilege inside its four-level MCP Security Maturity Model, and the model's central conclusion is that defense in depth, not any single control, is what actually holds.

OAuth 2.1-based identity binding ties agent activity, MCP connections, and individual tool calls back to the human who started the workflow. The Wiz and Amazon Q incident involved MCP server processes that inherited the full developer environment, and identity binding at the process level would have flagged that inheritance of credentials the moment it happened, when nobody expected it. A continuous vetting checklist can't catch this kind of drift either, because the compromise happens after approval. Organizations that pair initial vetting with active monitoring, and that can block a server automatically rather than waiting on a manual review, are the ones that stop rug pulls before they reach the pipeline instead of reading about them in an incident report afterward.

Every MCP server without an entry in the organization's registry is an identity nobody is accounting for, and an identity nobody is accounting for is the one that gets exploited. Shadow MCP servers, installed outside the governed path, bypass every control described in both the pre-adoption and monitoring layers simultaneously. Giving employees a sanctioned, governed path to the tools they actually need reduces shadow installations more reliably than prohibition does.

The regulatory and compliance environment hardening around MCP governance

Regulatory frameworks are starting to require the exact controls this layered architecture already produces. The EU AI Act and other emerging frameworks are moving toward mandating schema monitoring, access scoping, and identity binding as compliance requirements, not just security recommendations. Organizations that don't will be retrofitting under deadline pressure.

Treating AI governance as a competitive advantage, rather than a box to check before an audit, is what earns trust from regulators and users alike. Companies that centralize and enforce MCP access policy ahead of time ship agentic AI faster than teams planning to secure it later, because the guardrails are what let an organization say yes to a production deployment with confidence.

Assembling the layered framework: what the full vetting and monitoring architecture looks like in practice

The three layers only work as a set. Pre-adoption vetting addresses the install-time surface. Continuous schema monitoring catches mutation after deployment. Least-privilege access controls bound the damage once a server does turn malicious. An MCP gateway is the control point that enforces all three without requiring every individual agent to be configured by hand.

The CSA's four-level MCP Security Maturity Model lays out a practical path: basic authentication and transport security at Level 1, tool integrity verification and session hardening at Level 2, full message signing with supply chain controls and behavioral monitoring at Level 3, and zero-trust architecture with continuous verification at Level 4. The CSA's conclusion across all of it is that MCP security demands defense in depth: no single control carries the weight alone, and every control domain has to be addressed together.

Four controls, taken together, address the rug pull threat specifically: a private registry holding content-hash-pinned snapshots, an enforced tool allowlist per agent, OAuth 2.1 identity binding, and real-time schema drift detection. Each closes a gap the other three leave open on their own.

The gateway model is what makes this architecture workable. A gateway and guardrails architecture implements this control layer centrally, so the governed path is also the path with the least friction for the people using it day to day. Fast MCP adoption and safe MCP adoption are the same problem viewed from two angles, and the friction teams tend to blame on security is almost always the absence of a gateway, not its presence [1][2][3].

The CSA's broader recommendation is to treat MCP as critical infrastructure, with the same rigor an enterprise already applies to an API gateway or an identity provider. Organizations that do this are positioned well ahead of those still relying on default configurations and the assumption that a server trusted once stays trustworthy forever.