Rug pull: what happens when a tool changes after being approved

Introduction

A rug pull in the context of MCP tools is a change after the initial approval that modifies what the server presents or does. The expression describes a risk scenario; it is not a normative category of the protocol.

What can change

The description the model consumes, the accepted parameters, the accessible resources or the implementation’s behavior can all change. In some systems, a tool updates automatically or the server changes without a review equivalent to the initial one. If the client does not detect or communicate the change, the earlier approval may turn out to be too broad.

Invariant Labs’ research described this class of change as part of its tool poisoning experiments. Those findings should be presented as research, not as a claim that every implementation allows silent changes.

Lifecycle controls

Keep an approved inventory that links server, version, owner, tools and permissions. Pin versions or artifacts when feasible and review changes to description, schema and dependencies before putting them into production. Keep a verifiable integrity reference and raise an alert when the server or its capabilities change.

Tie approval to the reviewed version, not only to the tool’s name. When a relevant change occurs, pause sensitive calls until the review is complete. Have credential revocation, server deactivation and investigation of recent calls ready. Record the changes needed to respond to incidents, avoiding storing secrets or unnecessary personal content.

Conclusion

An initial approval is one point in the lifecycle, not a permanent guarantee. Inventory, version control, change review and the ability to revoke reduce the risk of an integration evolving beyond what was expected.