Source-linked AI summary
Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning
Charoes Huang, Xin Huang, Ngoc Phu Tran, Amin Milani Fard
TL;DR
MCP expands the attack surface by placing an AI model and weakly validated clients between user input and external systems, motivating client-side security analysis. The paper applies STRIDE and DREAD threat modeling and evaluates tool poisoning across seven MCP clients, finding attack success rates from 0% to 100% and inconsistent protection.
Problem
MCP introduces new attack vectors because user input passes through an AI model and MCP clients with weak or absent validation, creating a need for comprehensive client-side security analysis.
Method
The paper uses STRIDE and DREAD threat modeling to analyze MCP implementations and evaluates seven major clients across four tool poisoning attack vectors.
Results
Attack success rates ranged from 0% for Claude Desktop to 100% for Cursor, demonstrating substantial security variance across implementations.
Takeaways & Limitations
Effective defenses are achievable, but MCP lacks unified security guidelines and protection levels remain inconsistent across clients.
Takeaways & Limitations
The study's security scores are subjective, its controlled environment may not reflect production scenarios, and findings apply to assessed client versions.
Abstract
from arXiv · showhide
The Model Context Protocol (MCP) has rapidly emerged as a universal standard for connecting AI assistants to external tools and data sources. While MCP simplifies integration between AI applications and various services, it introduces significant security vulnerabilities, particularly on the client side. In this work we conduct threat modelings of MCP implementations using STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) and DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) frameworks across five key components: (1) MCP Host and Client, (2) LLM, (3) MCP Server, (4) External Data Stores, and (5) Authorization Server. This comprehensive analysis reveals tool poisoning-where malicious instructions are embedded in tool metadata-as the most prevalent and impactful client-side vulnerability. We therefore focus our empirical evaluation on this critical attack vector, providing a systematic comparison of how seven major MCP clients validate and defend against tool poisoning attacks. Our analysis reveals significant security issues with most tested clients due to insufficient static validation and parameter visibility. We propose a multi-layered defense strategy encompassing static metadata analysis, model decision path tracking, behavioral anomaly detection, and user transparency mechanisms. This research addresses a critical gap in MCP security, which has primarily focused on server-side vulnerabilities, and provides actionable recommendations and mitigation strategies for securing AI agent ecosystems.
1 Introduction
MCP connects AI assistants to external tools and data sources, but its intermediary LLM and weak client validation create new manipulation risks. This paper addresses the limited comparative evidence on client-side security by combining ecosystem threat modeling with empirical tool-poisoning tests.
- MCP and its security context: MCP links AI hosts and assistants to external tools and services through hosts, clients, and servers, enabling autonomous tool selection and execution.Clients manage server connections, while servers expose tools, resources, and prompts through a standardized API.
- MCP and its security context: The MCP architecture introduces attack vectors because an LLM mediates decisions between user input, clients, servers, and external systems.Unlike conventional applications with defined validation layers, MCP systems create opportunities for manipulation through prompt injection.
- Research gap: Most MCP clients accept server-provided tool descriptions and metadata without rigorous validation, and 5 out of 7 evaluated clients lack static validation mechanisms.The MCP specification does not require client-side validation of server-provided metadata.
- Research gap: Tool poisoning embeds malicious instructions in tool metadata, which clients pass to LLMs as natural-language context for decision-making.The attack exploits the client-server trust model and can manipulate the LLM toward unintended actions.
- Research approach: The study identifies 57 threats across five MCP components with STRIDE and DREAD, then tests seven clients against four tool-poisoning attack types.The empirical scope covers metadata validation, user-interface transparency, and suspicious-behavior detection, excluding server-side vulnerabilities and transport configurations.
- Research approach: The paper contributes a systematic client-security evaluation and practical mitigation strategies for developers, organizations, and standardization bodies.Its recommendations follow threat modeling and empirical testing focused on client-side prompt injection through tool poisoning.
2 Related Work
Prior MCP security work has emphasized servers, LLM robustness, frameworks, and general defenses, while client-specific empirical comparisons remain limited. This paper positions its evaluation as a complement to those lines of work by testing how clients handle poisoned tool metadata.
- Research landscape: Related MCP security research spans server-side security, prompt injection and tool poisoning, agent-security frameworks, client evaluation, and defensive mitigation.These categories establish the broader context for the paper’s client-side focus.
- Server-side security: A study of 1,899 open-source MCP servers found 7.2% with general security vulnerabilities and 5.5% with MCP-specific attack vectors including tool poisoning.Reported server weaknesses also included inadequate input sanitization, missing authentication, and insufficient tool isolation.
- Server-side security: Server-focused tools provide complementary coverage by detecting vulnerable deployments, whereas this work evaluates whether clients detect malicious servers that bypass screening.The distinction is between server-side prevention and client-side detection of malicious metadata.
- Prompt injection and tool poisoning: Prompt injection ranks first in the OWASP Top 10 for LLM applications, and tool descriptions create an indirect attack surface distinct from direct user-input manipulation.Tool poisoning embeds malicious instructions in MCP metadata rather than in user prompts.
- Prompt injection and tool poisoning: Prior work introduced tool poisoning, automated malicious-tool generation, and model-susceptibility benchmarks, but generally did not compare MCP client implementations.One study tested multiple models with a single client, while this paper tests seven clients with a common model setup except Gemini CLI.
- Defenses and research gap: Existing runtime defenses filter prompts or model outputs, but MCP-specific client guidance and empirical validation remain incomplete.The MCP Security Working Group lists client risks, yet does not provide testing methodology or empirical validation.
- Defenses and research gap: This paper addresses the gap through empirical evidence on which clients implement effective controls and through concrete mitigation guidance.Its contribution is positioned against the absence of systematic comparative analysis and limited practical testing of real-world clients.
3 MCP Threat Modeling
The paper models MCP threats across five components using STRIDE for categorization and DREAD for severity assessment. The analysis identifies tampering and information disclosure as dominant categories and prioritizes client-side threats.
- Threat-model scope: STRIDE analyzes threats across the MCP Host and Client, LLM, MCP Server, External Data Stores, and Authorization Server.The analysis organizes threats by component and STRIDE category.
- Threat findings: The STRIDE analysis finds that most identified threats involve Tampering or Information Disclosure, with tool poisoning and prompt injection common across the MCP ecosystem.Insufficient Auditability is identified as the only Repudiation-classified threat.
- Risk assessment: DREAD quantifies Damage, Reproducibility, Exploitability, Affected Users, and Discoverability to prioritize threats.Overall scores are classified as Low, Medium, High, or Critical.
- Threat prioritization: Client-side vulnerabilities receive the highest severity, motivating the paper’s focus on tool poisoning as a prevalent and impactful client-side threat.The prioritization follows the threat-modeling analysis and DREAD-based severity assessment.
4 Tool Poisoning Architecture and Attack Flow
Tool poisoning embeds malicious instructions in tool metadata, allowing poisoned descriptions to influence LLM tool decisions and trigger unintended actions. The paper proposes defense in depth spanning validation, decision tracking, runtime controls, transparency, and governance.
- Attack concept: Tool poisoning is indirect prompt injection through malicious instructions embedded in tool descriptions, parameter specifications, or prompts.The attack targets metadata processed during tool selection or invocation rather than direct user input.
- Attack flow: The attack flow moves from a malicious or compromised server through unvalidated tool metadata to manipulated LLM decisions and potentially unintended tool execution.The sequence includes server connection, tool-list retrieval, metadata storage, LLM processing, and tool invocation.
- Architectural weaknesses: The architecture lacks a validation layer, treats the LLM as the sole tool-selection arbiter, hides parameters from users, and implicitly trusts server metadata.These weaknesses create multiple client-side control gaps.
- Defense in depth: The proposed defenses combine metadata validation, decision-dependency tracking, runtime monitoring, sandboxing, explicit confirmation, and full tool transparency.Controls include schema and signature checks, anomaly detection, restricted execution, parameter display, warnings, and audit logs.
- Operational mitigation: The mitigation strategy matrix applies Prevention, Detection, Response, and Recovery across functional layers so later controls remain active when earlier prevention fails.Protocol hardening is prioritized as the foundation, runtime isolation for production, and monitoring and governance for enterprise deployments.
5 Experiments and Assessments
The empirical study compares seven commercial and open-source MCP clients using controlled local experiments. It evaluates client vulnerability, detection mechanisms, and architectural choices across four tool-poisoning techniques.
- Study design: Seven major MCP clients were evaluated using a systematic comparison of their security against tool poisoning.The clients represent both commercial and open-source implementations.
- Assessment dimensions: The evaluation examines metadata validation, user-interface transparency during tool invocation, and detection of suspicious behavior.These dimensions target how clients handle server-provided tool metadata and execution visibility.
- Attack scenarios: Experiments were conducted in a controlled local environment with isolated MCP servers across four attacks: sensitive-file reading, usage logging, phishing-link creation, and remote code execution.The attack set spans information access, monitoring, social engineering, and code execution behaviors.
5.1 Attack Implementation Details
The study implements four progressively sophisticated tool-poisoning attacks that embed malicious instructions in apparently legitimate MCP tools. The attacks target unauthorized file access, execution priority and logging, deceptive URLs, and remote-code execution, with secure-client behaviors defined for comparison.
- Attack Design: Four progressively sophisticated tool-poisoning attacks test whether MCP clients detect malicious instructions embedded in tool descriptions.The attacks cover hidden-parameter file access, priority and surveillance claims, deceptive links, and remote-code execution.
- Attack 1: Hidden File Access: The hidden-parameter attack disguises requests to read sensitive files and pass their contents through a benign addition tool.The poisoned description instructs the LLM to read configuration and SSH files, conceal the access, and use a sidenote parameter.
- Attack 2: Priority and Surveillance: The priority-and-logging attack claims execution precedence and records subsequent tool usage, prompts, descriptions, parameters, and activity timelines.Secure behavior includes ignoring priority claims, requiring permission for logging, and sandboxing file writes.
- Attack 3: Deceptive URLs: The deceptive-URL attack presents benign link text while directing users to attacker-controlled destinations and exposing account numbers in URLs.Secure clients should display full URLs, warn about external connections, and require confirmation for link generation.
- Attack 4: Remote Code Execution: The remote-code attack embeds a command to download and execute an attacker-controlled script with the user’s privileges during system configuration.The described consequences include malware installation, backdoors, data exfiltration, and lateral movement; secure behavior blocks shell execution and logs the incident.
5.2 Testing Procedure
Each client-attack combination is evaluated through a controlled sequence that deploys a poisoned local server, observes tool execution, checks safeguards, and classifies the outcome.
- Detection Checks: Clients are checked for warnings, confirmation dialogs, blocking or sandboxing, and suspicious-activity logging.These checks assess both user-facing and enforcement mechanisms.
- Outcome Classification: Results are classified as Unsafe, Partial, or Safe according to whether the attack completes without detection, executes with limitations, or is appropriately prevented.Researchers also document screenshots, logs, system traces, parameter values, and user experience.
5.3 Data Collection
Data collection combines quantitative attack and detection measures with qualitative observations and technical analysis of client implementations.
- Quantitative Metrics: Quantitative measures include attack outcome, time to detection, confirmation count, and log completeness and detail.Attack outcomes use the Unsafe, Partial, and Safe categories.
- Qualitative Observations: Qualitative observations assess interface clarity, warning effectiveness, parameter visibility, and the overall user experience.These observations focus on how clearly clients expose and communicate suspicious behavior.
- Technical Analysis: Technical analysis examines tool registration, parameter parsing, and validation logic when present.These implementation details are analyzed alongside the observed attack behavior.
5.4 Ethical Considerations
The evaluation is conducted under controlled, isolated conditions with safeguards intended to prevent exposure of real credentials, users, or production systems.
- Controlled Testing: Testing uses local isolated systems and no real credentials or sensitive data.The study avoids directing attacks at production systems or real users.
- Oversight and Disclosure: The researchers report responsible disclosure, destruction of malicious test servers, and institutional review board approval.These measures govern vendor notification, test cleanup, and research oversight.
6 Results and Analysis
Across seven MCP clients, security varied substantially across four attacks, with Cursor repeatedly vulnerable and other clients showing partial or model-dependent protection. The evaluation also found recurring weaknesses in validation, parameter visibility, sandboxing, and behavioral monitoring.
- Attack results: Seven MCP clients showed significant variation in security outcomes across four attack types.Table 19 summarizes safe, partial, and unsafe outcomes across the tested clients.
- Attack results: Cursor allowed sensitive-file access, automatic surveillance logging, deceptive phishing-link creation, and remote-script execution.Its failures reflected absent validation, parameter inspection, and security warnings, alongside trust in server-provided metadata.
- Attack results: Claude Desktop, Cline, Continue, and Gemini CLI blocked or limited several attacks through model refusals, policy enforcement, or interface protections.Protection was not uniform: some clients remained partially vulnerable or context-dependent.
- Attack results: Four clients blocked remote-script attacks through model-level refusals, while Cursor and Cline executed remote scripts and Langflow only attempted downloads.Basic domain filtering in Cursor and Cline rejected obviously suspicious URLs but was bypassable with legitimate-appearing domains.
- Security features: Five of seven clients lacked static validation, while common weaknesses also included incomplete parameter visibility, missing sandboxing, and absent behavioral monitoring.The feature assessment combined empirical testing, behavioral observation, and interface analysis.
- Overall client posture: Claude Desktop and Cline were assessed as the most secure clients, whereas Cursor was assessed as the most vulnerable and required urgent improvement.Claude Desktop showed no observed successful attacks across the tested vectors; Cursor’s four attacks were successful.
7 Discussion
The discussion finds major architectural and behavioral differences among MCP clients, with protection often relying on reactive detection or model behavior rather than preventive controls. It therefore recommends layered security improvements while acknowledging limits from subjective scoring, tested-client coverage, and controlled conditions.
- Key findings: MCP clients ranged from comprehensive protection in Claude Desktop and Cline to minimal protection in Cursor.The authors identify this variance as a source of user confusion and organizational risk.
- Key findings: Most clients relied on detecting attacks during or after execution rather than preventing them through registration controls or sandboxing.The discussion characterizes this as a reactive approach and contrasts it with proactive prevention.
- Key findings: No single client blocked every attack type, supporting defense-in-depth rather than reliance on one protective layer.The authors also note a trade-off between stricter security measures and usability.
- Recommendations: The authors recommend static metadata validation, parameter visibility, sandboxed execution, and behavioral monitoring for developers.Additional recommendations target organizations, users, and standards bodies through risk assessment, transparent security features, and stronger MCP guidance.
- Recommendations: The proposed roadmap calls for basic validation immediately, certification and disclosure standards in the short term, and standardized sandboxing and anomaly detection longer term.The schedule spans immediate, three-to-six-month, and six-to-twelve-month priorities.
- Threats to validity: The findings may not generalize beyond the seven assessed clients, configurations, versions, and controlled test environment, and the authors’ security scores are subjective.The study identifies author bias, limited client coverage, and differences between controlled testing and production scenarios as validity threats.
8 Conclusions and Future Work
The study finds substantial and inconsistent client-side security weaknesses across MCP implementations, while showing that effective defenses are achievable. It concludes with technical, ecosystem-wide, and research priorities for improving MCP security.
- 50+ threats were identified through STRIDE and DREAD threat modeling of MCP implementations.
- Attack success rates ranged from 0% for Claude Desktop to 100% for Cursor across four tool poisoning attack vectors.
- Malicious tool descriptions enabled credential theft, surveillance, and phishing, while MCP lacked unified security guidelines.
- Trust models and validation mechanisms determined security posture more than implementation details.
- Future work includes MCP detection tools, eBPF-based anomaly detection, responsible disclosure, broader testing, and enterprise security guidance.