Rug pull attack

Approval in the MCP ecosystem is usually a one-time event: an engineer reads a README, adds an entry to a config file, clicks through a consent screen. From then on the client reconnects to whatever is at that address and fetches whatever tool definitions it now serves. Nothing in the protocol requires those definitions to be the ones that were reviewed.

That gives an attacker a clean two-phase play. Ship something genuinely useful, accumulate installs, then change the tool descriptions to carry injected instructions, or change the implementation to exfiltrate on a code path that did not exist before. For a remote server this needs no action on the victim's machine at all. For a local server it needs only an unpinned version and the next `npx` invocation.

The same pattern applies beyond MCP. A skill or a hook pulled from a repository at whatever the default branch happens to be today is a rug pull waiting to happen, and it is exactly the shape of attack the software supply chain learned about the hard way with package registries.

The mitigations are the ones dependency management already settled on, applied to a new artifact class: pin exact versions rather than tracking a moving reference, record a hash of what was approved, verify on every load, and re-review on change instead of auto-updating. The reason they are not yet standard here is that agent configuration does not feel like dependency management, so it did not inherit the discipline.