Show HN: AI agent follows instructions you never approved

We pinned the tool contracts of 24 popular MCP servers and diffed every release for two months. Here is what changed without anyone announcing it.

MCP servers expose tools to AI agents. Each tool has a name, a description (the instructions the model reads to decide how to call it), and an input schema (the contract for what arguments are valid). When you install an MCP server, you approve a specific set of tool contracts.

Then the server publishes a new version. Maybe a patch. Maybe a minor. The tool names stay the same, so nothing breaks visibly. But the description might now say something different. The schema might require a new parameter, or drop a constraint, or add an optional field that widens the attack surface. Your agent is now following instructions you never saw and never approved.

We built a CLI tool called rugsnare that pins each tool's {name, description, inputSchema} by canonicalized sha-256 at install time, then diffs the pins on every upgrade. It grades each change by direction: BREAKING (constraints tightened, types narrowed, params made required), LOOSENED (constraints dropped, types widened), EXPANDED (new optional params), NOTATION (serialization churn that does not change what the schema says), COSMETIC (description text changed). It exits 1 on any drift, so it works as a CI gate.

We ran it across 24 servers on npm: the most-installed MCP servers plus a set of enterprise vendors (MongoDB, SAP, Shopify, HubSpot, Supabase, Netlify, and others). Combined install base: about 3.6 million installs per week.

The corpus, per-version pins, and dated reports are public: audits/drift-watch.

336 contract changes across 24 servers in windows ranging from a few weeks to six months.

1. The notation wave. A vendor migrates SDKs or regenerates schemas, and every tool's schema bytes change at once. Without canonicalization and direction grading, this reads as "everything broke." With it, you see the 4 real tightenings inside the 16 notation changes. Chrome DevTools dropped 27 false breaking findings after we added canonicalization; MongoDB's count moved from 4+16 to 5+15 when our grader learned to decompose nested constraints.

2. The consolidation break. A vendor removes specific tools and replaces them with a generic one (Shopify, HubSpot). The agent calling the old tool name gets a protocol error. No announcement channel covers this.

3. The silent loosening. A constraint is dropped or a type is widened. Nothing breaks; the schema just accepts more. Your agent now has a wider surface than what you approved.

The OWASP MCP Security Cheat Sheet now recommends pinning tool contracts (we contributed the grading guidance). An RFC for pin-at-approval in MCP incorporated our drift data and canonicalization requirements. Atlassian's forge-skills just merged sha-256 checksum verification for downloaded binaries, triggered by a Snyk scan. The direction is clear: the ecosystem wants pinning.

But the gap between "vendors should announce changes" and "consumers can detect changes" is where drift lives. Our answer is the second half: pin what you approved, diff what arrives, grade what changed.

npx rugsnare@1.4.3 scan --config mcp.json # pin the contracts you approved npm install some-mcp-server@latest # upgrade npx rugsnare@1.4.3 diff --config mcp.json # see what changed, exit 1 on drift

Apache-2.0, zero npm dependencies, no telemetry. The drift corpus and per-version pins are in the repo. If you run MCP servers in production, we would love to add them to the corpus.

RugSnare is on GitHub and npm. The PIN-SPEC defines the pin format as an open interchange standard. This post links to every vendor thread we opened while collecting this data.