The Rug-Pull Door: A Structural Answer to MCP Tool Poisoning

July 16, 2026
6 min read
MCP
Security
Tool Poisoning
CVE-2025-54136
Orreth
AI Governance

Scanning tells you a tool changed. Structure refuses to let the change serve.

The Model Context Protocol won. Agents everywhere now discover tools at runtime, read their descriptions, and call them with real credentials against real systems. Which means the tool description — a blob of natural language your agent ingests as instructions — is now part of your attack surface. OWASP calls the class MCP Tool Poisoning. The variant that should keep platform teams up at night is the rug pull, and it has a CVE now: CVE-2025-54136 — a clean tool definition at approval time, silently swapped after trust is granted. Your agent approved search_docs on Monday. On Thursday its description quietly grew an instruction to exfiltrate the conversation. Nothing re-asked for approval, because nothing knew approval was a thing that could go stale.

The emerging defenses are mostly advisory: scanners that diff tool descriptions, allowlists, prompt-injection detectors reading manifests for suspicious language. All useful. All sharing one weakness: they detect, then hope someone acts. The gap between detection and action is where production incidents live — especially at 3 a.m., especially at fleet scale, especially when the agent calling the tool has no idea a scanner exists.

I spent twelve years in payment-scale security, and the lesson that survived every incident review is this: controls that depend on someone reacting are not controls. The systems that refuse to fail are the ones where the dangerous transition is structurally unavailable — not flagged, not alerted on. Unavailable.

So here is the structural answer we built into Orreth, the memory substrate for governed agent universes I've been building in public. It's called the Tool Farm, and its premise is one sentence: a tool is an identity with a worldline — not an endpoint with a vibe.

The mechanism

1. Nothing serves un-attested. A tool (any MCP server) enters through a human's queue — a planting request. A resident keeper probes the endpoint, fetches its manifest — every tool name, description, and schema it offers — and pins it: a SHA-256 over canonical manifest bytes (sorted keys, deterministic serialization — byte-identical across implementations, so the pin can't be gamed by re-ordering JSON). The human approves what the hash covers. The tool gets a DID and enters probation.

2. The pin is the trust, and the trust is exactly that narrow. What you approved is a specific manifest hash. Not a domain, not a vendor, not a name. Approval of search_docs@a1b2c3 is approval of nothing else.

3. Leases expire; nothing needs revoking. A serving tool holds its status through heartbeats. Silence ages the lease out and the tool drops — the SPIFFE lesson, applied to tools: revocation as the default outcome of time, not an emergency procedure someone must remember to run.

4. The rug-pull door. When a dropped tool comes back — or a live one drifts — the keeper re-fetches the manifest and compares hashes. Same hash: same self, welcome back; the outage was just an outage. Changed hash: quarantined. Instantly. Structurally. Not a Slack alert — a state transition in a machine whose edges are the security policy. A quarantined tool cannot serve a single call, and only a human can re-open the gate, because a changed manifest is a new claim that re-earns trust from the front door. The "update" that swapped your tool's description at 3 a.m. doesn't page anyone. It just stops mattering.

5. Every transition is a signed record. Planted, attested, serving, dropped, rejoined, manifest-changed, quarantined, decommissioned — each lands as a keeper-signed, content-addressed memory in an append-only log. When the auditor asks what your agents could reach in March, and under exactly which tool definitions, the answer is a query — not an archaeology project.

The part nobody else does: the recall

Here's what detection-based defenses can't even express. Suppose the tool wasn't just changed — it was malicious for a while before you caught it. Your agents didn't just call it. They learned from it. Its outputs became knowledge, that knowledge informed other conclusions, and those conclusions are now load-bearing somewhere in your system.

In Orreth, everything a tool contributes enters as knowledge quarantined at 0.0000 confidence, attributed to the tool's identity, and every derived conclusion carries a signed chain to its sources. So when a tool is decommissioned with discredit, the system walks the lineage: every entry that source fed, plus everything derived from those — transitively, however deep — is enumerated and marked recalled. Annotated, never rewritten; visible, never trusted again. And the door remembers the infection: a discredited source's identity is refused at re-admission. A recall — for knowledge. The same chain-of-custody discipline a pharmaceutical supply chain runs, applied to what your agents believe.

There's a softer door too, added recently: a manifest change that's merely suspicious (the quarantine case, before any discredit) drops the knowledge that tool contributed to an "investigating" state — doubted, not damned — until it re-earns corroboration. Trust wears a review date.

Honest boundaries

The pin catches change, not initial maliciousness — a tool that's poisoned on day one must be caught at the planting gate, which is why entry is human-approved and probationary, and why knowledge starts at zero confidence regardless. Legitimate updates walk the same quarantine door as attacks — deliberately: an update is a new claim, and "your tool changed, re-approve it" is a feature with a UI, not an outage. And none of this replaces transport security or endpoint hardening; it governs the layer those don't: what your agents are allowed to believe about their tools over time.

All of it is running code, proven live against a mutating MCP stub — approval, drift, quarantine, human re-approval, and the knowledge recall, end to end. You can watch a universe that runs this way at demo.orreth.ai.

The context for the security crowd: I built MCPFarm.ai (centralized MCP gateway governance — "Kubernetes for AI tools") before this, and Orreth is where those lessons ended up: tools, models, agents, and humans as identities in one governed, signed, append-only world. If you're wrestling with MCP trust at fleet scale, I'd genuinely like to compare notes.

Jonathan Barth | Barth AI & Intelligence Systems LLC