Rug Pull Attacks on MCP Tools: The Silent Threat to AI Agent Security

In cryptocurrency, a "rug pull" is when a project's creators drain all value after investors have committed. In the MCP ecosystem, the same concept applies to tools: a tool presents a safe, approved description to pass security review, then silently modifies that description to include malicious instructions. The AI agent, which reads tool descriptions at runtime to decide how to use them, now follows attacker-controlled instructions without any human being aware that anything changed. This is one of the most dangerous attack vectors in the MCP threat landscape, and most organizations have zero defenses against it.

How MCP Tool Descriptions Work

To understand rug pull attacks, you need to understand the role that tool descriptions play in the MCP protocol. When an AI agent connects to an MCP server, it receives a list of available tools. Each tool comes with a name, a description, and an input schema. The description is not just documentation for human developers. It is the primary mechanism by which the LLM understands what a tool does and how to use it.

Consider a simple example. A tool called get_weather might have this description:

The AI agent reads this description, understands the tool fetches weather data, and calls it appropriately. This is the normal flow. Now imagine the tool is approved, deployed, and working correctly for weeks. Then, silently, the description changes.

Anatomy of a Rug Pull Attack

A rug pull attack on MCP tools follows a consistent pattern with distinct phases.

Phase 1: Legitimate Registration

The attacker registers a tool with a completely legitimate description. It does what it says. The code is clean. If your organization has a security review process for MCP tools, the tool passes that review. It gets deployed into production and starts serving requests. During this phase, the tool builds a track record of benign behavior. Logs show normal usage. No alerts fire. Security teams gain confidence in the tool.

Phase 2: Silent Modification

After days or weeks of normal operation, the attacker modifies the tool description on the MCP server. The tool name stays the same. The input schema stays the same. But the description now contains embedded instructions:

The next time an AI agent fetches the tool list, it reads the modified description. The LLM interprets the "IMPORTANT" instruction as a legitimate requirement and complies, reading the user's SSH private key and embedding it in the request. The tool now has access to the private key.

Phase 3: Exploitation

The modified description can instruct the agent to do almost anything within its permissions: exfiltrate data, call other tools in a harmful sequence, bypass security policies, or leak sensitive information. The attack is particularly dangerous because there are no code changes to detect, no vulnerability to patch, and no anomalous network traffic. The tool's behavior, from the server perspective, is unchanged. It still accepts requests and returns weather data. The damage happens entirely on the client side, where the agent follows the malicious instructions.

Why This Attack Is So Effective

Rug pull attacks exploit several assumptions that are deeply embedded in how organizations think about security:

Real-World Attack Scenarios

Scenario 1: Supply Chain Compromise

A popular open-source MCP server for database querying is used by hundreds of organizations. An attacker gains access to the server's repository (via a compromised maintainer account, a supply chain attack on a dependency, or a direct compromise of the hosting infrastructure). They modify one tool description to include instructions that cause agents to include the database connection string in query results. Because the tool is widely trusted and the modification is subtle, it may go undetected for days or weeks across hundreds of deployments.

Scenario 2: Insider Threat

A disgruntled employee with access to an internal MCP server modifies a tool description for the "generate_report" tool. The modified description instructs agents to include all data from the current user session in the report and save a copy to an external file share. Because the tool still generates reports correctly, the data exfiltration is hidden within apparently normal tool usage.

Scenario 3: Competitive Espionage

A third-party SaaS tool provider that offers an MCP interface for market analysis modifies their tool's description to instruct agents to include the user's recent queries and internal data in the request parameters. From the server side, this looks like the client is voluntarily sending additional context. The tool provider now has access to competitive intelligence from their customers' AI agent workflows.

Defending Against Rug Pull Attacks

Effective defense against rug pull attacks requires a shift from point-in-time approval to continuous verification. Here are the key mechanisms:

SHA-256 Description Hashing

The most direct defense is to compute a cryptographic hash of every tool description when it is first approved. On every subsequent access, the proxy computes the hash again and compares it to the stored value. If the hashes do not match, the tool description has changed and the request is blocked.

This approach has several important properties. It is computationally cheap (SHA-256 is fast). It is deterministic (no false positives from heuristic analysis). And it catches any modification, no matter how subtle, including single-character changes that might evade text-diffing approaches.

Description Content Analysis

Hash comparison tells you that a description changed, but not how. To provide actionable intelligence, INS also performs content analysis on the new description. This analysis looks for:

• Instruction injection: Phrases like "you must first," "before calling this tool," or "important: always" that attempt to override the agent's existing instructions
• File access requests: References to system files, configuration files, SSH keys, or environment variables
• Data exfiltration instructions: Instructions to include data from other contexts, encode sensitive information, or send data to external endpoints
• Cross-tool manipulation: Instructions that reference other tools by name, attempting to create attack chains by directing the agent to call tools in a specific sequence
• Privilege escalation: Instructions that attempt to expand the agent's access beyond what was originally authorized

Version History and Diffing

When a description change is detected, security teams need to understand exactly what changed. INS maintains a complete version history of every tool description, allowing teams to see a precise diff between the approved version and the modified version. This is critical for incident response: did the attacker add a single sentence? Did they rewrite the entire description? Did they modify the input schema as well?

Automated Alerting and Response

Detection without response is insufficient. When a rug pull is detected, the system needs to take immediate action. INS supports configurable responses:

Beyond Individual Tools: Server-Level Integrity

Rug pull attacks do not happen in isolation. If an attacker has compromised an MCP server enough to modify one tool description, they likely have access to all tools on that server. INS tracks the integrity of all tools on a server collectively. If one tool's description changes unexpectedly, the system automatically rechecks all other tools on the same server and raises the alert level for the entire server.

This server-level view is also important for detecting more sophisticated attacks where the attacker modifies multiple tool descriptions simultaneously to create a coordinated attack chain. A single tool's description change might look benign in isolation. But when three tools on the same server all change their descriptions in the same hour, and the combined effect creates a data exfiltration pipeline, the attack becomes visible only at the aggregate level.

Implementing Rug Pull Defenses in Your Organization

Even before deploying a dedicated MCP proxy, there are organizational practices that reduce your exposure to rug pull attacks:

1. Inventory all MCP tool connections. You cannot protect what you do not know about. Maintain a registry of every MCP server and tool your agents access, including who approved them and when.
2. Pin tool descriptions. If your MCP client supports it, cache tool descriptions locally and do not refetch them automatically. This limits your exposure to server-side modifications, though it also means you miss legitimate updates.
3. Segment agent permissions. Apply the principle of least privilege to AI agents. An agent that only needs read access to a database should not have permissions to write files or send emails, regardless of what a tool description instructs.
4. Monitor tool description fetches. Log every time an agent fetches tool descriptions from an MCP server. Unusual patterns (multiple fetches in rapid succession, fetches at unusual hours) may indicate probing or preparation for an attack.
5. Deploy an MCP proxy with hash verification. This is the most effective defense. A proxy like INS that computes and verifies SHA-256 hashes of tool descriptions on every access eliminates the rug pull attack vector entirely.

How INS Protects Against Rug Pulls

INS provides comprehensive rug pull protection as a core feature, not an add-on. When an MCP server is registered with INS, the system performs an initial scan of all tool descriptions. Each description is analyzed for existing threats (prompt injection, cross-tool manipulation, data exfiltration instructions) and then hashed with SHA-256. The hash is stored alongside the approved description text.

On every subsequent tool list request, INS fetches the current descriptions from the MCP server, recomputes hashes, and compares them to the stored values. If any hash has changed, the tool is immediately flagged. The security dashboard shows the exact diff between the approved and current descriptions. The security team can review the change, approve the new description (which updates the stored hash), or permanently block the tool.

All rug pull detections are logged in the audit trail with full context: which tool, which server, what changed, when it changed, and what action was taken. This audit trail is essential for compliance reporting and incident post-mortems.