Are AI-assisted Development Tools Immune to Prompt Injection?

1 Introduction

• Prompt injection can subvert guardrails, disclose sensitive data, and trigger unauthorized tool use; indirect attacks hide instructions in artifacts later ingested by a model.MCP tool poisoning hides malicious instructions in tool descriptions, metadata, or configurations, exploiting tool interfaces the model treats as trusted.Source: §1 · p. 1
• The research gap is limited comparative empirical evaluation of real-world MCP clients and their security features.The examined features include static validation, parameter visibility, injection detection, user warnings, execution sandboxing, and audit logging.Source: §1 · pp. 1–2
• The study compares seven widely used MCP clients through adversarial testing and examines their defenses and security-feature coverage.It addresses whether clients are vulnerable to tool-poisoning attacks, which detection and mitigation mechanisms they implement, and which security features they cover.Source: §1 · p. 2

2 Related Work

• OWASP identifies prompt injection as the top LLM application risk and recommends defense-in-depth, including least-privilege tooling and human approval.Examples of defenses include prompt and output scanners, input/response safety classifiers, and simulated action-result evaluation [46][63][53, 64].Source: §2 · p. 2
• Prompt-injection defenses can be brittle: combined attacks increase success, and tool-integrated agents remain vulnerable even under strong prompting [54][70].Hacking-style reinforcements can nearly double baseline success for ReAct-prompted GPT-4 in InjecAgent.Source: §2 · p. 2
• Retrieval poisoning can succeed with little malicious content: PoisonedRAG reports nearly 90% targeted attack success, while other retrieval attacks also achieve high success [71][42].The cited work includes systems that store generated outputs back into retrieval stores.Source: §2 · p. 2

3 Comparative Analysis of Tools

• The comparative analysis summarizes reported vulnerabilities, mitigations, and risks; its qualitative scale weighs untrusted inputs, model authority, oversight, context separation, and severe vulnerability history.Low risk entails separated contexts, human approval, and restricted autonomous chaining; high risk includes action from untrusted text or direct execution without oversight.Source: §3 · p. 2, Table 1 · p. 3
• Claude Desktop is rated low to medium risk, with permission-gated tools and strong role separation, while Claude Code is low to medium risk because commands are visible and workflows remain explicit.Both retain risks from indirect attacks or integrations; Claude Desktop rarely autoexecutes, and dangerous steps generally require confirmation.Source: §3 · pp. 3–4
• Cursor faces medium-to-high tool-poisoning risk, while Cline is assessed as high risk because of autonomous file, command, and tool-chaining capabilities.Cursor's command approvals can be weakened by click-fatigue; Cline's dynamic tool discovery and trust in tool outputs can amplify injection impact.Source: §3 · p. 4
• Continue's risk ranges from safe in strict configurations to dangerous in exploratory setups; Gemini CLI is medium risk, and Langflow's tool-poisoning risk varies from low to high.Continue relies on prompt guardrails and configurable auto-approval; Gemini CLI users typically review commands, while Langflow can blur trust boundaries when retrieved content flows into prompts.Source: §3 · pp. 4–5

4 Experiments and Assessments

• The evaluation covers seven commercial and open-source MCP clients, tested in November 2025.Experiments used isolated local systems and four attack types; no real credentials, sensitive data, production systems, or real users were involved.Source: §4 · p. 5, §4.1 · p. 5

4.1 Attack Implementation

• Four tool-poisoning attacks test client resilience: reading sensitive files, logging tool usage, creating phishing links, and executing remote scripts.The tests use malicious MCP servers and controlled conditions under strict ethical guidelines.Source: §4.1 · p. 5

4.1.1 Reading Sensitive Files Attack.

• The file-reading attack hides requests for sensitive configuration and SSH files in an apparently legitimate addition tool, passing contents through a hidden parameter.Secure behavior includes detecting suspicious paths, blocking access or requiring explicit permission, and logging suspicious activity.Source: §4.1.1 · pp. 5–6

4.1.2 Logging Tool Invocation Activities Attack.

• The logging attack claims priority to run before other tools and records subsequent tool use, user prompts, parameters, and activity timelines.The proposed secure behavior ignores priority claims and requires permission for logging or sandboxes file writes.Source: §4.1.2 · p. 6

4.1.3 Creating Phishing Links Attack.

• The phishing-link attack tests whether clients expose the destination URL when a tool requests a benign-looking clickable link.The hidden link can transmit an account number to an attacker; the expected secure behavior displays the full URL and requires confirmation.Source: §4.1.3 · p. 6

4.1.4 Remote Execution of Scripts Attack.

• The remote-script attack embeds instructions to download and execute code during a purported system-configuration update.The expected secure behavior blocks shell commands, alerts the user, and logs attempted remote execution.Source: §4.1.4 · p. 6

4.2 Testing Procedure

• Each test deploys a malicious local server, connects a client, submits a benign request, observes execution, and checks for warnings, confirmations, blocking, sandboxing, or logging.Outcomes are classified as unsafe when attacks complete without detection, partial when attacks execute with warnings or limitations, and safe when appropriate measures prevent them.Source: §4.2 · p. 6

4.3 Data Collection

• Data collection combines attack outcomes and detection time with confirmation counts, log completeness, interface observations, and technical analysis of registration, parsing, validation, and detection.Qualitative observations include warning effectiveness, parameter visibility, interface clarity, and user experience.Source: §4.3 · p. 7

• Security implementations varied significantly across the tested clients.Table 3 presents the comprehensive analysis of immunity status against implemented attacks and protection mechanisms.Source: §5 · p. 7

5.1.1 Reading Sensitive Files Attack.

• Cursor, Cline, and three other clients could permit sensitive-file reading, while Claude Desktop, Cline, and Continue blocked it through model refusals with Claude Sonnet 4.5.Cursor allowed file reads after user approval without warning; Gemini CLI, Claude Code, and Langflow could potentially allow them when configured with file-system permissions.Source: §5.1.1 · p. 7

5.1.2 Logging Tool Usage Attack.

• Four clients blocked automatic surveillance logging, but Cursor enabled multi-session logging; Claude Desktop and Langflow allowed logging when explicitly prompted.Source: §5.1.2 · p. 7

5.1.3 Creating Phishing Links Attack.

• Cursor created deceptive phishing links with hidden destinations, while Continue’s tooltip URL preview mitigated the attack despite primary controls failing.CLI clients gained architectural protection from text-only interfaces.Source: §5.1.3 · p. 7

5.1.4 Remote Execution of Scripts Attack.

• Cursor and Cline executed remote scripts when instructed, despite basic domain filters that could be bypassed with legitimate-appearing domains.Four clients blocked the attack through model refusals; Langflow attempted downloads but could not execute shell scripts. The results highlight reliance on model behavior rather than client-side sandboxing and network controls.Source: §5.1.4 · p. 7

5.2.1 Static Validation.

• Static validation was assessed by registering malicious tool descriptions, checking rejection or warnings, and examining schema validation beyond basic JSON checks.Clients were classified as accepting descriptions without validation, partially validating them, or systematically scanning and enforcing policy; no client met the systematic category.Source: §5.2.1 · p. 7

5.2.2 Parameter Visibility.

• Parameter visibility was assessed from approval dialogs for whether all parameter values appeared prominently or were hidden, truncated, or obscured by scrolling.Tools with varying parameter counts and lengths were invoked, and screenshots were captured for review.Source: §5.2.2 · p. 7

5.2.3 Injection Detection.

• Injection detection was tested with four attack types using patterns such as priority claims and hidden instructions, distinguishing model refusals from explicit pattern scanning and other coverage levels.The classification also included partial or absent detection; Table 3 summarizes immunity assessments and protection mechanisms against implemented attacks.Source: §5.2.3 · p. 7, Table 3 · p. 8

5.2.4 User Warnings.

• User warnings were assessed for risk-specific alerts during tool operations, including their clarity and actionability, with coverage classified as comprehensive, partial, or absent.Generic approval prompts without risk context counted as no proactive security warning.Source: §5.2.4 · p. 9

5.2.5 Execution Sandboxing.

• Sandboxing coverage was assessed from documentation and architectural analysis rather than empirical testing because comprehensive tests were not completed.Categories distinguished confirmed features, possible enterprise or architecturally indicated features, no documented capability, and unknown status.Source: §5.2.5 · p. 9

5.2.6 Audit Logging.

• Audit logging was assessed by checking for logs after tool operations and reviewing their completeness, including parameters, timestamps, results, and user accessibility.Classifications distinguished comprehensive, partial, absent or inaccessible, and unknown logging.Source: §5.2.6 · p. 9

• Common weaknesses included absent static validation, insufficient parameter visibility, missing sandboxing and behavioral monitoring, and implicit trust in server-provided descriptions.The analysis reports that five of seven clients lacked static validation and two addressed it partially.Source: §5.3 · p. 9
• Claude Desktop and Cline were judged the most secure, with the former relying on model behavior and enforced policy and the latter on pattern-based detection, warnings, and user education.No successful attack was observed against Claude Desktop across the tested vectors.Source: §5.3 · p. 9
• Cursor was judged the most vulnerable: it lacked tool-description validation, parameter inspection, filtering, and security warnings, and all four attacks succeeded.The analysis also notes that Cursor blindly trusts server-provided metadata.Source: §5.3 · pp. 9–10
• Continue, Gemini CLI, Claude Code, and Langflow were partially secure, with inconsistent protection across attack types and context-dependent outcomes.The authors state these clients require systematic security frameworks for comprehensive protection.Source: §5.3 · p. 10

6 Discussion

• Claude Desktop and Cline ranked most secure experimentally, while Cursor was most vulnerable; no client blocked every attack.Clients rely mainly on detection during or after execution rather than prevention at registration or sandboxing.Source: §6 · p. 10
• Recommendations span static tool-description validation, visible parameters, sandboxed execution, behavioral monitoring, and organizational risk assessment and incident planning.The paper also recommends transparent security and comprehensive MCP security guidance, certification, and disclosure procedures.Source: §6 · p. 10
• For high-risk tools, users should treat tool output as untrusted, require confirmation between calls, and prevent output from modifying system prompts.The authors also recommend sanitizing inputs and descriptions, avoiding auto-approval, and monitoring for updates.Source: §6 · p. 10
• Organizations should audit MCP deployments and use compensating controls; users should avoid granting sensitive write access or sudo privileges without human oversight.The recommendations also include running tools in containers or VMs and preventing access to sensitive files by default.Source: §6 · p. 10
• The evaluation covers seven clients and assessed versions; controlled tests may not reflect production, and MCP-specific findings may not generalize to other agent protocols.The authors also note possible author bias, omitted clients or configurations, and missed recent vulnerabilities.Source: §6 · p. 10

7 Conclusions

• Across seven MCP clients and four tool-poisoning vectors, client-side security was inadequate, with Cursor highly susceptible to cross-tool poisoning, hidden parameters, and unauthorized tool invocation.Malicious tool descriptions also enabled credential theft, surveillance, and phishing attacks.Source: §7 · p. 10