MCP rug pull is the sudden or hidden replacement of a trusted Model Context Protocol server, tool, or connector with one that behaves differently after adoption. In practice, an AI agent may inherit new permissions, altered outputs, or data exposure because the underlying MCP endpoint changes without clear review or control.
What MCP rug pull means in practice
MCP rug pull is a trust-break event, not just a software change. The danger is that an AI system may continue to rely on a connector or server that now behaves differently, so the agent’s permissions, outputs, and data flows can change without a visible security review.
This matters because Model Context Protocol is often used to standardise how agents discover and call tools. If the underlying endpoint is replaced or repurposed after adoption, the integration can still look legitimate while its security posture has fundamentally changed.
Why MCP rug pull is dangerous
The core risk is hidden capability drift. A connector that once performed a narrow task can later request broader access, return misleading results, or expose sensitive context to a different operator, which turns a trusted integration into an unreviewed dependency.
For agentic systems, that matters more than in ordinary integrations because the agent may automatically reuse stored trust, cached configuration, or previously approved access paths. A change in the MCP server can therefore become a change in effective authority, not just a change in functionality.
Trust also tends to be inherited across teams. Once developers, platform teams, or users approve an MCP endpoint, downstream agents may treat it as durable infrastructure even when the server is swapped, relocated, or reconfigured.
How organisations should assess exposure
Exposure starts with inventory. Organisations need to know which agents, desktops, workspaces, and automation flows are connected to which MCP servers, because a hidden replacement is only visible when the dependency chain is explicit.
They also need to check whether the MCP endpoint is externally reachable, privately hosted, or distributed through a registry or gateway. Public exposure and loose onboarding controls increase the chance that a “trusted” connector can be replaced or shadowed without immediate notice. The MCP Gateway and MCP Server Governance Guide is useful here because it focuses on approval tiers, allowlists, and monitoring for MCP server governance.
Vendor advisories, registry records, and change logs should be checked together. If the published server identity, transport mode, or tool inventory changes without a matching review, that is a signal that the integration is no longer operating under the same assumptions that were originally approved.
The MCP Security Guide is a good reference point for the authorisation model, token handling, and gateway patterns that matter when evaluating whether a server is still the one you intended to trust.
How to reduce the blast radius of a replacement
Reduction starts by treating MCP servers like governed dependencies, not informal plugins. Approval should be tied to an identifiable server, an explicit tool set, and a defined permission scope, so a replacement cannot silently inherit broader trust.
Controls should also limit what the agent can pass through to the server. If a changed endpoint can see all upstream tokens, files, or prompts, the rug pull can turn into a wider confidentiality or privilege problem than the original tool ever justified.
Strong deployment hygiene helps too. Private registries, server allowlists, audience-bound tokens, and monitored rollout paths make it harder for a changed endpoint to blend in as the original one. That is why practical governance guidance for MCP server governance is so important for agent deployments that depend on external tools.
Teams should also separate low-risk utility tools from higher-trust connectors. A server that can read sensitive context, alter outputs, or trigger side effects deserves tighter review than a read-only lookup tool.
What to review after a suspected MCP rug pull
If a replacement is suspected, review the server identity, tool catalog, access logs, and any agent actions that occurred after the change. The question is not only whether the server was modified, but whether the agent inherited new behaviour before anyone noticed.
Post-change review should include any secrets, tokens, or credentials that may have been exposed to the old or new endpoint. If the new server had broader visibility than expected, the safest assumption is that the trust boundary has already been crossed.
The AI Agent Tool and Plugin Security Guide helps anchor the review in tool validation, scoped permissions, and tool-output controls, which are the practical defences most directly affected when an MCP endpoint changes after adoption.
Risk and Threat Considerations
An MCP rug pull can create both exposure and adversarial opportunity. The hidden replacement may preserve the same name or interface while changing what the agent can access, which makes it easier to abuse trust, redirect outputs, or exfiltrate data through a path that defenders still believe is approved.
Failure mechanism: The agent continues to trust a server identity or configuration that has been swapped, repointed, or silently re-scoped, so the new endpoint inherits permissions and context it should not have had.
Impact: This can lead to unintended data exposure, altered tool behaviour, unauthorized side effects, and compromised decision-making in workflows that rely on the MCP connection.
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 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI04 — Agentic Supply Chain Vulnerabilities | Covers replaced or tampered agent dependencies and tool supply paths |
| Recommendation — Track MCP servers as agent supply-chain dependencies and reapprove them after any change. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Limits the blast radius if a swapped MCP server inherits broader access |
| CM-5 — Access Restrictions for Change | Controls who may alter trusted configurations and dependencies | |
| AU-2 — Event Logging | Supports detection and review of endpoint changes and post-change activity | |
| Recommendation — Constrain agent and server permissions to the minimum needed for each approved tool. Restrict who can modify approved MCP endpoints and their configuration records. Log MCP server changes and agent interactions so hidden replacements can be investigated. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | A changed MCP server can behave like a risky third-party dependency |
| Recommendation — Assess third-party MCP endpoints as governed dependencies before granting agent access. | ||
Practitioner Guidance
Why practitioners should care: MCP rug pull is a governance problem as much as a technical one. If an organisation cannot prove which server an agent is actually using, it cannot reliably defend the permissions or outputs that follow from that trust decision.
What to watch for: Treat changes in server ownership, transport, tool inventory, or authentication path as review triggers, even when the endpoint name stays the same. A stable label is not evidence of a stable trust relationship.
Practitioner takeaway: Bind approval to a specific MCP server identity and re-approve the integration whenever that identity, capability set, or trust path changes.
Related resources from NHI Mgmt Group
- Why do MCP rug pull attacks create such a high risk for enterprise AI agents?
- How should security teams implement MCP data protection in environments where AI agents pull from SaaS and cloud tools?
- What are the signs that a crypto project is becoming a rug pull?
- What is the difference between a legitimate crypto project failure and a rug pull?