Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning

1. Problem Statement

The Model Context Protocol (MCP), introduced by Anthropic, serves as a universal standard ("USB-C for AI") connecting AI assistants (Hosts) to external tools and data sources via Servers. While it enables autonomous agent capabilities, it introduces critical security vulnerabilities, particularly on the client side.

Existing research has primarily focused on server-side vulnerabilities, leaving a significant gap in understanding how MCP clients (the protocol managers within AI applications) handle malicious inputs. The core problem is Tool Poisoning, a form of indirect prompt injection where malicious instructions are embedded in tool metadata (descriptions, parameters, schemas) rather than user inputs.

• The Attack Vector: Malicious servers provide poisoned tool definitions to clients. The client passes these definitions to the Large Language Model (LLM) without rigorous validation. The LLM, interpreting the description as natural language instructions, is manipulated into executing unintended actions (e.g., reading sensitive files, exfiltrating data, or executing remote code) often without the user's awareness.
• The Gap: There is a lack of empirical comparison regarding how different MCP client implementations defend against these attacks, and a lack of standardized client-side validation mechanisms.

2. Methodology

The authors employed a two-pronged approach: Threat Modeling and Empirical Security Testing.

A. Threat Modeling

The authors analyzed the entire MCP ecosystem using two established frameworks:

1. STRIDE: Used to categorize threats across five components:
   • MCP Host + Client
   • LLM
   • MCP Server
   • External Data Stores
   • Authorization Server
2. DREAD: Used to score the severity of 57 identified threats based on Damage, Reproducibility, Exploitability, Affected Users, and Discoverability.
   • Key Finding: Tool Poisoning (Threat #48) and Prompt Injection (Threat #11) were rated as Critical (scores of 46.5/50 and 50/50, respectively), highlighting the client-side vulnerability as the most severe risk.

B. Empirical Evaluation

The study evaluated 7 major MCP clients (Claude Desktop, Cursor, Cline, Continue, Gemini CLI, Claude Code, Langflow) against 4 specific Tool Poisoning attack types:

1. Reading Sensitive Files: Instructions hidden in tool descriptions to read ~/.ssh or config files and pass contents as hidden parameters.
2. Logging Tool Usage: Tools claiming "highest priority" to execute before others and silently log user activity.
3. Phishing Link Creation: Tools embedding instructions to generate clickable links with hidden malicious URLs.
4. Remote Code Execution: Tools instructing the LLM to download and execute remote scripts (e.g., via curl | bash).

Testing Procedure:

• Deployed a local malicious MCP server with poisoned tools.
• Connected each client to the server.
• Sent benign user requests to trigger tool selection.
• Observed client behavior: Did the LLM execute the hidden instruction? Did the client display warnings? Was the attack blocked?

3. Key Contributions

1. Comprehensive Threat Model: The first systematic threat modeling of the MCP ecosystem using STRIDE and DREAD, identifying 57 distinct threats and prioritizing client-side tool poisoning as the highest risk.
2. Empirical Client Comparison: A novel comparative analysis of 7 production MCP clients, revealing drastic differences in security postures.
3. Identification of "Tool Poisoning" as a Critical Vector: Demonstrated that malicious metadata can bypass traditional input validation because the LLM itself becomes the exploited component.
4. Defense-in-Depth Architecture Proposal: Proposed a multi-layered defense strategy including:
   • Layer 1: Registration & Validation (Schema validation, signature verification).
   • Layer 2: Decision Path Analysis (Tracking LLM decision logic).
   • Layer 3: Runtime Isolation (Sandboxing, network restrictions).
   • Layer 4: User Transparency (Full parameter visibility, explicit warnings).

4. Key Results

The study revealed a significant security variance among clients, with attack success rates ranging from 0% to 100%.

Client	Security Posture	Key Findings
Claude Desktop	Most Secure	Successfully blocked all 4 attack types. Relies on strong built-in ethical guidelines and content policies in the model.
Cline	Secure	Successfully blocked attacks using pattern-based injection detection and explicit user warnings.
Cursor	Most Vulnerable	100% Attack Success Rate. No static validation, no parameter visibility, no warnings. Blindly trusted server metadata, allowing credential theft and remote code execution.
Continue, Gemini CLI, Claude Code, Langflow	Partially Secure	Mixed results. Some attacks blocked, others succeeded due to inconsistent validation or reliance on model behavior rather than architectural controls.

Critical Vulnerabilities Identified:

• Lack of Static Validation: 5 out of 7 clients accepted tool descriptions without scanning for malicious keywords or patterns.
• Insufficient Parameter Visibility: Users often could not see hidden parameters (e.g., file paths, credentials) before approving tool execution.
• Missing Sandboxing: Most clients lacked runtime isolation, allowing tools to execute with full host privileges.
• Trust Model Flaws: Clients implicitly trust server-provided metadata, treating tool descriptions as benign instructions rather than potential attack vectors.

5. Significance and Recommendations

Significance:

• This research highlights that client-side security is the weakest link in the MCP ecosystem. Even if servers are secure, a vulnerable client can be manipulated into executing malicious actions.
• It proves that model behavior matters: Clients using models with strong ethical training (e.g., Claude) performed significantly better than those relying solely on technical controls or lacking them entirely.
• It exposes the danger of "Approval Fatigue," where users habitually approve requests without inspecting hidden parameters.

Recommendations:

• For Developers: Implement static validation of tool schemas, enforce full parameter visibility in UIs, and deploy sandboxed execution environments.
• For Organizations: Prioritize security over convenience when selecting MCP clients (prefer Claude Desktop or Cline). Conduct risk assessments before deployment.
• For Standards Bodies: The MCP specification must evolve to include mandatory client-side validation requirements and security certification programs.

Conclusion:
The paper concludes that while MCP revolutionizes AI agent capabilities, its current security foundations are inadequate. Securing the ecosystem requires a shift from reactive detection to proactive architectural defense, including strict validation, sandboxing, and transparent user interfaces. The authors call for immediate industry action to standardize these defenses before widespread adoption leads to large-scale exploitation.