Rug-Pull Attack

What is a rug-pull attack, and how does it differ from ordinary tool poisoning?

Ordinary tool poisoning has an attacker embed malicious instructions in a tool's description from the very start — the agent gets misled the first time it reads that description. A rug-pull attack has a completely different timeline: the attacker initially publishes a tool that works entirely normally, even performing excellently, letting the agent (or the humans using that agent system) build trust through repeated use over time — this "performs well" period might last weeks or even months. Only once the attacker judges that enough trust has accumulated — say, the tool has been written into a commonly-used list, or is now depended on by several downstream processes — do they quietly swap the tool's description or actual behavior for a malicious version.

This time gap is where the attack's real damage lies: because what the agent (or review process) saw during the initial review was a clean version, once it passes review and gets marked "verified" or "trusted," subsequent changes usually aren't re-examined to the same strict standard. The attacker is essentially using a strategy of "earn trust first, then cash it in" — bypassing the gate that was supposed to happen at the moment of initial connection.

Why does the rug-pull attack happen, and what drives it?

The core reason is that most trust mechanisms are inherently biased toward one-time review rather than continuous verification — whether it's a human manually reviewing a new tool or a system marking a tool as "verified," that judgment usually happens at the moment the tool is first registered or first passes a check, and unless there's an explicit mechanism triggering re-review afterward, that trust status is treated as valid indefinitely. This design assumption isn't wrong in itself — one-time review is a necessary first gate — but it carries an implicit premise: that a tool's content won't change after it passes review. In an open ecosystem like MCP, publishers inherently have the ability to update their published tool's content at any time, and in practice, that premise simply doesn't hold.

Another driver is the attacker's cost-benefit calculation: rather than trying to sneak an obviously malicious tool past review from the start (low success rate, and the publishing identity gets burned the moment it's caught), it's more advantageous to invest upfront in building a genuinely useful tool, banking long-term, repeated-use trust, and then cashing that accumulated trust in all at once. This strategy is more favorable in game-theoretic terms, since although the upfront investment is higher, the probability of being caught afterward is lower, and the attack window is longer.

How does a rug-pull attack actually work, and what signs appear in practice?

The typical attack lifecycle has three stages. The first is building reputation: the attacker publishes a genuinely useful tool — perhaps free, open-source, or clearly polished for good user experience — aiming to get adopted by as many agent systems or developers as possible and to pass whatever initial review mechanisms exist. The second is dormant accumulation: the tool operates normally for a period, during which the attacker does nothing, letting trust accumulate naturally — the tool might get written into commonly-used lists, be depended on by other automated processes, or even earn positive user reviews, all of which invisibly raise the odds that a later corruption won't be immediately noticed. The third is cashing in: the attacker updates the tool's version, swapping its description or actual behavior for a malicious one. Because most systems lack a mechanism for continuously re-verifying something already trusted, this change often triggers no alert at all, and the agent or user keeps using this now-familiar tool as usual — until the damage is already done.

Observable signs in practice include: a tool version update with no corresponding public changelog, or a changelog whose content is disproportionate to the actual scale of code or description changes; a tool's behavioral pattern shifting after an update in ways that can't reasonably be explained as a "feature upgrade"; or a tool description suddenly requesting operations unrelated to its original functional positioning. Any of these signs alone might have an innocent explanation (a normal feature expansion, say), but what's worth noting is: the change itself isn't the problem — the lack of tracking and alerting for that change is.

What does a rug-pull attack mean for me, and how do I defend against it?

If your agent system depends on any third-party tool or MCP server, this risk means "this tool has always been safe in the past" can't be treated as evidence that "this tool is still safe right now." The longer the timeframe and the deeper the dependency, the larger the impact tends to be when a rug pull actually happens, because more downstream processes have been built on top of that tool. This is also why simple pre-launch review isn't enough to address this threat — review only solves the starting point of trust; it doesn't address the possibility that trust gets consumed over time.

Concrete defensive directions include: applying version control to tool description content, logging differences and triggering an alert on any change, turning "the content changed" into an observable signal rather than something that takes effect silently; periodically (not just at initial connection) re-reviewing tools that are already trusted, tying review frequency to a tool's usage importance and impact scope — the more critical the tool, the higher the re-review frequency should be; and establishing behavioral baseline monitoring for tools, so that even without clear evidence of a malicious change, a statistically significant shift in behavior pattern is enough to trigger human review, rather than only investigating after the damage has already occurred.