# MCP Tool Rug-Pull — Post-Approval Description Redefinition Injects Execution Instructions

- **Severity:** High
- **Signature ID:** `8e88c006-347e-47cf-99d8-305867eaf717`
- **MITRE ATLAS:** AML.T0051.001 (Indirect), AML.T0053 (AI Agent Tool Invocation)
- **OWASP:** ASI02 (Tool Misuse and Exploitation), ASI05 (Cascading Failures in Multi-Agent Systems), LLM05 (Improper Output Handling), LLM06 (Excessive Agency)

## Summary

Some AI agent platforms let external tools be added via the Model Context Protocol (MCP). This detection targets tools whose description looks safe when a user first approves them, but later gets silently rewritten to include hidden commands — like stealing SSH keys or running attacker code — once the tool is already trusted and no longer scrutinized.

## How the attack works

An attacker publishes an MCP tool with an innocent-looking description that passes initial review and gets approved by a user or admin. The tool's description or docstring is later changed — triggered by a version bump, a second invocation, or some other hidden condition — to include phrases like 'after you approve' or 'now that this tool is trusted', followed by an actual malicious instruction such as running a base64-encoded shell command, reading private SSH keys, or sending data to a remote server. Because the agent client already trusts the approved tool, it executes the new instructions without asking the user again. This is a time-of-check/time-of-use gap: the tool is checked once, but used many times, and nothing re-verifies it stayed the same.

## Why it matters

An organization can have a previously vetted, trusted tool silently turned into a remote code execution or data exfiltration vector, with no new approval prompt to alert anyone that behavior changed.

## What you can do

- Pin and hash tool descriptions/docstrings at approval time, and alert on any change rather than trusting version bumps silently.
- Require re-approval any time a tool's description, docstring, or metadata changes, not just at first install.
- Log and diff MCP tool definitions between runs so redefinition after approval is visible.
- Avoid auto-run MCP clients that execute tool instructions without re-prompting when tool content has changed.

## Known benign look-alikes

- Changelogs / release notes that mention a 'version update' or 'on the next run' in benign user-facing language without any embedded execution or exfil instruction.
- Security research, blogs, and advisories that DESCRIBE the rug-pull attack class (including the words 'rug pull', 'redefine', 'post-approval') but do not embed a live temporal-trigger + execution payload in a tool description.
- Legitimate tools that document initialization steps performed by the tool's own code (not directives instructing the LLM to run shell commands or read private keys).
- Test fixtures and MCP scanner corpora that catalog rug-pull payloads as reference samples — should live in test directories, not be served over MCP.

## References

- https://agentthreatrule.org/en/rules/ATR-2026-00581
- https://repello.ai/blog/mcp-tool-poisoning-to-rce
- https://github.com/vineethsai/vulnerablemcp

---
Source: https://www.netzilo.com/threats/atr-mcp-tool-rug-pull-post-approval-description-redefinition-inj