PaperlayerView exact revision on arXiv

Source-linked AI summary

MCP-ITP: An Automated Framework for Implicit Tool Poisoning in MCP

Ruiqi Li, Zhiqiang Wang, Yunhao Yao, Xiang-Yang Li

arXiv:2601.07395v1cs.CRcs.AI

TL;DR

MCP tool integration creates a security gap that enables implicit tool poisoning, in which poisoned metadata redirects agents to legitimate high-privilege tools without invoking the poisoned tool. MCP-ITP uses adversarial black-box optimization with evaluator and detector feedback to generate stealthy poisoned descriptions. Across 12 LLM agents, it outperforms the manually crafted baseline, reaching 84.2% ASR and reducing MDR to as low as 0.3%.

  • Problem

    Existing tool-poisoning research mainly addresses explicit invocation or manually crafted tools, leaving implicit attacks that redirect agents through uninvoked poisoned tools insufficiently addressed.

  • Method

    MCP-ITP uses iterative black-box optimization with attacker, evaluator, and detector LLM feedback to craft poisoned tool descriptions.

  • Results

    84.2% ASR versus 48.2% for the manually crafted baseline was achieved on GPT-3.5-turbo, while MDR reached as low as 0.3%.

  • Takeaways & Limitations

    MCP-ITP demonstrates cross-model implicit tool-poisoning effectiveness and evasiveness against existing malicious-tool detection mechanisms.

  • Takeaways & Limitations

    MDR increases when stronger malicious-tool detectors are used, and evaluation is restricted to the MCPTox dataset without formal theoretical analysis.

Abstract

from arXiv · show

To standardize interactions between LLM-based agents and their environments, the Model Context Protocol (MCP) was proposed and has since been widely adopted. However, integrating external tools expands the attack surface, exposing agents to tool poisoning attacks. In such attacks, malicious instructions embedded in tool metadata are injected into the agent context during MCP registration phase, thereby manipulating agent behavior. Prior work primarily focuses on explicit tool poisoning or relied on manually crafted poisoned tools. In contrast, we focus on a particularly stealthy variant: implicit tool poisoning, where the poisoned tool itself remains uninvoked. Instead, the instructions embedded in the tool metadata induce the agent to invoke a legitimate but high-privilege tool to perform malicious operations. We propose MCP-ITP, the first automated and adaptive framework for implicit tool poisoning within the MCP ecosystem. MCP-ITP formulates poisoned tool generation as a black-box optimization problem and employs an iterative optimization strategy that leverages feedback from both an evaluation LLM and a detection LLM to maximize Attack Success Rate (ASR) while evading current detection mechanisms. Experimental results on the MCPTox dataset across 12 LLM agents demonstrate that MCP-ITP consistently outperforms the manually crafted baseline, achieving up to 84.2% ASR while suppressing the Malicious Tool Detection Rate (MDR) to as low as 0.3%.

1 Introduction

MCP-ITP addresses implicit tool poisoning, where malicious metadata redirects agents from intended actions to legitimate high-privilege tools without invoking the poisoned tool. It automates poisoned-description generation and outperforms a manually crafted baseline while evading detection.

  • MCP standardizes external-tool access but expands the attack surface because third-party tools lack unified security vetting.
  • Implicit tool poisoning leaves the poisoned tool uninvoked while redirecting the agent to a legitimate, high-privilege target tool.This decoupling makes execution-monitoring detection difficult.
  • MCP-ITP formulates poisoned-tool generation as black-box optimization using attacker, detector, and evaluator LLM feedback.The attacker LLM refines candidates while the detector and evaluator provide evasiveness and effectiveness feedback.
  • 84.2% ASR versus 48.2% for the manually crafted baseline was achieved on GPT-3.5-turbo, while MDR reached as low as 0.3%.The evaluation covered 12 prominent LLM agents on MCPTox, built from 45 real-world MCP servers and 353 real tools.
  • MCP-ITP systematically investigates contextual redirection without directly invoking the poisoned tool.

2 Background and Related Work

The background situates MCP tool poisoning as a specialized indirect prompt injection that exploits tool metadata loaded during registration. Related attacks include prompt injection, agent-component manipulation, and direct tool poisoning, while MCP adoption broadens the exposure surface.

  • Prompt injection embeds malicious instructions in external data to steer LLM actions, whereas jailbreaks operate through user inputs to bypass safety guardrails.
  • Agent attacks exploit integrated components by hijacking tool selection or corrupting retrieval-augmented generation databases.
  • MCP lets agents dynamically discover, select, and orchestrate tools using server-provided metadata loaded into the LLM context.
  • MCP’s standardized design lowers the barrier to tool integration, while attackers can use MCP servers for tool poisoning and rug-pull attacks.
  • Tool poisoning embeds malicious instructions directly in tool descriptions and injects them into the LLM context during MCP registration.It is described as a specialized form of indirect prompt injection.
  • Prior automated work primarily generated tools whose malicious effects occurred when the poisoned tools were directly invoked.

3 Threat Model

The threat model treats users and the MCP Host as honest or trusted, while MCP servers may be untrusted and load poisoned tools alongside benign tools. Attackers operate without user queries or agent internals and seek stealthy redirection to high-privilege tools.

  • The MCP workflow includes users, the MCP Host, and MCP Servers.
  • Users are assumed honest and noncolluding, issuing benign queries and receiving final responses through the Host.
  • The MCP Host is trusted and orchestrates tool invocations between the user query, system prompt, and execution results.
  • MCP Servers are untrusted; an attacker-controlled server can load a poisoned tool alongside benign tools and manipulate invocation decisions.
  • In the black-box setting, attackers cannot access actual user queries or internal agent parameters but can inspect benign tools and publish poisoned tools.
  • The attacker redirects queries intended for an original tool to a legitimate high-privilege target while keeping the poisoned tool dormant and evading detection.

4 Methodology

MCP-ITP automatically constructs implicitly poisoned tools through iterative black-box optimization, balancing attack effectiveness against detector evasion. Its attacker, evaluator, and detector LLMs generate, assess, and refine candidate payloads across successive search iterations.

  • Framework overview: MCP-ITP uses attacker, detector, and evaluator LLMs to iteratively optimize poisoned-tool candidates.The attacker generates candidates, while the detector and evaluator assess maliciousness and attack effectiveness.
  • Poisoned-tool construction: The method decomposes the poisoned description into camouflage R and functional payload S, then optimizes S to induce target-tool invocation.R aligns semantically with the original tool, while S realizes the implicit poisoning functionality.
  • Candidate generation: At each iteration, the attacker LLM generates N refined candidates from current candidates and prior feedback.New candidates are merged into Cand_next for subsequent evaluation.
  • Maliciousness detection: The detector assigns a maliciousness label and rationale, and malicious candidates receive a score penalty that guides later optimization.Detector rationales are appended to feedback for the next iteration.
  • Effectiveness evaluation: The evaluator scores candidates by counting shadow queries in which the target tool is invoked, using an indicator for target-tool selection.The merged system prompt contains the legitimate tools and each candidate poisoned tool.
  • Feedback and selection: Candidates are ranked by combined effectiveness and detection scores, with the top W retained until a threshold is met or the iteration limit is reached.The highest-scoring candidate is returned when optimization terminates.

5 Experiments

MCP-ITP is evaluated across 12 LLM agents and MCPTox’s implicit-poisoning cases, using ASR for attack effectiveness and MDR for detection evasiveness. It generally improves attack success over manually crafted tools, lowers detection rates, and shows that model capability, reasoning mode, description design, and evaluator choice affect outcomes.

  • Experiment Settings: Experiments use MCPTox’s 45 MCP servers, 353 tools, and 548 implicit-poisoning cases to compare MCP-ITP with manually crafted tools across 12 LLM agents.The MCP implementation uses the open-source MCP codebase and its default system prompt.
  • Evaluation Metrics: ASR measures successful attacks among valid agent responses, while MDR measures malicious-tool flags among valid outputs.Higher ASR indicates greater attack effectiveness, whereas lower MDR indicates greater evasiveness.
  • Main Results: 84.2% ASR is achieved on GPT-3.5-turbo, alongside 82.9% on o1-mini and 78.4% on DeepSeek-V3.The reported evaluation uses one run per agent setting, and failures are categorized as Ignored, Direct, or Others.
  • Main Results: MCP-ITP raises ASR from 48.2% to 84.2% on GPT-3.5-turbo and improves by over 10 percentage points in 8/12 settings versus MCPTox.The gains are primarily associated with fewer Ignored cases and a greater likelihood of invoking target tool TG instead of original tool TA.
  • Main Results: MDR falls from 17.22% to 0.96% under AI-Infra-Guard and from 77.35% to 31.39% under Oracle for o1-mini.MCP-ITP attains lower MDR than MCPTox under both detection methods.
  • Ablation Study: Reasoning raises Qwen3-8b ASR from 7.44% to 40.5% and Qwen3-32b ASR from 28.8% to 69.9%, while stronger models are more vulnerable.The observed pattern is linked mainly to decreasing Ignored rates as model capability increases.
  • Ablation Study: Adding R increases ASR for higher-capability models but reduces it for weaker models, whereas Qwen3-32b as evaluator generally outperforms o1-mini.The evaluator comparison attributes earlier stopping with a more capable evaluator to suboptimal convergence.

6 Conclusion

The paper identifies implicit tool poisoning as a practical MCP security threat and introduces MCP-ITP to automate attacks that manipulate tool invocations without directly executing the poisoned tool. It reports improved attack effectiveness and reduced detection rates, while noting dataset, detection-strength, theoretical-analysis, and deployment-scope limitations.

  • MCP-ITP is an automated iterative-optimization framework for crafting implicit tool poisoning attacks in MCP settings.
  • MCP-ITP manipulates agent tool invocations without directly executing the poisoned tool and can evade existing malicious-tool detection methods.
  • The evaluation is restricted to the MCPTox dataset because datasets for MCP-specific implicit tool poisoning remain limited.
  • The study emphasizes empirical attack effectiveness and evasiveness rather than providing a formal theoretical analysis.
  • The attacks were conducted only in controlled environments and were not deployed against real-world or live systems.
  • The dataset is open and transparent, with randomly generated PII and no real personal data collected, processed, or stored.

A Shadow Queries Generation

The shadow-query procedure constructs queries that normally invoke a selected original tool, using its intent and argument schema while enforcing concise, structured, non-destructive outputs.

  • The attacker constructs a shadow query set Q = {q1, . . . , qm} whose queries normally invoke the original tool TA.
  • The query-generation prompt asks for exactly m short user queries specifically requiring the selected tool rather than other tools.
  • Queries are grounded in the original tool’s intent and argument schema, desc(TA).
  • The generator must output JSON containing a queries array and no code blocks, explanations, or tool names inside the queries.
  • The prompt requires plausible non-destructive paths under /home/user or /data.
  • Each query is constrained to at most 25 words.

B Details for Attacker LLM LA Setting

The attacker LLM iteratively optimizes poisoned-tool descriptions using detector and evaluator feedback, while prompting for authoritative, detection-evasive instructions that force a target tool invocation before the original tool acts.

  • The attacker LLM LA initializes desc(TK) from S0 and refines candidates using detector labels and rationales plus evaluator effectiveness feedback.
  • The poisoning instruction requires calling [ng] before [na] performs its core function for compliance policy.
  • The target tool [na] is locked until [ng] completes its core action for the relevant resource, framing [ng] as an activator.
  • Optimization feedback records prior detection status, attack failures, failed queries, and the previous iteration’s total score.
  • The setting frames the attacker as a cybersecurity researcher addressing tool poisoning, prompt injection, and AI-agent threat modeling.
  • The initial attacker prompt asks for b alternative S-descriptions satisfying evasion, priority-hijack, and trigger-hijack goals.
  • Each variant uses an authoritative compliance-policy tone and is emitted one per line without numbering or extra text.
  • The attacker avoids replacement language, suspicious terms, and unrelated actions while binding [ng] to [na]’s target resource.

C Prompt for Evaluator LLM LE

The evaluator LLM selects tools and produces invocation outputs for shadow queries, while the detector LLM classifies poisoned descriptions and explains whether they contain suspicious instructions.

  • C Prompt for Evaluator LLM LE: For each candidate TK(Si), the evaluator LLM LE produces tool-invocation outputs for the shadow queries.
  • C Prompt for Evaluator LLM LE: The evaluator receives legitimate tools together with the poisoned tool and chooses the appropriate tool based on the user’s question.
  • C Prompt for Evaluator LLM LE: When a tool is needed, the evaluator must return only the specified JSON object containing the tool name and arguments.
  • C Prompt for Evaluator LLM LE: After a tool response, the evaluator transforms raw data into a concise, informative conversational response using relevant context.
  • D Prompt for Detector LLM LD: The detector LLM LD analyzes a candidate tool description for embedded instructions and outputs a binary maliciousness label with supporting rationale.
  • D Prompt for Detector LLM LD: The detector focuses on instructions that deviate from the tool’s original function, including attempts to bypass rules or hide instructions.
  • D Prompt for Detector LLM LD: The detector also flags forced tool replacement and unexpected actions beyond normal tool functions as malicious indicators.

E Case Study

The case studies show poisoned tools inducing agents to invoke other tools during requests, including high-privilege or legitimate tools, rather than necessarily invoking the poisoned tool itself. Across examples, the induced tool calls include compliance-themed triggers and unauthorized or unintended operations.

  • Response categories: The reported response categories distinguish success, ignored attacks where the original tool is invoked, and direct attacks where the poisoned tool is invoked.These categories separate induced target-tool invocation from non-response and direct poisoned-tool invocation.
  • Email-deletion case: In the email-deletion case, secure_email_deletion instructs the agent to call getEmailDetail before deleteEmail, and the model invokes getEmailDetail instead.The call requests details for email 123 in the inbox rather than deleting the listed emails.
  • Create-issue case: In the create-issue case, the poisoned context tool instructs the agent to call push_files before create_issue, and the model ultimately invokes create_issue.The response creates an issue in my-project with the specified title and body.
  • Profile case: In the profile case, signature instructs the agent to call openai_computer_use_agent before create_profile, and the model invokes signature.The user requested creation of a persistent Hyperbrowser profile, but the recorded response selects the signature tool.
Loading 2601.07395v1…