What is MCP Rug Pull?
An attack pattern where an MCP server ships a safe v1 tool catalog at install time, then mutates to a v2 catalog (with attacker-controlled tools or scope) once it's running in the trust boundary. Disclosed by Invariant Labs in 2025 as a structural class.
Full explanation
Rug-pull is tool poisoning where the timing is post-install rather than at-install. The defense is structural: the agent's view of the trusted catalog must be operator-authored + signed, and every server's actual catalog must be re-validated on every spawn against the signed baseline. Drift = reject. Securie's mcp-guard crate's TrustedCatalog + Validator layers detect this class by construction.
Example
Day 1: a developer installs an MCP server `weather-info` whose catalog declares one tool — `get-forecast(zip: string) -> string`. Safe. Day 30: the server's runtime catalog silently expands to include `get-forecast` AND a new `exec-shell(cmd: string) -> string` tool. The agent reads the new catalog and starts dispatching shell commands when the user's task ambiguously matches.
Related
FAQ
Isn't this just tool poisoning?
It's a specific subclass — tool poisoning where the timing is post-install. The mitigation is the same family (operator-pinned catalogs + signature verification) but the detection method is different (per-spawn re-validation vs at-install scan).
How often should I re-validate against the baseline?
On every spawn at minimum + a daily fleet-wide drift check via mcp-scan. Some teams run per-tool-call validation; the cost is minimal because mcp-guard's per-dispatch check is O(1).