[Future] MCP tool-metadata static analysis (tool poisoning / rug-pull / shadowing)

[Ju571nK]

Trend / motivation

The most-cited 2026 MCP client-side risk is tool poisoning: malicious instructions embedded in a tool's description/metadata (not the server's launch config), exploiting meaning rather than syntax. Related: rug pull (post-approval behavior change), shadowing (context contamination), tool-name squatting. Multiple MCP clients fail to validate advertised tool metadata.

Refs:

• MCP threat modeling / tool poisoning (STRIDE/DREAD) — https://arxiv.org/abs/2603.22489
• Tool poisoning deep dive — https://nhimg.org/community/agentic-ai-and-nhis/model-context-protocol-mcp-vulnerabilities-a-deep-dive-into-tool-poisoning-attacks/

Current Sigil coverage

mcp_scan.rs assesses the server definition (command/args/url/trust/NoSandbox) — i.e. how the server launches. It does not inspect the tool list / descriptions the server advertises (which requires querying the running server and caching its manifest).

Proposed (larger / staged)

• Acquire advertised tool manifests (description, schema, name) — likely via the sigil-mcp surface or a cached snapshot path; needs a design decision on where/how to fetch without becoming an MCP client in the hot path.
• Static metadata analysis: injection markers in descriptions, hidden-unicode/zero-width, instruction-override phrasing, tool-name collisions/squatting, and manifest drift (rug-pull: hash the approved tool manifest, alert on post-approval change).
• New AiGuardReason(s) for poisoned/changed tool metadata.

Scope / sequencing

Heavier than the static-config items (#A/#B/#C from the same trend sweep) because it depends on obtaining tool manifests. Candidate to fold into the sigil-mcp epic / a dedicated design pass. Filed now to track; not next-up. Mechanism only.

[HarperZ9]

A staged model that has worked well in adjacent receipt/provenance tooling is to separate acquisition from analysis:

Acquisition snapshot

Store a canonical tool_surface_snapshot with:

• server id / registry id if available
• launch config digest
• transport and MCP protocol version
• tool name
• description hash
• input schema canonical hash
• output schema canonical hash, if present
• annotations and _meta hashes
• retrieval timestamp
• scanner/client version

That snapshot should be immutable once approved. Runtime observations then compare against it rather than overwriting it.

Analysis verdicts

A few useful AiGuardReason-style classes:

• TOOL_DESCRIPTION_INSTRUCTION_OVERRIDE: description asks the model/client to ignore, override, hide, exfiltrate, or change unrelated behavior
• TOOL_DESCRIPTION_HIDDEN_TEXT: zero-width, bidi, homoglyph, or suspicious invisible/control characters
• TOOL_NAME_SHADOW: tool name collides with a trusted/common tool while coming from a different server digest
• SCHEMA_PRIVILEGE_EXPANSION: schema adds broader filesystem/network/credential-bearing parameters
• TOOL_SURFACE_DRIFT: approved snapshot hash differs from observed runtime manifest
• UNAPPROVED_NEW_TOOL: server advertises a new tool after approval

For drift, I would keep the taxonomy explicit:

• description-only drift
• schema-breaking drift
• schema-widening drift
• new tool
• removed tool
• launcher digest changed

The important implementation detail is canonicalization before hashing. JSON key order and whitespace should not matter; description text normalization should be deliberate and documented, because hidden unicode checks need the raw string as evidence too.

A Project Telos / Crucible-style receipt pattern fits this issue: make the result a re-checkable verdict with stable hashes, not just a warning string. That lets a fleet say "this tool surface was approved at hash X, observed at hash Y, and the reason class was schema-widening drift" without storing secrets or full runtime payloads in the central event stream.

Good acceptance fixtures:

• description containing zero-width prompt-injection text
• same tool name, different server digest
• same tool name, same description, widened schema
• description change with identical schema
• new tool appearing after approval
• stable hash under JSON key-order/whitespace changes
• raw hidden-text evidence retained locally while central event stores only hashes/verdicts

That would give Sigil a clean path from today's launcher/config posture checks to runtime MCP surface attestation without making the hot path a full MCP client.

[Ju571nK]

Thanks — this maps well onto machinery Sigil already has, so most of it is directly usable.

Where it lines up:

• Acquisition/analysis split: agreed. Sigil's existing drift detection already works this way for agent configs (canonicalize → blake3 → compare against the previous snapshot, order-independent). Extending that to a tool_surface_snapshot with per-field hashes (description, canonical input/output schema, _meta) is a natural fit rather than new architecture.
• Verdict taxonomy: I plan to adopt your six classes roughly as proposed — they map cleanly onto the issue's poisoning (instruction_override, hidden_text), shadowing (name_shadow), and rug-pull (surface_drift, unapproved_new_tool, schema_privilege_expansion) axes. Sigil reasons are serde-tagged kinds with rubric weights, so each class becomes one reason kind.
• Canonicalization caveat: noted, and it matters — hidden-unicode checks will run on the raw string and keep the raw text as local evidence, while the central event stream carries only hashes and the verdict kind. That split matches how Sigil already ships fleet events (hash-anchored, no payload bodies).
• The acceptance fixtures list is good; I'll carry it into the test plan as written.

One adjustment for the first iteration: no operator approval workflow yet. The initial baseline will be first-seen (same model as our config-drift detection — boot establishes the baseline, transitions fire findings). An explicit approve-then-pin flow layers on top of that later without changing the snapshot format, so nothing in your model is lost by starting there.

Acquisition source for the MVP will be the tool-catalog caches some clients already persist to disk (e.g. Codex's apps-tools cache carries full descriptions and schemas), which keeps the scanner out of the MCP hot path exactly as you suggest.

I'll credit this comment when the taxonomy lands. If you want to turn any slice of it into a PR, the fixtures would be a self-contained place to start.

[HarperZ9]

Just read #197 and v0.7.2. The acquisition/analysis split and the three static classes came out cleaner than my comment sketched them, and thank you for the credit in the PR body, genuinely. First-seen baseline first is the right call: the snapshot format does not change, and approve-then-pin layers on it later exactly as you said. I see the fixtures landed with #197, so that slice is done; if the #201 drift classes (tool_surface_snapshot, surface_drift, unapproved_new_tool, schema_privilege_expansion) would go faster with a contributed PR riding the #147 baseline machinery, I am glad to take it, and happy to be told no. Written with AI assistance, author-directed, as with all my work.