An MCP rug pull attack is when a trusted Model Context Protocol tool, server, or connector changes behavior after deployment to steal data, weaken controls, or redirect agent actions. In practice, an attacker or compromised maintainer replaces safe functionality with malicious code or access paths inside the AI toolchain.
What an MCP rug pull attack is
An MCP rug pull attack abuses trust in a Model Context Protocol tool, server, or connector by changing its behavior after deployment, so an apparently safe integration starts stealing data, weakening controls, or steering agent actions.
The core danger is not that the component was always malicious, but that its trust profile changes after it has already been approved, connected, and relied on by agents and operators.
Why this attack pattern is dangerous
MCP tooling sits in a privileged position between an agent and the systems it can query or act on. If a maintainer, host, or dependency is compromised, the attacker can turn a trusted path into a covert control point, which makes the change harder to notice than a brand-new malicious integration.
This is especially risky when the tool has broad read access, write capability, or token handling behavior that users did not expect. A connector that appears stable can become an exfiltration channel, a policy bypass, or a way to redirect the agent toward unsafe actions.
The OWASP Agentic AI Top 10 is useful here because it frames tool misuse, identity and privilege abuse, and supply-chain risk as first-class agentic threats.
How organisations spot exposure
Exposure review starts with inventory: which MCP servers, local connectors, hosted tools, and plugin-style integrations are trusted by agents today, and who controls their update path. That inventory should include the tool’s permissions, the data it can reach, and whether it can change agent behavior without a fresh approval step.
Teams should also check whether the integration is internet-reachable, whether the publisher or maintainer has changed, and whether the tool’s manifest, schema, or outbound requests have drifted since onboarding. Vendor advisories, release notes, and governance controls matter because the risky event is often a behavior change after deployment rather than an obvious initial compromise.
The Model Context Protocol: Authorization specification helps explain why audience-bound tokens and no token passthrough are important guardrails against trust abuse.
The MCP Security Guide also covers the practical trust boundary issues around authorization, token passthrough, and local server credentials.
Remediation and monitoring after a suspected rug pull
When a trusted MCP component changes behavior, the immediate response is to isolate it, revoke or rotate any credentials it could have seen, and validate whether agents or downstream systems consumed altered instructions or outputs. If the component is hosted or remotely managed, treat the hosting path as part of the incident, not just the tool binary itself.
Monitoring should focus on unusual tool calls, unexpected data egress, new destinations, schema drift, and agent actions that do not match the approved use case. After patching or replacement, review whether any secrets, session tokens, or API access paths were exposed and whether the agent needs to be re-onboarded onto a clean, approved integration.
The MCP Gateway and MCP Server Governance Guide is relevant because approval tiers, private registries, and monitoring are the kinds of controls that reduce post-deployment drift.
The AI Agent Tool and Plugin Security Guide is also a good companion for understanding tool validation, scoped permissions, and tool poisoning defenses.
Identity and trust implications for agents
A rug pull often becomes an identity problem as soon as the tool can act with delegated authority. If the connector can relay credentials, impersonate a user context, or reuse an agent token, the attack can cross from tool compromise into unauthorized access and privilege misuse.
That makes trust decisions about MCP servers inseparable from tool permissions, credential handling, and lifecycle governance. A safe design assumes the tool may later be altered and constrains what it can do even if it is currently trusted.
The AI Agent Identity Security: The 2026 Deployment Guide is a useful reference when the trust change affects agent identity, delegation, or short-lived credentials.
The NHI Authentication Guide is relevant where the connector’s abuse path depends on machine-to-machine authentication, token handling, or secret exposure.
Risk and Threat Considerations
An mcp rug pull attack is dangerous because the compromise may happen after approval, when defenders have already treated the integration as trusted. That makes it a supply-chain and trust-boundary problem, not just a code-injection problem.
Failure mechanism: A legitimate tool, server, or connector is updated, repackaged, or repurposed so it silently changes behavior and begins exfiltrating data, weakening controls, or steering agent actions through a trusted path.
Impact: The result can be credential leakage, covert data access, unauthorized tool use, and compromised agent decisions, especially where the integration holds broad permissions or sees sensitive sessions, tokens, or secrets.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI04 — Agentic Supply Chain Vulnerabilities | Covers post-deployment tool and dependency trust changes in agentic systems |
| ASI02 — Tool Misuse | MCP rug pulls abuse trusted tools to alter agent behavior and actions | |
| ASI03 — Identity & Privilege Abuse | Rug pulls can abuse delegated authority, tokens, and agent permissions | |
| Recommendation — Review agent supply-chain changes and revalidate trusted tools after updates. Constrain tool use and validate tool outputs before agents act on them. Limit delegated privilege and isolate credentials from untrusted tool paths. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party MCP components can become a compromised trust dependency |
| NHI-05 — Overprivileged NHI | Malicious MCP tools are dangerous when granted broader access than needed | |
| NHI-10 — Human Use of NHI | Human approvals and maintenance decisions can be abused to change non-human tool behavior | |
| Recommendation — Assess third-party integrations for update risk and operator compromise exposure. Reduce tool permissions to the minimum required for each agent task. Separate human administration from production tool execution paths. | ||
Practitioner Guidance
Why practitioners should care: Treat MCP integrations as living trust relationships, not one-time approvals. The question is not only whether the tool was safe at onboarding, but whether its update path, maintainer control, and runtime permissions still match the risk you accepted.
Common misunderstanding: A signed or well-known tool is not automatically safe forever. Practitioners often focus on initial review and miss later behavior drift, which is exactly what makes this attack pattern effective.
Practitioner takeaway: Keep the trust decision tied to the current version, current permissions, and current operator, and revalidate when any of those change.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org