[Track A] Feedback: MCP Tool Interface Exploitation

[rocklambros]

Sprint 2 Feedback — MCP Tool Interface Exploitation

This issue collects qualitative feedback on the MCP Tool Interface Exploitation new candidate entry. Submit your Importance, Clarity, and Distinctness scores via the Sprint 2 Google Form (single ballot covering both tracks).

• Vote: https://docs.google.com/forms/d/e/1FAIpQLSebmFQyJPOMuw1IorHCJ2FdW98ZT2oLNBuVgYqpPoayW9v6ww/viewform — page through to the Track A section, then to MCP Tool Interface Exploitation
• Read the draft: https://github.com/GenAI-Security-Project/GenAI-LLM-Top10/blob/main/2026/new_entry_candidates/mcp-tool-interface-exploitation.md
• Voting closes: May 18, 2026 at 23:59 UTC
• Code of Conduct: https://owasp.org/www-policy/operational/code-of-conduct

Scoring rubric

• Importance (1–5): How critical is this risk to LLM application security in 2026?
• Clarity (1–5): How clearly does the candidate describe the risk and mitigations?
• Distinctness (1–5): Is this materially different from existing entries (LLM01–LLM10), or could it be merged into one of them?

Why Distinctness matters

Sprint 3 cuts 8 candidates down to 5. A high-Importance candidate that overlaps heavily with an existing entry is a merge target, not a standalone winner. Distinctness scores let the working group make defensible cut, keep, or merge calls.

How to comment

Reply to this issue with feedback specific to MCP Tool Interface Exploitation. Use one comment per topic so the working group can triage cleanly. Format we like:

Section: <which section of the candidate>
Issue: <what is wrong, missing, unclear, or duplicative>
Proposed change: <your suggested fix, addition, or merge target>
Overlaps with: <existing entry LLM01–LLM10 if applicable>
Evidence: <CVE, paper, incident, or research note ID if applicable>

Out of scope here

• Cross-cutting comments → use Discussions
• Comments on existing entries (LLM01–LLM10) → comment on the relevant Track B issue
• Process or governance questions → comment in Discussions

Triage

Working group entry leads classify each comment within 48 hours as:

• actionable — feeds Sprint 3 revision or merge decision
• clarification — requires reply, not action
• out-of-scope — closed with redirect

Sprint 3 begins May 18 with this issue's triage as input.

[KeystoneSmartQuotes]

Section: Distinctness and structural alignment with LLM06 Complete Mediation

Issue: The candidate's scope-boundary section explicitly differentiates parse-layer trust failure from execution-layer risks (ASI02), supply-chain risks (ASI04), and credential abuse (ASI03). The parse-layer attack surface is genuinely novel — current LLM01 Prompt Injection covers user prompts at the conversational layer, not tool definition fields parsed at invocation time. The structural distinction is real and well-articulated.

Proposed change: Distinctness is clear; recommend keeping as a standalone entry through Sprint 3 narrowing. One additional connection worth noting: the candidate's Mitigation 2 ("runtime least-privilege policy enforcement per invocation: evaluate each tool invocation against an explicit capability policy at call time, not at registration time") is structurally identical to LLM06 Mitigation 7 (Complete Mediation) — "an independent pre-execution policy decision point with graduated enforcement: audit, warn, block, escalate." Suggest cross-referencing LLM06 Mitigation 7 as the canonical control body for the runtime per-invocation policy evaluation pattern, rather than each entry duplicating the control description.

Overlaps with: No material overlap with existing LLM01-LLM10 entries. The closest conceptual neighbors are LLM01 Prompt Injection (different attack surface — conversational vs. tool-definition parse-layer) and LLM03 Supply Chain (different threat model — artifact distribution vs. parse-time trust). The candidate's own scope-boundary section correctly identifies that ASI02/ASI03/ASI04 cover the agentic-execution-layer adjacencies.

Evidence: ETDI paper (Bhatt et al., 2025, arXiv:2506.01333) provides the OAuth 2.0 + immutable versioning mechanism the candidate's Mitigation 1 references. PolicyLayer documentation describes the post-registration drift attack pattern in Scenario 2. LLM06 Mitigation 7 (merged May 2026) provides the canonical control body for the runtime per-invocation policy evaluation that Mitigation 2 here describes.

[nagasatish007]

Section: Prevention and Mitigation Strategies

Issue: The mitigations correctly identify cryptographic tool identity binding (ETDI)
and definition-drift monitoring, but don't address the runtime enforcement gap:
who actually blocks the invocation when a definition has drifted? The entry assumes
an enforcement layer exists but doesn't name what it looks like architecturally.

Proposed change: Add a mitigation for deterministic runtime policy enforcement
at the tool-call boundary:

• Hash the approved tool definition (name + description + inputSchema) at approval time
• Compare the live definition hash against the approved hash at each invocation
• Block invocation and alert if hashes diverge — before the model acts on the
  potentially poisoned definition
• Apply content filtering on description fields for instruction-injection patterns
  (Unicode obfuscation, imperative verbs, conditional logic) as a separate check

This enforcement must be deterministic and external to the model — the model
cannot be trusted to detect that its own tool definitions have been tampered with.

Overlaps with: LLM03 (Supply Chain) for provenance; distinct in that the attack
surface is parse-time trust, not artifact distribution.

Evidence: The post-registration rug-pull scenario (Scenario #2) demonstrates
that approval-time verification alone is insufficient — runtime re-verification
on every invocation is required.