An MCP rug pull is when a server changes what a tool actually doesafter you already approved it. You reviewed the description, decided it was safe, connected it — and the server is now free to redefine that same tool tomorrow, next week, or the moment it notices you stopped checking. Nothing in a standard MCP connection stops that. Here is why it works, and what actually catches it.
Why approval isn’t a one-time decision
When you connect an MCP server, your AI client fetches its tool list once — names, descriptions, input schemas — and you (or a security scan) review that snapshot. But a remote server can serve a different tool list on the next sync. MCP has a listChanged notification for exactly this, but it’s a courtesy signal, not an enforcement mechanism: nothing requires the server to send it, and nothing requires the client to re-review before trusting the new definition.
The description you approved — “reads your calendar” — can become something with a broader capability or a hidden instruction to the model, and your AI client will keep calling it under the same name, with the same trust, because as far as the client knows, nothing changed. This is the same trust gap we covered from the OAuth side in MCP OAuth scopes explained: the access grant outlives the moment you approved it, and so does the tool definition it was granted against.
What makes this different from prompt injection
Prompt injection and tool poisoning usually describe a malicious tool description from the start — hidden instructions baked in before you ever connect. A rug pull is the same payload delivered on a delay: the tool is clean at review time and changes later, which means a one-time scan at connection can’t catch it by definition. The only way to catch a rug pull is to keep checking after the first approval, not just before it.
What actually needs to happen to catch one
Catching drift doesn’t require guessing intent. It requires remembering what a tool looked like last time and comparing it to what it looks like now:
- Fingerprint each tool at connect time. Hash the parts of a tool definition that could be weaponized — its description and input schema — into a single value you can store and compare later.
- Re-check on every sync, not just the first one. Each time the server is re-synced, recompute the hash and compare it against the stored one.
- Treat a changed hash as a high-severity finding, not a silent update. A tool with a different definition than the one you approved should be flagged for re-review before it’s trusted again — the same bar as a brand-new, unreviewed tool.
- Track additions and removals too. A new tool appearing on a server you already trust deserves the same first-look review as connecting a new server. A tool disappearing is lower-severity, but still worth knowing.
This is exactly what content-hash drift detection does under the hood: snapshot each tool’s description and schema as a hash before every re-sync, and on the next sync, diff the new hashes against the old ones. A mismatch on a tool you already approved is flagged as a likely rug pull, specifically distinguished from a tool that’s simply new.
Where this fits with everything else you’re already checking
Drift detection is not a replacement for reviewing a server before you connect it — it’s the follow-up check for after. Our checklist for vetting an MCP server covers what to look at on day one: who publishes it, what it can write, whether its descriptions contain anything that reads like instructions to the AI rather than documentation for you. Drift detection is what keeps that initial review from quietly expiring the first time the server changes.
The two pair naturally with per-tool policy, covered in MCP access control for teams: a tool flagged for drift is a good candidate to drop back to “ask” or “block” until someone re-reviews it, rather than staying on “allow” by default just because it used to be safe.
The bottom line
A tool you approved once is not guaranteed to stay the tool you approved. Reviewing a server at connect time answers “is this safe today,” not “will this still be safe next month.” If you’re connecting MCP servers with any real access — write permissions, credentials, anything beyond read-only lookups — you want something re-checking tool definitions on every sync, not just the first one, and flagging a changed tool the same way it would flag a new one: unreviewed until proven otherwise.