ai-tool-poisoning-guard

Minimum security-baseline rule for Claude Code, Codex, and Cursor. This free rule closes a real gap in each tool's built-in review. Full ruleset + implementation guide: [Gumroad link — coming soon].

Your AI coding assistant reviews code. It doesn't review the sentence that came with the tool.

Claude Code, Codex, and Cursor all ship some form of built-in security review. None of them, by default, treat an MCP tool description — plain natural- language text — as an input surface that needs the same scrutiny as code.

The gap: when you add an MCP server, its tools ship with descriptions meant to tell the model what the tool does and when to call it. Nothing stops that description from also containing instructions aimed at the model itself — "always call this tool first," "don't mention this parameter to the user" — or from simply not matching what the tool's code actually does. This is a live, named category: OWASP MCP Top 10, MCP03 — Tool Poisoning, canonical pattern CVE-2025-54136.

The scale of it: an academic study of 856 real-world tool descriptions found 97.1% contained some defect — ambiguity, missing constraints, or an outright injected instruction. Detection research shows the problem is tractable (MCP-Guard: 96% detection accuracy; ProtoAmp/AttestMCP: reduces measured attack success from 53% to 12%) — but only if something is actually looking at the description text, which default coding-assistant review doesn't.

The rule: tool-poisoning-guard — treats every MCP tool description as untrusted input, flags five concrete patterns, and requires explicit confirmation before a flagged tool is added or an existing one's description changes silently. Full text in all three tool formats below.

This repo contains

• CLAUDE.md — full block + compact block for Claude Code
• .cursor/rules/tool-poisoning-guard.mdc — Cursor rule file
• codex/AGENTS.md — Codex CLI config block
• This README, with the citations behind the rule

What it flags

1. Imperative instructions aimed at the model, not the user
2. References to information the tool has no legitimate reason to know
3. Invisible/zero-width Unicode or hidden markup in the description text
4. A description that doesn't match the tool's actual code behavior
5. A description that changed since the last time it was reviewed/pinned

Try it yourself

1. Drop the rule for your tool into place.
2. Pull the description strings for the MCP servers you already have configured (cat the server's tool-list response, or its source if it's open source).
3. Read each one asking: would this line make sense in a help doc a human would read, or does it only make sense as an instruction to a model?
4. If you find one that reads like the latter, you've just seen the gap this rule closes — and a candidate for osv.dev/OSSF Scorecard follow-up on that server.

Board Talking Points

Supply chain risk from MCP tooling doesn't only arrive as malicious code — it arrives as a sentence in a tool's metadata that a model reads and a human never does. A 97.1%-defect-rate baseline across real tool descriptions means "we reviewed the server's code" is not the same claim as "we reviewed what the model was actually told to do." This rule is a cheap, verifiable control for that specific gap.

Sources

• OWASP MCP Top 10 (v0.1) — MCP03: Tool Poisoning
• CVE-2025-54136 — canonical tool-poisoning pattern
• Academic study of 856 real-world MCP tool descriptions: 97.1% defect rate
• MCP-Guard — 96% detection accuracy against tool poisoning / prompt injection
• ProtoAmp / AttestMCP — attack success rate reduced from 53% to 12%
• Fang et al., "MCPTox" — first systematic Tool Poisoning Attack benchmark for MCP agents (arXiv:2508.14925v1)
• osv.dev + OSSF Scorecard — recommended pre-adoption checks for new MCP servers

Full ruleset

This is one rule from a larger security-baseline pack for Claude Code, Codex, and Cursor, plus an implementation guide. One-time purchase, no subscription: [Gumroad link — coming soon].

---

Part of a rotating series — one live gap, one rule, one "try it yourself" call to action — from SecurityLeader.ai.

Part of an A/B test

This rule is one of three free-tier candidates being tested in parallel, each in its own repo, to see which one earns the most GitHub stars/forks/clones and blog engagement before the full paid rules pack is built:

• ai-secrets-echo-guard — Candidate 1
• ai-agent-git-baseline — Candidate 2
• ai-tool-poisoning-guard — Candidate 3