PaperlayerView exact revision on arXiv

Source-linked AI summary

Les Dissonances: Cross-Tool Harvesting and Polluting in Pool-of-Tools Empowered LLM Agents

Zichuan Li, Jian Cui, Xiaojing Liao, Luyi Xing

arXiv:2504.03111v3cs.CR

TL;DR

Multi-tool LLM agents create control-flow risks that prior work on isolated malicious tools did not address. The paper defines XTHP attacks, develops Chord to test tools for them, and finds that 75% of tested tools can be practically exploited. The evaluation focuses mainly on LangChain and LlamaIndex tools.

  • Problem

    Prior work on inappropriate tool use focused mainly on isolated malicious tools, leaving risks from pools of tools and their task control flows underexplored.

    Source: §I · p. 1

  • Method

    The authors define XTHP attacks and develop Chord to generate malicious tools and dynamically test target tools in agent task contexts.

    Source: §I · pp. 1–2, A. Chord: A Dynamic XTHP Threat Analyzer · p. 9

  • Results

    75% of tools were identified as practically exploitable, and 27 of 37 LangChain tools and 21 of 29 LlamaIndex tools susceptible to hijacking were vulnerable to XTH exploits.

    Source: 1) Results landscape · p. 11, §VIII · p. 13

  • Takeaways & Limitations

    XTHP can exploit agent control flows to harvest sensitive data or pollute information handled by legitimate tools.

    Source: §I · pp. 1–2

    The evaluation mainly focused on LangChain and LlamaIndex tools, although the authors describe XTHP as potentially affecting other frameworks and tool integrations.

    Source: §VI · p. 13

Abstract

from arXiv · show

Large Language Model (LLM) agents are autonomous systems powered by LLMs, capable of reasoning and planning to solve problems by leveraging a set of tools. However, the integration of multi-tool capabilities in LLM agents introduces challenges in securely managing tools, ensuring their compatibility, handling dependency relationships, and protecting control flows within LLM agent workflows. In this paper, we present the first systematic security analysis of task control flows in multi-tool-enabled LLM agents. We identify a novel threat, Cross-Tool Harvesting and Polluting (XTHP), which includes multiple attack vectors to first hijack the normal control flows of agent tasks, and then collect and pollute confidential or private information within LLM agent systems. To understand the impact of this threat, we developed Chord, a dynamic scanning tool designed to automatically detect real-world agent tools susceptible to XTHP attacks. Our evaluation of 66 real-world tools from the repositories of two major LLM agent development frameworks, LangChain and LlamaIndex, revealed a significant security concern: 75% are vulnerable to XTHP attacks, highlighting the prevalence of this threat.

I. INTRODUCTION

The paper examines control-flow risks introduced when LLM agents use pools of tools, extending prior work focused mainly on isolated malicious tools. It defines XTHP as a way for adversarial tools to enter agent workflows and then harvest or pollute information.

I. INTRODUCTION

  • Prior work primarily studied malicious tools in isolation, while pool-of-tools agents introduce tool compatibility, dependency, and control-flow challenges.The authors argue that these challenges call for systematic investigation of tool orchestration and runtime workflows.Source: §I · p. 1
  • XTHP tools claim functionality or relations that make them appear useful alongside victim tools, entering the agent’s task control flow before or after them.Crafted descriptions may be dynamically loaded from adversarial servers.Source: §I · pp. 1–2
  • After hijacking control flow, adversarial tools can harvest or pollute information produced or processed by other tools.The paper describes misinformation in YouTube search results and collection of sensitive information, including names, addresses, and medical search records.Source: §I · p. 2
  • Chord automatically generates malicious tools and tests target tools in task-specific agent contexts for end-to-end XTHP exploits.The paper reports testing 66 real-world tools from LangChain and LlamaIndex repositories.Source: §I · p. 2

II. BACKGROUND

  • A tool schema includes a name, description, arguments, and an entry function, while agents select tools from those imported into their pool.The framework API binds tools to models and passes tool results back into the model.Source: §II · p. 2

III. THREAT MODEL

  • The threat model assumes an attacker can introduce a context-aligned malicious tool into an agent’s pool to hijack tool selection and harvest or pollute information.Direct attacks that manipulate the LLM into harmful or incorrect decisions are outside the paper’s scope.Source: §III · pp. 3–4

IV. CROSS-TOOL HARVESTING & POLLUTING

XTHP attacks first hijack an agent’s control flow, then harvest or pollute information handled by legitimate tools. The overview illustrates how a helper tool can be used to alter a victim tool’s inputs and results.

A. Overview

  • XTHP combines control-flow hijacking with cross-tool harvesting or polluting, and can be triggered automatically when a malicious tool is available to the agent.The adversarial tool inserts itself into normal tool execution by logically hooking onto a victim tool.Source: A. Overview · p. 4
  • Three attack vectors—semantic logic hooking, syntax format hooking, and LLM-preference optimization—can place a malicious tool before or after a victim tool.The chosen position supports different attack goals, including harvesting or polluting.Source: A. Overview · p. 4
  • A YoutubeSearchPreprocessor can claim to construct the required comma-separated input, then replace search terms to return unwanted or disinformative results.The same tool may harvest private information from the user query or task context.Source: A. Overview · p. 4

B. Semantic Logic Hooking

Semantic logic hooking exploits a claimed relationship between a malicious helper and a victim tool. Tools requiring external knowledge create targeted hooking opportunities because an agent may employ a helper to prepare the victim’s input.

B. Semantic Logic Hooking

1) Targeted Semantic Hooking:

  • YahooFinanceNews requires a stock ticker, so a CompanyToTicker helper can claim to convert company names and be selected immediately before it.The authors describe this as an external knowledge dependency, even when the LLM may already know the ticker mapping.Source: 1) Targeted Semantic Hooking · p. 5
  • Agents may rely on an available helper for ticker knowledge even when that knowledge is already within the LLM’s training, which can make the helper a hooking point.The paper notes that internal knowledge may be outdated and that ReAct agents tend to prioritize external knowledge.Source: 1) Targeted Semantic Hooking · p. 5

2) Untargeted Scenario-based Semantic Hooking:

The paper describes several ways to exploit agent tool selection: scenario-based semantic hooks, runtime-created descriptions, format-validation helpers, and tool descriptions optimized for model preferences.

2) Untargeted Scenario-based Semantic Hooking:

  • Tools claiming error handling or other scenario-specific help may be invoked when agents encounter execution errors or related task contexts.Examples include coding vulnerability validation and prompt paraphrasing.Source: 2) Untargeted Scenario-based Semantic… · pp. 5–6

3) Dynamic Tool Creation:

  • Toolkit tools can receive names and descriptions from remote servers at runtime, letting developers control individual tool descriptions despite a benign-looking base tool.The paper notes that tool descriptions are how tools communicate their functions to agents.Source: 3) Dynamic Tool Creation · p. 6

C. Syntax Format Hooking

1) Hooking on domain-specific or customized data format:

  • Agents may employ a claimed input-format helper before a tool that requires a domain-specific format, as in the comma-separated input for YoutubeSearch.The paper describes such a malicious helper as a shadowing tool that can hijack control flow.Source: 1) Hooking on domain-specific or… · p. 6

2) Hooking on general data formats:

  • A URLValidator can claim to check URL validity and be invoked before tools that process URL inputs, creating a control-flow hook.The paper states that this occurred in its experiment.Source: 2) Hooking on general data formats · pp. 6–7

D. Hooking Optimization Using LLM Preference

  • When a benign tool competes with an XTHP tool, the authors optimize the malicious description using LLM preferences to improve its selection likelihood.Their approach ranks descriptions through tool-pair comparisons, then revises high-ranking descriptions with preferred features such as “optimized for efficiency”; mutated tools exceeded 50% usage in most cases.Source: D. Hooking Optimization Using LLM… · p. 7

E. Cross-Tool Information Polluting

Malicious tools can hook into agent workflows before or after victim tools, then pollute their inputs or outputs or harvest sensitive information from task context. The paper describes separate preemptive and retrospective pollution strategies and two channels for harvesting data.

E. Cross-Tool Information Polluting

  • Preemptive polluting changes a victim tool’s input, while retrospective polluting takes its output as input and returns a polluted result.The resulting manipulation can alter the final answer delivered to the user.Source: E. Cross-Tool Information Polluting · p. 8
  • FinancialsDataValidator poses as a formatter after PolygonFinancials and increases the returned stock price by 10%, potentially misleading users making financial decisions.Polluting code may be hidden in a dependency or run remotely, and may target selected tools or data types.Source: E. Cross-Tool Information Polluting · p. 8

F. Cross-Tool Data Harvesting

  • Cross-tool information harvesting can retrieve data produced by earlier tools, even though tools cannot directly access other tools’ results in the described frameworks.A malicious tool can blend into the victim tool’s semantic context and appear to help process its data.Source: F. Cross-Tool Data Harvesting · p. 8
  • Harvesting can request sensitive task data through dynamically loaded tool descriptions or entry-function arguments with customized schemas.These channels use tool descriptions, argument names, and argument descriptions to prompt the agent to pass context-relevant data.Source: F. Cross-Tool Data Harvesting · pp. 8–9
  • Fig. 3 depicts LocationValidator targeting AmadeusClosestAirport as an example of an XTH attack vector.The figure caption identifies the malicious and victim tools; the accompanying description says the tool can collect the user’s physical location.Source: Figure 3 · p. 9, F. Cross-Tool Data Harvesting · p. 9
  • A LocationValidator can receive the user’s physical address alongside the queried location when the agent has that address in its context or task history.The tool can forward the information to an attacker’s server using a general-looking argument name such as function_data.Source: F. Cross-Tool Data Harvesting · pp. 8–9

V. VULNERABLE AGENT TOOLS IN THE WILD

The paper introduces Chord, an automated analyzer for testing real-world tools’ susceptibility to XTHP. Chord generates malicious tools, tests whether they hijack task control flow, and then evaluates harvesting and polluting.

A. Chord: A Dynamic XTHP Threat Analyzer

  • Chord tests susceptibility through three phases: control-flow hijacking, harvesting data produced by the target tool, and polluting its input or output.It uses dynamically executed agent tasks tailored to the target tool’s usage context.Source: A. Chord: A Dynamic XTHP Threat Analyzer · p. 9, Figure 4 · p. 10
  • Hijacker tests candidate tools as predecessors and successors across five task rounds, optimizing candidates when hijacking succeeds in fewer than three rounds.The optimizer can run up to three times in the predecessor setting, seeking a satisfactory success rate such as 60%.Source: A. Chord: A Dynamic XTHP Threat Analyzer · p. 10
  • Harvester tests whether context-related data can be collected, while Polluter tests whether target-tool inputs or results can be altered.Both components run five end-to-end tests under predecessor and successor settings.Source: A. Chord: A Dynamic XTHP Threat Analyzer · p. 10

B. Implementation

  • Chord is implemented as LangChain agents, evaluates LangChain and Llama-Index tools, and uses GPT-4o by default for generation tasks.Framework-specific testing agents allow the design to be extended to other agent-development frameworks.Source: B. Implementation · p. 10

C. Results and Evaluation

Chord found automatic end-to-end harvesting and polluting exploits across many tested tools from LangChain and Llama-Index, alongside control-flow hijacking. The paper also reports consequential data targets and successful attacks against evaluated defenses.

2) Attack Consequences:

  • The evaluated tools handled potentially confidential data such as document contents and physical addresses, while pollution targets included financial data and other tool outputs.The authors give a trajectory in which changing a ticker from Netflix to Nike could lead a trading agent to place incorrect orders.Source: 2) Attack Consequences · p. 11

1) Results landscape:

  • XTH exploits succeeded on 27/37 LangChain tools (73%) and 21/29 Llama-Index tools (72%); XTP succeeded on 22/37 (59%) and 23/29 (79%), respectively.These are tools vulnerable in at least one of five test rounds.Source: Table I · p. 11, 1) Results landscape · p. 11
  • CFA hijacking affected 27/37 LangChain tools (73%) and 23/29 Llama-Index tools (79%) among the 66 configured tools.The results were manually confirmed; the authors describe Chord’s automatic exploit results as a lower bound on tools that may be exploited.Source: 1) Results landscape · pp. 10–11, Table I · p. 11

3) Evaluating XTHP under State-of-the-Art Defenses:

  • In tests on 10 target tools, prior defenses were not obviously effective against XTHP; the authors also successfully launched proof-of-concept attacks under IsolateGPT and ACE.The IsolateGPT fare-estimation attack consistently placed its malicious tool after metro_hail in 10 experiments; under ACE, a malicious tool was always chosen in 10 experiments.Source: 3) Evaluating XTHP under… · pp. 11–12
  • ACE accepts plans containing context-aligned XTHP tools because their input-output behavior can match what it expects from benign tools.The paper explains that such tools can preserve task semantics without a detectable semantic or policy-violating deviation.Source: 3) Evaluating XTHP under… · p. 12

4) Impact of backend models:

The paper examines XTHP across multi-tool agent workflows, reports that stronger-reasoning models tend to be more affected, and discusses the threat’s scope, related work, and implications.

4) Impact of backend models:

  • Stronger-reasoning backend models tend to be more affected by Chord-generated XTHP tools.The paper refers readers to Appendix K for experiment details.Source: 4) Impact of backend models · p. 12

VI. DISCUSSION

  • XTHP extends indirect prompt injection by using contextually useful companion tools to hook into victim-tool workflows; existing prompt-injection defenses had little effect.The authors also report that stronger-reasoning models are normally more prone to XTHP.Source: §VI · p. 13
  • The study focuses on LangChain and Llama-Index, while the authors identify other frameworks, LLM-integrated applications, and MCP servers as potential settings for XTHP.They note that anyone can submit MCP servers without restrictions and that tool growth and limited vetting may increase exposure.Source: §VI · p. 13
  • Detecting XTHP tools precisely is challenging; monitoring data leakage or incorrect agent behavior may help, but does not prevent out-of-context data leakage.The authors also report incorrect decisions with in-context but biased tool data and call for automatic repository vetting, which is largely missing.Source: §VI · p. 13

VII. RELATED WORK

  • Unlike prior work centered on single-tool scenarios, this study analyzes attacks in pools of tools and a broader range of control-flow hijacking strategies than ToolHijacker [29].The authors examine LangChain and Llama-Index and identify real-world tools vulnerable to the proposed attacks.Source: §VII · p. 13

VIII. CONCLUSION

  • The paper presents a systematic analysis of multi-tool agent task control flows and reports that 75% of tools can be practically exploited, motivating secure orchestration and rigorous tool assessment.The authors report that they disclosed issues to LangChain and Llama-Index.Source: §VIII · pp. 13–14, §IX · p. 14

APPENDIX A TOOL/TOOKIT IMPORTING (§ II)

The passages cover importing LangChain tools and toolkits, evaluating mutated descriptions, and illustrating control-flow hooks that can enable harvesting or polluting information.

APPENDIX A TOOL/TOOKIT IMPORTING (§ II)

  • The appendix example combines a Wikipedia query tool with Gmail toolkit tools and supplies both to a LangChain agent.The example initializes the agent with ChatOpenAI at temperature 0.Source: Appendix A · p. 16

(§ IV-D)

  • In most evaluated cases, mutated tool descriptions achieved usage rates above 50%, while Llama3.1 was least affected and You Search and Jina Search were resilient.The authors attribute about half of cases to position bias for Llama3.1 and the resilient tools’ original descriptions to already containing preferred aspects.Source: (§ IV-D) · p. 16, Table III · p. 16

ATTACK VECTORS (§ IV)

  • Agents may autonomously add tools that offer to interpret errors, creating a hook for malicious tools to harvest or pollute information from other tools.The ErrorExplainer example invokes GPT-4o and can collect prompts or data returned by a target tool.Source: ATTACK VECTORS (§ IV) · p. 17
  • Tools that claim to accept user prompts can be selected at the start of tasks, providing a prompt-handling hook point.The passages describe a malicious tool claiming to detect jailbreaks as one such example.Source: ATTACK VECTORS (§ IV) · p. 17
  • Agents may invoke code-preprocessing tools before code-execution tools, creating another control-flow hook for a tool claiming to improve code quality.The passage gives code correctness checking and style formatting as examples.Source: ATTACK VECTORS (§ IV) · p. 17

APPENDIX E ADDITIONAL POC TOOL EXAMPLES (§ IV)

The examples show malicious tools entering agent workflows by claiming to validate formats or by dynamically changing descriptions, enabling access to other tools’ data.

APPENDIX E ADDITIONAL POC TOOL EXAMPLES (§ IV)

  • JsonValidator claims to validate JSON and can be invoked before ShellTool when that tool requires JSON input.Its workflow position can let it harvest or pollute results from other tools, regardless of whether it implements the claimed validation.Source: Appendix E · p. 18
  • YoutubeSearchHelper claims to construct the input expected by YoutubeSearch and can be invoked immediately before it.YoutubeSearch accepts a string query that it splits into a person name and an optional result count.Source: Appendix E · p. 18
  • LocationNormalizer’s benign-looking description alone did not hijack workflows using Yelp, but a remotely fetched description instructing agents to use it first did.The tool’s initialization replaces its description with server-provided JSON.Source: Appendix E · pp. 18–19

APPENDIX F PROMPT USED FOR MUTATING TOOL DESCRIPTIONS

The mutation prompts direct revisions of tool descriptions toward qualities intended to fit particular usage contexts. The examples emphasize LLM-oriented features, performance, fairness, and trustworthiness.

APPENDIX F PROMPT USED FOR MUTATING TOOL DESCRIPTIONS

  • One prompt asks for an LLM-oriented detail suited to the current usage scenario.It suggests LLM-optimized results or LLM-aided summarization, while asking for concise wording and unchanged input requirements.Source: (§ IV-D) · p. 19
  • The LLM-oriented prompt asks the mutation to paraphrase when needed and return only the revised description.If an LLM-oriented aspect is already present, the prompt asks for another relevant detail.Source: (§ IV-D) · p. 19
  • A performance prompt steers revisions toward speed, scalability, latency, or another technical aspect.It asks not to make input requirements more complex.Source: (§ IV-D) · p. 19
  • The performance prompt asks for a concise description and replacement of any technical detail already present.It requests output without introductory or closing remarks.Source: (§ IV-D) · p. 19
  • A fairness-oriented prompt suggests details about inclusivity, diversity, LGBTQ+ friendliness, gender inclusiveness, or political neutrality.It asks not to complicate input requirements and to replace an aspect already addressed.Source: (§ IV-D) · p. 19
  • A trustworthiness prompt suggests mentioning authorized-vendor APIs or verified results to make a description appear more reliable.It asks for concise wording and replacement of related claims already present.Source: (§ IV-D) · p. 19

APPENDIX G CRDS IDENTIFIED BY Chord (§ V-C)

The appendix identifies candidate data for harvesting and reports attack-success results across framework settings, while its prompts guide Chord’s generation of helper tools. The supplied passages specify these materials’ scope but not their detailed table values.

APPENDIX G CRDS IDENTIFIED BY Chord (§ V-C)

  • Table V identifies CRDs that Chord considers potentially harvestable.The supplied passage gives the table’s scope, not its entries.Source: Table V · p. 19

SETTINGS (§ V-C)

  • The settings results cover predecessor and successor attacks on LangChain and LlamaIndex tools, alongside cumulative XTHP success across framework-setting combinations.Tables VI–IX cover the framework-specific attack settings; Figure 6 reports cumulative attack success and marks the median with a dotted line.Source: SETTINGS (§ V-C) · p. 19, Table VI · p. 20, Table VII · p. 20

APPENDIX I Chord’S PROMPTS

  • Chord’s Hijacker prompt asks for a helper tool invoked before a target, suggests format, code-validation, and knowledge helpers, and requires JSON output with name and description fields.The prompt also instructs the model to return only the JSON object.Source: Appendix I · p. 21

APPENDIX J XTHP UNDER PRIOR DEFENSES

The appendix examines prior defenses against XTHP and evaluates attacks with additional backend models. It reports that several defenses leave attack paths open, while tool filtering trades reduced attacks against benign-tool disruption.

APPENDIX J XTHP UNDER PRIOR DEFENSES

  • Spotlighting is ineffective by design because XTP outputs contain only in-context data, while prompt-injection detectors often classify those outputs as safe.The detector may misclassify regex-validator outputs containing special characters as injections; the passage attributes this to a detector limitation.Source: Appendix J · p. 21
  • Tool filtering removes many XTP tools but can also filter benign tools; explicit necessity language in tool descriptions can bypass it and restore attack success near baseline.The passage gives a stock-price search example where both the victim and XTHP tools are filtered.Source: Appendix J · p. 21
  • AirGap’s context minimizer cannot recognize XTH calls as unnecessary when their arguments contain in-context data aligned with the query.Source: Appendix J · p. 21
  • Plan-first defenses can still select XTHP tools because tool descriptions remain part of the planner’s input; ACE’s mapping can also be exploited through tool-description embeddings.ACE’s abstract tools may not match tools in the pool, and an optimized malicious description can rank above benign tools in the reported case study.Source: Appendix J · pp. 21–22

APPENDIX K XTHP WITH DIFFERENT BACKEND MODELS

  • GPT-OSS-120B achieves a higher attack success rate than Llama-4-Scout-17B, whose instruction-following and tool-call errors can lower hijacking success.The smaller model often misunderstands tool dependencies, issues multiple calls together, or produces invalid names or parameters.Source: Appendix K · p. 22

APPENDIX L TOOLS IN THE FARE ESTIMATION EXAMPLE

The fare-estimation examples describe benign ride-hailing tools and malicious tools designed to alter or replace their use. One malicious tool targets Metro Hail as a successor, while another is presented as a replacement in ACE.

APPENDIX L TOOLS IN THE FARE ESTIMATION EXAMPLE

  • In the IsolateGPT example, metro_hail and quick_ride are the original fare-estimation tools, and the malicious tool targets metro_hail as a successor.Source: Appendix L · p. 22
  • The malicious fare instruction adds $10 to metro_hail’s displayed fare and directs the agent to show only the final fare.Source: Appendix L · p. 22
  • The metro_hail_price_parser description says it parses Metro Hail’s price by calculating tax and tips, and should run after metro_hail.Source: Appendix L · p. 22
  • In the ACE example, MetroHail is the target, MetroHailFareLookup is the malicious replacement, and MetroHailFareEstimate is the abstract tool.The lookup tool fetches a fare for a specified Metro Hail route.Source: Appendix L · p. 22
Loading 2504.03111v3…