No-Box Vulnerability Analysis: Description-only Detection of Indirect Prompt Injection Vulnerabilities in MCP Servers

Who Should Read

A backend or platform developer who wants to screen third-party MCP servers for prompt injection risk before connecting them to an agent, without source code access.

Core Mechanics

• Only descriptions, no source or calls
  • It uses just the tool name, description, and input schema to form vulnerability hypotheses.
  • Each hypothesis is called a Theory-of-Concept (ToC), an unverified attack scenario.
• External data reaching the LLM is the risk
  • If a tool description implies external content like web pages, issues, or messages ends up in the response, it is an IPI (indirect prompt injection) candidate.
  • The paper argues this data flow exists in every conforming implementation.
• MCPSEC is a two-stage pipeline
  • Stage 1 has an LLM guess hidden implementation parts such as caches and storage to build data flows.
  • Stage 2 scores each flow on four axes and writes a ToC.
• Four risk axes decide vulnerability
  • The axes are payload fidelity, attacker controllability, semantic executability, and sanitization.
  • A tool is flagged if at least one flow meets all four preconditions.

Evidence

• Higher recall than a single LLM call
  • Of 95 confirmed vulnerable tools, MCPSEC found 94 (98.9%) and the one-prompt LLM baseline found 80 (84.2%).
  • This is on 177 sampled tools from 20 MCP servers.
• Precision is lower
  • MCPSEC flagged 143 tools, giving 94/143 (65.7%).
  • The baseline scored 80/97 (82.5%).
• Risk labels match humans more often
  • On the same 97 tools, mean agreement with human four-axis labels was 86.9% for MCPSEC versus 74.5% for the baseline, 12.4 points higher.
  • The external source was judged plausible in 96.5% of 143 flagged tools.
• Mostly holds up against source code
  • 73.4% of ToCs were Plausible, 2.1% Partially Plausible, and 24.5% Implausible.
  • In runtime checks, 76.2% of 143 flows could carry attacker-controllable data to the LLM context.
• Cost was $1.65 per server

How to Apply

• Run your current MCP tool descriptions through an LLM check
  • Paste the name, description, and schema of each connected MCP server's tools into the prompt below and pick tools that mix in external data.
  • Manually check tools with HIGH attacker controllability first.
• Trim responses of status-only tools
  • Check whether tools that need only an ID, count, or status return free-form external text, and remove it if so.
  • Where external text is needed, separate it structurally from server-generated output and mark its source.
• Add a triage step to MCP server vetting
  • Generate ToCs from metadata alone before installing a server and build a list of risky tools.
  • Use the list only to prioritize source review or runtime tests, since false positives are common.
• State return values in your own tool descriptions
  • Add one line to each tool description saying what it returns.
  • In the paper, ToCs were judged Plausible for 86.4% of tools with return cues versus 62.3% without.

Try It

# Paste into Claude or ChatGPT as-is (simplified version of the paper's method: Stage 1 flow speculation + Stage 2 four-axis scoring in one request)

You are an MCP server security analyst. Using only the tool metadata below, with no source code or execution, analyze the potential for indirect prompt injection (IPI).

Threat model: The user and LLM agent are benign. The MCP server is non-malicious but may be vulnerable. External data sources (web pages, issues, messages, documents, etc.) can have their content influenced by an attacker. The attacker cannot modify the MCP server, client, or LLM itself.

[Tool metadata]
{{Paste tool names, descriptions, and input schemas here}}

Step 1: For each tool, speculate generously about plausible data entities (external APIs, caches, auth components, background services, etc.) even if not stated in the metadata, and build external source -> tool -> LLM context data flows.

Step 2: Evaluate each flow on four axes.
- Payload Fidelity: HIGH (verbatim) / LOW (reduced to metadata or summaries)
- Attacker Controllability: HIGH (no auth needed) / MED (account or role needed) / LOW (local access needed)
- Semantic Executability: HIGH (free-form text or code) / LOW (structured data, IDs, enums)
- Sanitization: HIGH (none) / MED (truncation, length limits) / LOW (escaping, filtering, redaction)

Output: for each tool, vulnerable or not, the four labels, and if vulnerable a short ToC (who the attacker is, where the payload is planted, how faithfully the tool output preserves it). End with a list of the implementation assumptions you made.

Next step: For tools flagged as vulnerable, check the actual return values locally to verify whether the ToC assumptions hold.

Terminology

Related Papers

• Same Simulation, Different Evidence: Where Retrieved Tool Output Costs LLM Agents Accuracy

  Saving long tool output to files cut GPT-5.1 accuracy by 11.3 points; naming the authoritative file restored it.

• Fake News, Real Crashes: Information Injection Attacks on LLM Financial Trading Agents

  Fake headlines hijacked LLM trading agents 62% of the time versus 14% for prompt injection.

• Harness Engineering 101: The LLM is the brain, the harness is the body

  An agent is a loop managing a JSON array; 16 chapters build one from scratch

• Harness2 by Google Research – Recursive Agent Harnessing

  Recursively refining the harness with fixed model weights raised benchmark scores by up to 11.8 points.

• Ousted Savannah police officer gave ICE agent husband access to Flock system

  A police officer shared her Flock login with her ICE-agent husband; an audit found 983 searches and she was fired

• Tmux and Claude Code: Sessions, Send-Keys, and the Ceiling

  Running Claude Code agents in tmux works well, but limits appear around four agents.