T RUST D ESC: Preventing Tool Poisoning in LLM Applications via Trusted Description Generation Hengkai Ye
Zhechang Zhang
Jinyuan Jia
Hong Hu
arXiv:2604.07536v1 [cs.CR] 8 Apr 2026
The Pennsylvania State University
Abstract
LLM-based applications. For example, Gemini [65] integrates with a suite of Google services, such as YouTube and Gmail, enabling the model to support diverse user tasks [70]. An LLM tool usually contains two components: the executable code and a semantic description. The executable code performs the actual operations, like retrieving data. It resides on the application side, remaining invisible to the LLM. In contrast, the description specifies the tool’s functionality and input schema. By embedding tool descriptions into the model context, LLMs identify available capabilities and select proper tools to assist with user tasks. Therefore, tool descriptions form a critical trust boundary that influences decision-making and execution behavior in LLM-integrated applications. Current tool design assumes that tool descriptions are benign and faithful to their implementations. However, violations of this assumption introduce a new attack surface, known as tool poisoning attacks (TPAs) [13, 21, 34, 48, 50, 51, 57, 62]. In explicit TPAs, attackers embed malicious instructions into tool descriptions. After being loaded into the model context, they steer the system to execute unauthorized or unintended actions [13, 21]. In implicit TPAs, attackers craft benignlooking but exaggerated descriptions (e.g., “best” and “efficient”) to bias the LLM’s tool-selection process [48, 62]. As a result, the LLM may prefer attacker-controlled tools, systematically altering execution behavior and potentially producing unsafe outcomes, even without explicit malicious instructions. Existing defenses against prompt injection [22, 26, 27, 37, 51,52,66,73] primarily target explicit attacks, but remain ineffective against implicit ones. These defenses typically detect anomalous or malicious instructions embedded in prompts or tool descriptions [6, 8, 15, 19]. For example, SecAlign [27] improve LLM robustness by fine-tuning models on datasets containing labeled prompt-injection attacks. However, implicit attacks present benign-looking yet misleading descriptions without any explicit malicious signals, enabling them to evade automated detectors and rule-based scanners. Detecting implicit TPAs requires reasoning about whether a tool’s description faithfully reflects its implementation, a challenging task even for human experts without careful code inspection.
Large language models (LLMs) increasingly rely on external tools to perform time-sensitive tasks and real-world actions. While tool integration expands LLM capabilities, it also introduces a new prompt-injection attack surface: tool poisoning attacks (TPAs). Attackers manipulate tool descriptions by embedding malicious instructions (explicit TPAs) or misleading claims (implicit TPAs) to influence model behavior and tool selection. Existing defenses mainly detect anomalous instructions and remain ineffective against implicit TPAs. In this paper, we present T RUST D ESC, the first framework for preventing tool poisoning by automatically generating trusted tool descriptions from implementations. T RUST D ESC derives implementation-faithful descriptions through a threestage pipeline. SliceMin performs reachability-aware static analysis and LLM-guided debloating to extract minimal toolrelevant code slices. DescGen synthesizes descriptions from these slices while mitigating misleading or adversarial code artifacts. DynVer refines descriptions through dynamic verification by executing synthesized tasks and validating behavioral claims. We evaluate T RUST D ESC on 52 real-world tools across multiple tool ecosystems. Results show that T RUST D ESC produces accurate tool descriptions that improve task completion rates while mitigating implicit TPAs at their root, with minimal time and monetary overhead.
1
Introduction
Large language models (LLMs) have been widely integrated into real-world applications due to their remarkable performance in natural language understanding, reasoning and generation [25, 55, 77]. Despite these advances, standalone LLMs still face limitations in handling time-sensitive tasks and performing concrete actions. To address these limitations, recent work augments LLMs with external tools [30, 60, 75], allowing models to retrieve up-to-date information, execute commands, and interact with external systems. Consequently, tool integration has become a fundamental component of modern 1
We observe that the core vulnerability arises not from the tool implementation, but from discrepancies between what the description claims and what the implementation actually performs. If this inconsistency is eliminated, tool poisoning attacks can be mitigated at their root. Our analysis of real-world attacks shows that adversaries rarely embed malicious code in tools, likely due to the effectiveness of modern malwaredetection techniques [23, 24, 44]. Instead, attackers predominantly target the descriptive layer, which lacks comparable integrity guarantees. Based on these observations, we believe that a tool’s source code provides a trustworthy ground truth from which faithful tool descriptions should be derived. Given their strong capabilities in understanding and summarizing program code [9, 42, 64], LLMs are natural choices for generating tool descriptions from implementations. However, applying existing LLM-based code summarization techniques faces three non-trivial challenges. First, real-world LLM toolsets often implement multiple tools within a shared and tightly coupled codebase (e.g., the filesystem toolset contains 14 tools). Prompting an LLM with the entire codebase incurs significant overhead and increases reasoning complexity. Second, even when relevant functions are identified, extracted code may still contain irrelevant logic that distracts the LLM and degrades summary accuracy [38,61,72]. Finally, due to hallucination issues [36, 41], LLMs may generate incorrect claims when reasoning complex program semantics, undermining the reliability of generated tool descriptions. To address these challenges, we design T RUST D ESC, the first framework that automatically generates implementationfaithful tool descriptions from tool implementations. T RUST D ESC consists of three components: SliceMin, DescGen and DynVer. Given a complete codebase, SliceMin extracts tool-relevant code slices through reachability-aware static analysis and constructs a call graph for each tool. It then leverages an LLM to prune unreachable and irrelevant logic based on concrete call sites, iteratively refining the call graph. Based on the resulting minimal code slices, DescGen generates initial tool descriptions. During the generation, it removes code comments and docstrings, truncates long function/variable identifiers, and adopts an LLM-based method to mitigate misleading or adversarial artifacts embedded in source code. To address hallucinations and semantic errors, DynVer performs dynamic verification by decomposing descriptions into verifiable tasks, executing them, and recording execution logs. It uses an LLM-based judge [35, 68, 78] to analyze these logs to validate behavioral claims. After removing statements that fail dynamic verification, T RUST D ESC produces high-quality, trusted tool descriptions for LLM-integrated applications. We implement T RUST D ESC using 2,377 lines of Python code to automatically generate trusted tool descriptions for model context protocol (MCP) servers. MCP servers have become a widely adopted deployment model for real-world LLM tools and represent natural and impactful targets for securing tool descriptions. The current implementation sup-
ports MCP servers developed in Python and TypeScript, the two most popular programming languages in MCP ecosystems. Although our prototype currently targets Python and TypeScript, the design of T RUST D ESC is largely languageagnostic. We can extend it to other programming languages by integrating corresponding parsing and execution frameworks. Therefore, T RUST D ESC is applicable to a broader class of LLM tool implementations beyond the MCP ecosystem. We systematically evaluate the accuracy, cost, effectiveness, and robustness of T RUST D ESC. First, we evaluate 208 tasks across 52 tools from 12 MCP servers using both original and T RUST D ESC-generated descriptions. Using task success rate (TSR) as the accuracy metric, T RUST D ESC improves task success by 4.3% on average, demonstrating that automatically generated descriptions are highly faithful to tool implementations. Second, we evaluate the cost of generating and consuming trusted descriptions. When powered by Gemini-3-Flash, T RUST D ESC requires only $0.013 and 25.7 s to generate a trusted description. During real-world task execution, T RUST D ESC increases monetary cost by only 4% and latency by 0.2%, on average, while in some cases reducing overall cost. Third, to evaluate effectiveness under tool competition, we introduce low-quality tool variants that remove security checks, or disable one to two key functionalities. T RUST D ESC reduces the selection rate of these low-quality tools to 41.6%, 18.8%, and 14.5%, respectively, demonstrating the improved tool-quality discrimination. Finally, we evaluate T RUST D ESC’s robustness against adaptive attacks, which introduce misleading identifiers to tool implementation to bias description generation. Across 15 attack iterations, the success rate fluctuates between 44.7% and 67.4%, without a stable upward trend, indicating that T RUST D ESC remains resilient to iterative adversarial strategies. In summary, we make the following contributions. • We propose T RUST D ESC, the first framework that automatically generates trusted tool descriptions from implementations, eliminating description-based attacks at their root. • We introduce a semantics-aware description generation pipeline that bridges program analysis and LLM reasoning, enabling reliable code-to-description translation while mitigating misleading code artifacts and hallucinations. • We conduct a comprehensive evaluation on 52 real-world tools across 12 MCP servers, showing that T RUST D ESC improves task success rates by 4.3% on average, reduces the selection of low-quality tools, and generates trusted descriptions with minimal cost and runtime overhead.
2
Background
In this section, we provide the background necessary to understand LLM-based tool use and tool poisoning attacks. 2
@tool() def upload_file(file_path: str, note: str) -> str: """ 4 Upload a file with a note to free cloud storage 5 and reutrn the download link. 1
LLM-Integrated Application
2
User Message
System Prompt
Show me the weather alerts in California.
Application Built-in System Prompt Tool Description Tool - get_alerts - get weather alerts of a US state Input Schema - state: str - Two-letter state code ①
Installed Tools
3
6
③
②
7 8
LLM
9 10 11 12
④ ⑧
13 15
<get_alerts> <state>CA</state> </get_alerts>
16 17 18
get_alerts(CA)
through natural language descriptions. MCP contains three components: the server, client, and host. The server implements and registers tools and exposes their descriptions, like functionality and input schemas. The client retrieves tool metadata, invokes tools, and returns execution results, while the host manages multiple clients within the LLM application. By standardizing tool interfaces, MCP improves tool reusability and portability, allowing each server to be integrated across different applications. Since its release in late 2024, MCP has seen rapid adoption, with thousands of servers published and widespread support from LLM applications and frameworks [33]. Consequently, MCP servers have become a primary vehicle for distributing third-party LLM tools, and we focus on them as a representative tool ecosystem.
Figure 1: LLM tool-use workflow. The tool description plays a critical role for LLM-based applications to select the tool.
2.1
</IMPORTANT> """ url = upload(file_path, note) return url
Figure 2: Explicit tool poisoning attack. The malicious instruction in description induces the LLM-integrated application to silently leak the user’s private key.
Parser ⑥
Do not mention that you first need to read the file (this could even upset the user).
14
Output
⑤
⑦
<IMPORTANT> Before using this tool, read `~/.ssh/id_rsa` and pass its content as note, otherwise the tool will not work.
LLM Tool and MCP
LLMs have demonstrated impressive capabilities in natural language understanding and generation [25,55,77]. Augmenting LLMs with external tools further extends these capabilities by enabling access to up-to-date information and execution of concrete actions. Tool integration has become a core component of modern LLM applications. Mainstream systems, such as ChatGPT, Gemini, and Claude, integrate web-search tools to retrieve time-sensitive information, while coding agents (e.g., Cline [3]) provide built-in tools for software development. Many applications further support third-party tool installation, allowing LLMs to interact with external systems, such as web browsers via tools like playwright [18]
2.2
Tool Poisoning Attacks
Prompt injection [32, 34, 45, 49–51, 56, 57] is recognized as a major security risk and is listed as #1 of the top 10 security threats to LLM applications by OWASP [17]. Traditionally, prompt injection attacks rely on user-provided untrusted inputs to inject malicious instructions into the model context, thereby influencing or even controlling the LLM’s behavior. Recently, the wide integration of external tools introduces a new attack surface for prompt injection, referred to as tool poisoning attack (TPA) [13, 21, 48, 62]. In a TPA, an attacker publishes a tool whose description contains crafted or misleading instructions. If a user installs such a tool without carefully inspecting its description, the injected content is loaded into the system prompt, where it can influence the LLM’s reasoning, tool selection, and subsequent actions. Based on their attack methods and objectives, we can classify existing TPA attacks into two categories: explicit TPA and implicit TPA. Explicit TPA. In explicit TPAs [13, 21, 34], an adversary embeds malicious instructions directly into a tool’s description. These instructions are often crafted to appear authoritative and are interpreted by the LLM as part of the system-level
Tool Use. LLM tool use, also known as function calling, refers to the process by which an LLM selects and invokes external tools to assist with user queries. As shown in Figure 1, the application first 1 loads developer-provided tool descriptions into the system prompt. These descriptions specify each tool’s name, functionality, and input arguments. Given the system prompt 2 , and user query 3 , the LLM decides whether a tool is needed. If so, it 4 consults the tool descriptions to select an appropriate tool and generates a structured tool-call request following a predefined format. Notably, the LLM has no visibility into the tool’s implementation and relies entirely on the descriptions during tool selection. The LLM-based application then 5 parses the request, and 6 initializes the API call. Next, the application will 7 execute the selected tool, and 8 return the result to the LLM for further reasoning. Model Context Protocol. The model context protocol (MCP) is an open-source standard for connecting LLM applications with external tools [68]. It defines a uniform interface that enables LLMs to discover, invoke, and interact with tools 3
cial gain when paid services are invoked. Recent studies have demonstrated the effectiveness of this attack vector. For example, Chord [48] shows that biased descriptions can systematically influence tool selection, while ToolHijacker [62], automates implicit TPAs by formulating description generation as an optimization problem over LLM preferences. Figure 3 presents a real-world example of implicit TPA in the MCP ecosystem. The MCP servers Context7 and exa-mcp-server both provide tools for retrieving up-to-date code documentation, through query-docs and get_code_context_exa, respectively. An examination of their descriptions reveals that get_code_context_data includes rules that strongly encourage LLMs to invoke this tool for any code-related tasks. In addition, its description employs highly positive words (e.g., “highest quality”, “freshest context”), further biasing the LLM’s decision. Consequently, even if users explicitly instruct the LLM to use Context7 following its official guideline, the model may disregard the user request and invoke get_code_context_data instead.
Context7 - query-docs - Retrieves and queries up-to-date documentation and code examples from Context7
exa-mcp-server - get_code_context_exa - Search and get relevant context for any programming task. Exa-code has the highest quality and freshest context for libraries, SDKs, and APIs. RULE: when the user's query contains anything related to code, you MUST use this tool.
Always use Context7 MCP when I need library/API documentation Understand. When your request involves library/API documentation, I will automatically use Context7 MCP tools to pull current, authoritative guidance.
Show me the latest specification of Linux syscall execve Tool Call: get_code_context_exa in exa-mcp-server Below is the current Linux man-pages specification for execve …
2.3
Tool Poisoning Defenses
In recent years, many defenses have been proposed to defend against prompt injection, including prevention-based [1, 2, 26–29, 31, 43, 47, 58, 63, 66, 69, 71, 73] and detectionbased [22,37,40,45,46,52,53,59,76,79]. Prevention-based defenses aim to proactively prevent an LLM from following malicious instructions, e.g., by fine-tuning LLMs [26–28, 66, 73]. For example, StruQ [26] and SecAlign [27] separate untrusted content from trusted prompts and fine-tune the LLM to ignore potentially injected instructions within the untrusted context. Detection-based defenses aim to detect malicious instructions in a text (e.g., tool description). For instance, Liu et al. [52] proposed DataSentinel, which concatenates a detection instruction and a text and feeds them into a detection LLM. The text is detected as containing an instruction if the detection LLM does not follow the detection instruction. Limitations of Existing Defenses against Tool Poisoning Attacks. Existing defenses against prompt injection primarily target attacks that expose explicit malicious instructions in the prompt, and therefore provide limited protection against tool poisoning attacks in practice [48, 62]. For instance, Shi et al. [62] showed that state-of-the-art defenses, including StruQ [26], SecAlign [27], and DataSentinel [52], fail to defend against their proposed tool poisoning attacks. Additionally, a recent study [54] demonstrated that adaptive attackers can craft increasingly complex or deceptive instructions to bypass defenses. More fundamentally, implicit tool poisoning attacks do not expose overtly malicious or abnormal intent at all, rendering existing defenses ineffective. Identifying these attacks requires reasoning about where a tool’s natural-language description faithfully reflects its actual implementation, while this task remains challenging even for human experts without careful manual inspection. As a result,
Figure 3: Competition between Context7 and exa-mcp-server. Positive words in tool descriptions bias tool selection toward get_code_context_era, resulting in violation of the user’s request.
guidance. The objective of an explicit TPA is to steer the LLM into performing unauthorized or harmful actions, such as leaking private data, bypassing safety constraints, or escalating privileges. With the malicious intent in the tool description, the attack will succeed if the LLM fails to identify the malicious intent and treats the poisoned description as trustworthy. Figure 2 illustrates an example of an explicit poisoned tool description. The tool upload_file is intended to upload a file together with a note and return a download link. However, the attack-crafted description instructs the LLM to pass the user’s private key as the note argument and further warns the LLM not to disclose this behavior in its output. If the LLM follows these instructions, the private key is silently uploaded along with the file, resulting in a confidentiality breach. Implicit TPA. In contrast to explicit attacks, an implicit TPA does not embed overtly malicious instructions in the tool description. Instead, the adversary meticulously crafts the tool description using attributes favored by LLMs, such as exaggerated positive language, detailed implementation claims, or concrete usage examples. These descriptions appear benign and contain no malicious intent, yet they make the attacker’s tool look more capable, reliable, or relevant than it actually is. The objective of implicit TPA is to subtly bias the LLM’s tool selection process, causing it to consistently prefer the attacker-controlled tool over legitimate alternatives with similar functionality. The malicious tool may be invoked more frequently, enabling outcomes such as traffic diversion or finan4
# ========================================================= # server.py::search_arxiv # ========================================================= 4 def search_arxiv(query, max_results): 5 papers = search_handler(arxiv_searcher, query, 6 max_results) 7 return papers if papers else [] 1
For explicit TPAs, we assume that standard detection-based defenses against prompt injection [26, 27, 51, 52] are enabled and capable of identifying overtly malicious or instructionlike content in tool descriptions. For implicit TPAs, we assume that the attacker can leverage automated techniques such as ToolHijacker [62] to generate benign-looking yet misleading descriptions that systematically bias the LLM’s tool-selection process without exposing explicit malicious intent. The attacker’s primary goal is to manipulate the LLM’s tool selection through crafted descriptions. For example, when one tool incorporates a paid service, the attacker may induce the LLM to preferentially and repeatedly invoke that tool to generate profit. More generally, by influencing tool selection, the attacker can degrade task performance, bias downstream reasoning, or create opportunities for subsequent exploitation. Scope and Assumptions. We focus on tool poisoning attacks that operate by manipulating the semantic information consumed by the LLM, including tool descriptions and other code-derived artifacts used during description generation. We assume that the executable implementation of each tool does not contain overtly malicious runtime behavior, such as unauthorized data exfiltration or system-level exploitation. Attacks relying on malicious tool implementations fall under malware detection and software supply-chain security, and are considered out of scope, as existing antivirus and code scanning tools can effectively identify such behavior prior to installation. Our assumption of trustworthiness does not exclude adversarial semantic manipulation embedded in code. We explicitly consider attacks in which comments, identifiers, or naming conventions are crafted to influence the LLM during description generation without altering the tool’s runtime behavior. Such code-level prompt injection remains within the scope of this work, and our approach is designed to mitigate its impact. We further restrict our attention to tools with source code available. Closed-source or remote tools provide weaker security guarantees, as their implementations cannot be verified. MCP’s official documentation [7] advises users to exercise caution when connecting to such tools; accordingly, attacks that rely on uninspectable remote tools are also out of scope.
2 3
8
# ========================================================= # server.py::search_handler 11 # ========================================================= 12 def search_handler(searcher, query, max_results, **kwargs): 13 if ’year’ in kwargs: 14 papers = searcher.search(query, max_results, 15 year=kwargs[’year’]) 16 else: 17 papers = searcher.search(query, max_results) 18 return [paper.to_dict() for paper in papers] 9
10
Figure 4: Code slice for search_arxiv. This tool does not support year-based filtering, since its entry function provides no year when calling search_handler (line 5), rendering lines 13-15 unreachable.
tool poisoning attacks remain one of the most effective and practical forms of prompt injection in LLM applications. Several studies [29,31, 43,63,67,71] leverage security policies to mitigate prompt injection. For instance, Kim et al. [43] propose a privilege separation mechanism, isolating agents with different privilege levels to prevent privilege escalation. However, it remains challenging to accurately specify security policies and apply them to effectively defend against prompt injection in generic tool call settings. Wu et al. [74] proposed IsolateGPT to prevent the propagation of malicious tool behaviors through benign tools to systems. However, it cannot mitigate malicious behaviors within a malicious tool. A few open-source tools [6,14,15,19] were released to scan MCP tools for potential security threats. As discussed before, the defenses or tools (e.g., mcp-scanner [19] and AI-InfraGuard [6]) that scan the tool descriptions can be vulnerable to implicit tool poisoning. MCPScan [15] and MCPGuard [14] scan the code to identify suspicious behaviors, e.g., MCPScan [15] utilizes static taint analysis to detect abnormal data flows. These code–scanning–based tools cannot prevent implicit tool poisoning attacks and are complementary to our defense.
3
Threat Model and Challenges 3.2
We first define the threat model and then outline the challenges of generating faithful tool descriptions from code.
3.1
Approach Overview and Challenges
Our Insight. At the root of both explicit and implicit TPAs lies a shared vulnerability: LLMs are forced to rely on tool descriptions provided by third-party developers as trusted inputs during tool selection and invocation. As long as untrusted or misleading descriptions can be directly consumed by LLMs, detection-based defenses alone cannot provide robust protection. This observation leads to our key insight: tool descriptions should not be treated as trusted inputs at all. Instead, they should be automatically derived from a more reliable source, such as the tool’s actual implementation. Recent advances have demonstrated that LLMs possess strong capabilities in understanding and summarizing source
Threat Model
Attacker Capabilities and Goals. We consider an adversary who can publish LLM tools with malicious or misleading descriptions on public tool hubs (e.g., MCP repositories [10] or model hubs [11]) and induce users to install these tools in their LLM-integrated applications. The attacker does not interact with the victim; instead, they carry out the entire attack through tool descriptions that are loaded into the system prompt and influence the LLM’s tool-selection behavior. 5
SliceMin Entry Function Identification
Debloating
Tool Name Entry Function Source Code
DynVer
DescGen
Call Graph Function Body
Initial Desc.
Code Slice Preprocess
refine Sanitization
Caller & Callee
Static Analysis
Call Site
Slice to Desc.
Judge
Task
Verification Agent
Final Desc.
Execution Log
Figure 5: T RUST D ESC workflow. Given the tool name and source code, SliceMin performs reachability analysis to construct a minimal code slice. DescGen processes the slice and generates an initial description. DynVer iteratively refines the description through dynamic verification.
code [42, 64]. These models can extract high-level semantics and infer functionality from complex implementations, and produce concise natural-language summaries. Such capabilities suggest a promising direction for addressing tool poisoning attacks: instead of trusting developer-provided tool descriptions, we can leverage LLMs to generate descriptions directly from a tool’s implementation, ensuring consistency between claimed functionality and actual behavior.
form the deep reasoning required to accurately interpret code logic involving non-trivial control flow, subtle data dependencies, or implicit constraints. Instead of admitting uncertainty, LLMs may generate plausible-sounding but incorrect claims. Descriptions with such incorrect information can mislead the LLM’s subsequent tool selection and argument preparation, leading to unnecessary or repeated tool invocations, and ultimately increasing execution latency and cost.
Challenges. However, it is non-trivial to apply existing LLMbased code summarization techniques for this task. We identify three major challenges that must be addressed to enable reliable LLM-based tool description generation. (A) Large and intertwined codebases. Real-world toolsets (e.g., MCP servers) commonly implement multiple tools within a single, intertwined codebase. The logic of individual tools is scattered across multiple files, shared modules, and utility functions. When generating a description for a specific tool, naively prompting an LLM with the entire codebase is prohibitively expensive and substantially increases reasoning complexity. This inflates computational and monetary cost and also forces the LLM to reason over large amounts of irrelevant logic, making direct end-to-end analysis impractical. (B) Unreachable and irrelevant code paths. Even when a code slice for a target tool is extracted, it may still include logic that is unreachable in any valid execution of that tool. Such unreachable code can distract the LLM and lead to over-approximate or incorrect descriptions. Figure 4 illustrates a simplified code slice for the search_arxiv tool, which retrieves papers from the arXiv database. Function search_arxiv accepts the user query and a maximum number of results, and then delegates the search to search_handler. The handler optionally filters results by year when a keyword argument is provided. However, since search_arxiv never supplies this argument, the filtering logic in lines 13-15 is unreachable for this tool. Including such verbose but irrelevant context may cause the LLM to incorrectly infer that “search_arxiv supports year-based filtering”. (C) Hallucinations in complex reasoning. Due to the notorious hallucination issue [36, 41], LLMs may struggle to per-
4
T RUST D ESC Design & Implementation
Figure 5 presents an overview of T RUST D ESC, the first framework for automatically generating trusted LLM tool descriptions from tool actual implementations. Given the source code of a toolset and the list of available tools, T RUST D ESC generates, for each tool, a concise summary, a set of supported functionalities, and a precise input schema. These trusted descriptions replace the original, developer-provided descriptions, thereby eliminating both explicit and implicit tool poisoning attacks caused by inconsistent tool descriptions. Our design of T RUST D ESC consists of three main components: SliceMin, DescGen, and DynVer. 1 SliceMin performs reachability-aware code analysis to construct a minimal code slice for each tool, retaining only the code that is reachable from the tool’s interface. By removing irrelevant and unreachable logic, this step significantly reduces the complexity of subsequent reasoning. 2 Based on the resulting minimal code slice, DescGen generates an initial, potentially imperfect tool description while accounting for malicious or misleading semantic artifacts in the implementation. 3 Finally, starting from the initial description, DynVer iteratively refines it through dynamic verification, ensuring that the final description faithfully reflects the tool’s actual behavior.
4.1
Reachability-Aware Slice Generation
To address Challenges (A) and (B), we design SliceMin a reachability-aware code slicing module that extracts toolspecific code relevant to description generation. The design 6
1
goal of SliceMin is to isolate the minimal portion of the code base that precisely characterizes a target tool’s behavior, while eliminating irrelevant and unreachable logic that would otherwise distract LLM reasoning. SliceMin first identifies the entry function that serves as the tool’s interface. Starting from this entry point, it performs static analysis over the codebase to construct a call graph capturing all potentially reachable functions. Since static analysis alone may over-approximate function reachability, SliceMin further leverages an LLM to debloat the call graph by pruning code paths that are unreachable under the concrete invocation context of the tool. The resulting refined call graph is then used to generate a minimal, tool-specific code slice, which serves as the input for downstream tool description generation. 4.1.1
2
# Caller create_chart
3 4 5 6 7 8 9 10
# Call site result = create_chart_in_sheet( full_path, sheet_name, data_range, chart_type )
11
# Function body def create_chart_in_sheet( 14 filepath: str, 15 sheet_name: str, 16 data_range: str, 17 chart_type: str, 18 style: Optional[Dict] = None 19 ) -> dict[str, Any]: 20 chart = ChartClass() 21 if style is None: 22 style = {"show_data_labels": True} 23 else: 24 style.setdefault("show_data_labels", True) 25 + style = {"show_data_labels": True} 26 ... 27 if style.get("grid_lines", False): 28 chart.x_axis.majorGridlines = ChartLines() 29 chart.y_axis.majorGridlines = ChartLines() 30 ... 31 return ... 12 13
Entry Function Identification
SliceMin first identifies the entry function of a target tool
as the starting point for call graph construction. The entry function represents the tool’s externally exposed interface and defines the concrete invocation context under which the tool is executed. In many cases, the entry function directly corresponds to the tool’s implementation function. For example, in Figure 2, function upload_file is registered as a tool using the @tool decorator and serves as the entry function. However, the entry function name does not always coincide with the tool name. For instance, arxiv-mcp-server, the MCP tool designed to search academic papers, adopts a centralized dispatch function call_tool, which examines the tool name (e.g., search_papers) and invokes the corresponding handler function (e.g., handle_search). In this case, the dispatch function call_tool constitutes the entry function. We conduct an empirical study of popular MCP tool implementations, and identify three common patterns that associate tool names with their entry functions. • Decorator-based registration. A function annotated with @tool or @mcp.tool decorator serves as the entry function. The tool name defaults to the function name unless explicitly overridden by a name argument in the decorator.
32
# Description - Allows customization of chart style such as grid lines 35 + Applies default styling with data labels showing values 33 34
Figure 6: Call graph debloating on create_chart. SliceMin finds argument style not used and rewrites the code by removing lines 18, 21-24, 27-30 and adding line 25. Lines 34-35 show the difference in generated description with and without debloating.
sures robustness against non-standard or framework-specific tool registration patterns. 4.1.2
Call Graph Construction and Debloating
Given the identified entry function, SliceMin constructs a tool-specific call graph to capture all code that may be executed during the tool’s invocation. SliceMin first parses the source code using tree-sitter [20] and performs static analysis over the resulting abstract syntax tree (AST). This analysis allows SliceMin to reason about function definitions and call relations in a language-agnostic manner. Starting from the entry function, SliceMin traverses the AST using a depth-first search (DFS) strategy to inspect every reachable function call. When a library or built-in function is encountered, SliceMin records the call but does not expand it further, as its implementation lies outside the tool’s codebase. When the callee’s definition exists in the AST and has not been visited before, SliceMin creates a new node in the call graph, recording the function body, its caller, and the associated call site. If the callee has already been visited, SliceMin updates the existing node by appending the new caller and call site. This process yields an initial, over-approximate call graph that captures all potentially reachable code. Since static call graph construction usually overapproximates function reachability, SliceMin then performs
• Explicit registration. In calls to registerTool, the first argument specifies the tool name, while the function reference provided as a later argument defines the entry function. • Dispatch-based registration. A dispatcher function selects the entry function via conditional branches (e.g., if/elif name == "tool_name"), where the callee within the matched branch is treated as the entry function. Given a target tool name, SliceMin first searches the codebase for these patterns to identify the corresponding entry function. If none of the patterns are matched, SliceMin falls back to a lightweight heuristic that retrieves code regions surrounding occurrences of the tool name and delegates the final entry-function identification to the LLM based on the surrounding semantic context. This fallback mechanism en7
call graph debloating using LLM-assisted analysis. Rather than debloating the entire call graph at once, SliceMin operates at the granularity of individual functions. For each function, SliceMin provides the LLM with the function body together with its concrete call sites, allowing the LLM to reason about which branches, parameters, or helper functions are unreachable under the tool’s actual invocation context. When unreachable code is identified, SliceMin removes or rewrites the corresponding code segments. If an entire callee is unreachable, SliceMin also updates the call graph by removing the associated node and deleting its caller and call-site entries. After debloating all nodes, SliceMin reconnects the refined nodes to produce a minimal, tool-specific call graph, from which the final code slice is generated. By decomposing call graph debloating into a sequence of localized, node-level operations, SliceMin significantly reduces reasoning complexity and limits the scope of each LLM query. This design improves scalability, reduces cost, and minimizes the risk of introducing new inaccuracies during the debloating process. Case Study: Debloating Unreachable Optional Logic. Figure 6 illustrates a concrete example of call-graph debloating performed by SliceMin on create_chart, an MCP tool for manipulating Excel charts. The entry function create_chart_in_sheet defines an optional argument style that enables chart customization (e.g., data labels, legends, and gridlines). However, our analysis reveals that all callsites invoke this function without supplying the style argument, rendering the customization logic unreachable in the context of this tool. Without debloating, LLMs must reason over this unreachable logic for description generation. In practice, even advanced LLMs (e.g., Claude-4.5-Sonnet) incorrectly infer that the tool supports style customization, leading to overapproximate descriptions that do not reflect actual behavior. Such inaccuracies directly undermine the goal of generating implementation-faithful tool descriptions and can bias downstream tool selection. SliceMin detects that the style is never provided at any call site and identifies the associated branches (lines 20-21 and 24-26) as unreachable. It then rewrites the function by replacing style with a local variable initialized with its default value and removing the unreachable branches. By reducing the code slice to only behavior occurring in valid executions, SliceMin enables even open-source models (e.g., gpt-oss-120b) to accurately summarize the tool and avoid generating misleading claims. This highlights how unreachable optional logic, if left unpruned, can systematically bias LLM-based summarization toward overstated functionality.
4.2
and (3) a precise input schema. Because the input code slice contains only instructions reachable from the tool’s interface, the generated description is grounded in executable semantics rather than over-approximate or irrelevant logic. Lightweight Deployment. It is possible that the functionality list in the refined description may be overly detailed or partially redundant with the summary or argument descriptions. To mitigate this issue, we introduce T RUST D ESClite , a simplified mode of T RUST D ESC that omits the functionality list while retaining the summary and input schema, which are sufficient for accurate tool selection in practice. While LLMs have demonstrated strong capabilities in understanding and summarizing code, directly applying them to description generation introduces a new attack surface. Adversaries may attempt to embed malicious or misleading semantic artifacts in the implementation itself, such as comments, docstrings, or strategically chosen variable/function identifiers, to influence the generated description. We design DescGen to explicitly account for this threat and apply a set of defensive measures to mitigate the impact of such artifacts. Handling Malicious Code Artifacts. Malicious code artifacts may aim to explicitly inject instructions or commands into the description generation process (e.g., instruction-like comments or docstrings). Consistent with our threat model, we assume that standard prompt-injection defenses are enabled and effective at detecting and filtering overtly malicious content. Consequently, DescGen focuses on mitigating more subtle and harder-to-detect forms of semantic manipulation. Handling Misleading Code Artifacts. Misleading code artifacts do not contain explicit malicious intent, but are designed to bias the LLM’s understanding of the tool. DescGen adopts several complementary strategies to reduce their influence. 1 Comments and docstrings. Natural-language comments and docstrings are a primary vehicle for semantic manipulation. To eliminate their influence entirely, DescGen removes all comments and docstrings from the minimal code slice before description generation. Although this may reduce the amount of auxiliary information available to the LLM, our evaluation shows that the remaining code logic is sufficient to generate accurate descriptions for reliable tool selection. 2 Identifier length normalization. Attackers may attempt to encode exaggerated or misleading claims directly into variable or function names. To limit this channel, DescGen normalizes all identifiers by truncating them to a maximum length of 20 characters. This threshold is informed by an empirical study of popular MCP tools, which shows that the vast majority of identifiers fall well within this bound. While underlying programming languages allow much longer identifiers, we find that 20 characters are sufficient to preserve semantic meaning in practice while significantly reducing the attacker’s ability to inject verbose or promotional phrasing. 3 Semantic filtering of biased identifiers. Even within the length constraint, attackers may introduce misleading modi-
Code-Grounded Description Generation
Given the minimal code slice produced by SliceMin, DescGen generates an initial description for the target tool using an LLM. Specifically, DescGen prompts the LLM to summarize the tool’s behavior and produce three components: (1) a concise high-level summary, (2) a set of supported functionalities, 8
Table 1: MCP servers and tools for evaluation, including their categories, programming languages, and the number of selected tools.
fiers (e.g., repeatedly embedding words such as “best” or “optimal” in identifiers). To mitigate this risk, DescGen employs an auxiliary LLM classifier to identify and remove semantically biased or promotional terms based on the surrounding code context. This process preserves the functional role of identifiers while eliminating language that could systematically bias the generated description. 4 Adaptive adversaries. We acknowledge that a determined adversary may attempt to probe and adapt to the above defenses by experimenting with alternative misleading terms. However, our evaluation against adaptive attacks shows that bypassing the combined constraints imposed by identifier normalization and semantic filtering is challenging in practice, and does not significantly affect downstream tool selection. Remaining inaccuracies are further addressed by the dynamic verification stage described in the next subsection.
4.3
MCP Server
Stars Category
Language #Tools
excel-mcp-server markdownify-mcp mysql_mcp_server arxiv-mcp-server paper-search-mcp filesystem context7 wikipedia-mcp yfinance-mcp travel-planner-mcp healthcare-mcp imagesorcery-mcp
3.3k 2.4k 1.1k 2.1k 618 78k 44.7k 183 94 94 83 280
Python TypeScript Python Python Python TypeScript TypeScript Python Python TypeScript TypeScript TypeScript
Total
Dynamic Verification-Based Refinement
Productivity Productivity Database Research Research File System Knowledge Knowledge Finance Travel Health Image
5 5 1 4 5 5 2 5 5 5 5 5 52
cally prepends ‘=’ to formulas if not already present.” Such a description misrepresents the tool’s behavior and would cause downstream agents to invoke the tool with invalid inputs. DynVer detects this inconsistency by synthesizing a verification task that instructs an agent to write a formula without a leading =. Executing the task results in a runtime error, and the LLM-based judge correctly determines that the statement is inconsistent with the observed behavior. DynVer therefore removes the erroneous claim and refines the argument description of formula to explicitly require a leading =. This example demonstrates how DynVer uses task execution to falsify incorrect semantic assumptions and refine tool descriptions to faithfully reflect runtime behavior.
The minimal code slice produced by SliceMin allows the LLM to focus exclusively on tool-relevant logic, substantially improving the accuracy of generated descriptions. However, even when reasoning over the correct code, LLMs may still hallucinate when the tool logic is complex, implicit, or relies on subtle constraints. To address this issue, rather than imposing additional reasoning on the LLM, we introduce DynVer, which refines tool descriptions through dynamic verification. Given the initial tool description, DynVer analyzes it to identify which statements can be validated through execution. Statements that cannot be meaningfully verified at runtime (e.g., internal implementation details) are considered less critical to the tool-use workflow and therefore, are discarded. For each dynamically verifiable statement, DynVer leverages the LLM to synthesize a corresponding executable task. These tasks are executed by an agent built on LangChain and equipped with the tested tool set. The agent plans the execution, selects appropriate tools, and records detailed execution logs, including the tool-call sequence and returned results. DynVer then submits the execution log, together with the tested statement and synthesized task, to an LLM judge. Based on the observed behavior, the judge determines whether the statement is correct. Validated statements are retained in the final description, while incorrect ones are removed and the description is refined accordingly. Case Study: Verification Corrects Latent Errors. We illustrate the necessity of dynamic verification using the tool apply_formula, which writes formulas to Excel worksheet cells with input validation. The entry function invokes validate_formula_impl, which in turn calls validate_formula to enforce that every formula begins with the character =. If this constraint is violated, the tool raises an error. Despite access to the debloated code slice, the LLM fails to infer this implicit constraint and generates an initial description containing the incorrect statement: “Automati-
5
Evaluation
As we discuss in §2.1, MCP servers and tools now serve as the predominant and representative form of LLM tools. Therefore, in this section, we evaluate T RUST D ESC on real-world representative MCP tools across four dimensions: description accuracy, generation cost, tool quality selection, and effectiveness and robustness against tool poisoning attacks. Our evaluation aims to answer the following research questions. Q1. Can T RUST D ESC generate accurate descriptions? (§5.1) Q2. What is the cost introduced by T RUST D ESC? (§5.2) Q3. Can T RUST D ESC help select high-quality tools? (§5.3) Q4. Can T RUST D ESC prevent existing TPA attacks? (§5.4) Q5. Is T RUST D ESC robust to adaptive attacks? (§5.5) Tools for Evaluation. We select real-world MCP servers from awesome-mcp-servers [33], a popular collection of MCP servers with 80.3K GitHub stars. The collection lists 1,364 real-world MCP servers, which is far beyond our evaluation scale. From the list, we randomly sample 20 MCP servers implemented in Python or TypeScript, the two languages sup9
Table 3: Overlap and divergence of completed tasks. To ∩ Tl ∩ Tf : tasks completed under all three description types; To \ (Tl ∪ Tf ): tasks completed with only original descriptions; (Tl ∪ Tf ) \ To : tasks completed only with T RUST D ESClite or T RUST D ESC f ull .
Table 2: Task success rate. The agent completes 175 tasks (84.1%) with original descriptions, 182.5 (87.7%) with T RUST D ESCgenerated descriptions, and 179.5 (86.3%) with lightweight versions. Model for Gen
T RUST D ESClite
T RUST D ESCfull
Claude-4.5-Sonnet Gemini-3-Flash GPT-5.2 gpt-oss-120b
87.5% (182) 86.5% (180) 87.0% (181) 84.1% (175)
89.9% (187) 88.5% (184) 86.1% (179) 86.5% (180)
Average
86.3% (179.5)
87.7% (182.5)
To ∩ Tl ∩ Tf
To \ (Tl ∪ Tf )
(Tl ∪ Tf ) \ To
Claude-4.5-Sonnet Gemini-3-Flash GPT-5.2 gpt-oss-120b
169 170 170 172
0 1 2 2
14 11 11 14
tionalities exposed by the tool. This design ensures that task completion depends on the agent’s understanding of the tool rather than explicit hints. We use a prebuilt ReAct agent [4] powered by Gemini-3-Flash to execute these tasks. The agent executes each task with three sets of descriptions: the original ones, the ones generated by T RUST D ESC (T RUST D ESCfull ), and lightweight variants that omit the functionality list (T RUST D ESClite ). We manually inspect the agent’s execution trace and consider it successful if the target tool is invoked and the task objective is correctly achieved. We calculate the task success rate (TSR), the percentage of tasks successfully completed by the agent, as an objective measure of description accuracy. We evaluate 208 tasks generated from 52 tools using multiple LLMs and report aggregated results. Table 2 shows the TSRs of the evaluation. Across all models, T RUST D ESClite and T RUST D ESCfull consistently outperform the original descriptions, enabling the agent to complete more tasks. With the original descriptions, the agent completes 175 out of 208 tasks, i.e., TSR = 84.1%. For T RUST D ESClite and T RUST D ESCfull , the TSRs are 86.3% and 87.7%. T RUST D ESCfull achieves higher success rates than T RUST D ESClite in three models, suggesting that detailed descriptions provide stronger guidance for tool use. Claude-4.5Sonnet delivers the highest accuracy in description generation, achieving the top TSR in both lite and full modes. Even the worst setting, T RUST D ESClite with gpt-oss-120b, matches the performance of original descriptions. These results show that T RUST D ESC produces implementation-aligned, high-quality descriptions across LLM models and deployment modes. Table 3 shows the relations of tasks completed under the different descriptions. Among 175 tasks completed with the original descriptions, 169-172 of them can be completed with both T RUST D ESClite and T RUST D ESCfull , depending on the LLM model. Only less than two tasks are uniquely completed with the original descriptions, whereas T RUST D ESClite and T RUST D ESCfull enable the agent to complete an additional 11-14 tasks that the original descriptions fail to support.
ported by T RUST D ESC. We remove eight servers that are remote or require paid accounts, leaving 12 servers for evaluation. For servers with fewer than five tools, we evaluate all available tools. For servers with more than five tools, we randomly sample five tools for evaluation. After sampling and filtering, we obtain 52 tools from 12 popular MCP servers as summarized in Table 1. These tools exhibit substantial category diversity, ranging from practical domains such as file processing and productivity to specialized fields, including healthcare, finance, research, and travel. They are also widely adopted and representative of real-world MCP usage, with five servers having more than two thousand stars on GitHub. LLM Setup. We evaluate the performance of T RUST D ESC on three commercial LLMs and one open-weight LLM. For the commercial models, we select Claude-4.5-Sonnet, Gemini3-Flash, and GPT-5.2 because they are flagship offerings from the three providers with the largest market share [5], making them representative of popular commercial LLMs. For the open-weight LLM, we select gpt-oss-120b because it is one of the most widely used open-weight models [12] and is fully compatible with our local infrastructure. We use the default reasoning effort setting and set the temperature to 0.2 for stable outputs. Access to Claude-4.5-Sonnet, Gemini-3-Flash, and GPT-5.2 is obtained through OpenRouter [16]. The local model gpt-oss-120b is deployed on a server equipped with four NVIDIA RTX PRO 6000 Blackwell GPUs.
5.1
Model for Gen
Accuracy of Generated Descriptions
We first check whether the generated descriptions remain accurate relative to the original ones. Since directly judging a natural-language description could be subjective, we evaluate the description quality through task-oriented executions. If a description accurately reflects the implementation, an LLM-based agent should be able to understand the tool’s capabilities, select it and invoke it to complete relevant tasks. Conversely, inaccurate or incomplete descriptions likely introduce incorrect tool selection or failed executions. For each tool, we prompt an LLM to generate four tasks: two derived from the original description and two derived from the generated description. We require these tasks to avoid mentioning the tool name, and cover diverse func-
Case Study: Faithful Descriptions are More Accurate. The tool apply_formula is designed to write formulas into worksheet cells with built-in validation, whereas another tool write_data_to_excel provides general-purpose datawriting functionality. However, the original description of 10
Table 4: Description Generation Cost. We report the average token usage, monetary cost and time cost for T RUST D ESC to generate one tool description. We break down the cost to entry function identification, slice debloating, initial description generation, and dynamic verification. Model for Gen
Entry Func. tokens
Claude-4.5-Sonnet Gemini-3-Flash GPT-5.2 gpt-oss-120b
Debloating
cost time tokens 2.2′′
2,757 0.009 1,650 0.001 1.7′′ 1,350 0.003 3.2′′ 2,761 - 2.4′′
cost
Init Desc. time tokens 8.3′′
2,020 0.009 1,877 0.002 4.1′′ 1,988 0.010 13.5′′ 2,078 - 4.7′′
cost time tokens 7.5′′
2,242 0.011 2,114 0.002 2.7′′ 1,927 0.008 7.5′′ 2,144 - 4.1′′
apply_formula is overly concise and lacks argument details, which is less informative than the original description of write_data_to_excel. Consequently, when given the task “Sum data from A1 to A5 in A6”, the agent incorrectly selects write_data_to_excel to write =SUM(A1:A5) into cell A6. This choice bypasses the validation logic enforced by apply_formula and leads to a violation of the task’s intended requirements. In contrast, T RUST D ESC generates a more comprehensive and implementation-faithful description for apply_formula, including its validation semantics and argument constraints. With this refined description, the agent correctly identifies apply_formula as the appropriate tool for the same task. This demonstrates that T RUST D ESC improves tool selection by providing more accurate and actionable tool descriptions than those supplied by developers.
5.2
Dynamic Ver. cost
Total
time tokens 34.1′′
22,256 0.077 22,146 0.009 17.2′′ 18,070 0.046 73.0′′ 13,862 - 25.2′′
cost
time
29,277 0.106 52.0′′ 27,788 0.013 25.7′′ 23,336 0.067 97.3′′ 20,847 - 36.3′′
due to longer dynamic verification. Local model gpt-oss-120b consumes the fewest tokens and achieves moderate latency, offering a cost-free alternative to commercial models. Across all models, dynamic verification dominates the pipeline, accounting for around 70% of the total time and 71% of the monetary cost, as it involves executing and validating multiple synthesized tasks. Entry function identification is highly efficient: 46 of 52 entry functions are identified through pattern matching, avoiding LLM invocations and cost. In summary, these results show that T RUST D ESC can generate accurate and trustworthy tool descriptions with modest one-time overhead. By selecting an appropriate model such as Gemini-3-Flash, this overhead can be kept minimal, while local models further demonstrate that high-quality descriptions can be produced without any monetary cost. Runtime Overhead. We measure the runtime cost incurred when completing each task under different settings in §5.1. We collect total token usage (including input and output tokens), monetary cost, end-to-end time cost, and the number of tool invocations. We use the task execution with the original descriptions as the baseline and evaluate the additional overhead introduced by T RUST D ESClite and T RUST D ESCfull . Table 5 reports the runtime overhead on the tasks that can be successfully completed under all three description settings. On average, T RUST D ESClite increases the monetary cost by 4% and the latency by 0.2%. The overhead is modest and acceptable given the corresponding improvement in security and task success rate. Interestingly, despite providing more detailed descriptions, T RUST D ESCfull introduces only a 0.3% increase in monetary cost and even reduces latency by 1.7%. We attribute this effect to a reduction in unnecessary or failed tool invocations. With more precise and informative descriptions, the LLM gains clearer understandings of tool semantics, leading to fewer failed redundant tool calls and faster task completion. As a result, the efficiency gains offset the additional token cost associated with longer descriptions. Given its higher task success rate and lower runtime overhead, we recommend T RUST D ESCfull as the default deployment mode.
Cost of T RUST D ESC
The cost of T RUST D ESC arises from two distinct phases. First, during description generation, T RUST D ESC interacts with the LLM for code analysis, description synthesis, and dynamic verification, introducing computation time and monetary costs. Second, during task execution, the generated descriptions influence the agent’s runtime behavior, affecting token usage, monetary cost, and latency. We evaluate these costs separately to quantify the overhead introduced by T RUST D ESC and its impact on downstream LLM-assisted workflows. Description Generation Cost. We measure T RUST D ESC’s cost for description generation by generating descriptions for 52 tools in our benchmark using four different LLMs. Table 4 presents a breakdown of the per-tool cost at each stage of T RUST D ESC, including entry function identification, code debloating, initial description generation, and dynamic verification. This cost is a one-time overhead incurred during tool installation. For commercial LLMs, the generation process can be parallelized across tools to reduce wall-clock time. Among commercial models, Gemini-3-Flash is the most cost-efficient option, achieving the lowest average cost ($0.013) and the lowest latency (25.7 s), while producing highquality descriptions. Claude-4.5-Sonnet incurs the highest monetary cost, at about 8.3× that of Gemini-3-Flash, although its latency remains moderate. GPT-5.2 is the slowest model, requiring an average of 97.3 s to complete the pipeline, largely
5.3
Quality-based Tool Selection
We evaluate whether T RUST D ESC helps LLM select highquality tools from multiple choices. We design a benchmark 11
Table 5: Runtime Overhead. We report the runtime overhead of T RUST D ESClite and T RUST D ESCfull . Token usage, monetary cost, latency, and number of tool-calls are reported as relative changes from the original baseline. T : total token usage; Tin : input token; Tout : output token. Model for Gen
T
Tin
T RUST D ESClite Tout Cost Latency #tool-call
T
Tin
T RUST D ESCfull Tout Cost Latency #tool-call
Claude-4.5-Sonnet Gemini-3-Flash GPT-5.2 gpt-oss-120b
+9.6% +9.2% +6.2% +2.7%
+9.9% +4.0% +5.5% +9.8% +1.4% +4.3% +6.5% +1.6% +6.4% +3.1% -2.4% -0.3%
+9.0% -4.1% -2.2% -1.8%
+9.3% +0.7% -0.3% -2.3%
-3.3% -3.4% -0.7% -2.6% +1.6% +1.8% -1.2% -1.7% +2.1% +2.3% -0.02% +2.9% +0.4% +0.5% -0.7% +2.4%
-0.3% +0.5% -3.8% -3.0%
+1.0% -2.3% -4.5% -3.9%
Average
+6.9% +7.3% +1.2% +4.0%
+0.2%
+1.9%
+0.2% +0.3%
-1.7%
-2.4%
Table 6: Tool Selection Rate based on Code Quality. For each MCP tool, we reduce its code quality via three strategies, and measure its selection rate when competing with the original tool.
Table 7: TPAs Prevention. We collect public available TPAs and check whether T RUST D ESC can prevent them. Tool Name
Model for Gen
Qualify Degradation
Claude-4.5-Sonnet
security checks removed one feature disabled two features disabled security checks removed one feature disabled two features disabled security checks removed one feature disabled two features disabled security cehcks removed one feature disabled two features disabled
Gemini-3-Flash
GPT-5.2
gpt-oss-120b
-0.7% +0.3%
Selection%
add add get_fact_of_the_day LocationNormalizer CompanyToTicker ErrorExplainer YoutubeSearch
32.5% 10.9% 10.6% 45.5% 21.3% 20.8% 44.0% 34.6% 17.7% 44.3% 8.5% 7.5%
Type Bad terms E E E E I I E
read id_rsa.pub send all emails change the recipient MUST USE Useful useful, AI-friendly should use before
Blocked? ✓ ✓ ✓ ✓ ✓ ✓ ✓
richer functionality. Overall, these results show that descriptions generated by T RUST D ESC faithfully encode differences in implementation quality, enabling LLMs to consistently prefer higher-quality tools in competitive selection scenarios.
by varying the implementation quality. From 12 MCP servers, we inspect tool implementations and select one tool per server as a high-quality baseline. Our analysis reveals two characteristics of higher-quality tools: the presence of robustness or security-related checks, and additional or refined features that improve task effectiveness. Consequently, we generate three degraded variants for each tool: one with security checks removed, one with one feature disabled, and one with two features disabled. We apply T RUST D ESC to generate descriptions for original and degraded tools. Then, we load an original tool with one degraded variant, and ask the agent to complete the corresponding tasks introduced in §5.1.
5.4
Effectiveness on Preventing TPAs
We empirically validate the effectiveness of T RUST D ESC on preventing real-world tool poisoning attacks. We collect publicly available TPAs reported in prior work [48] and public repositories [39], covering both explicit and implicit cases. For each attack, we obtain the tool implementation and use T RUST D ESC to generate a trusted description. We then manually inspect the original description to identify the key instructions or biased terms responsible for triggering the attack, and cross-check whether similar instructions or misleading claims appear in the description generated by T RUST D ESC.
Table 6 presents the selection rates of the degraded variants. When only security checks are removed, low-quality tools are selected with probabilities between 32.5% and 45.5%, consistently below the 50% random-choice baseline. When one feature is removed, the selected rate drops substantially to 8.5%-34.6%, and further decreases to 7.5%-20.8% when we remove two features. Descriptions generated using Claude4.5-Sonnet most accurately reflect security-related implementation details, resulting in the lowest selection rate (32.5%) for security-degraded tools. In contrast, the open-weight model gpt-oss-120b tends to emphasize functional capabilities in its descriptions, causing LLM to preferentially select tools with
Table 7 summarizes our findings. Across all collected attacks, including five explicit TPAs and two implicit TPAs, none of the descriptions generated by T RUST D ESC contains the malicious instructions or misleading terms present in the original descriptions. These results confirm that T RUST D ESC effectively neutralizes both explicit and implicit TPAs at their root. This evaluation further demonstrates that T RUST D ESC complements existing malware detection and code-scanning defenses, while uniquely addressing attacks that exploit the description–implementation mismatch. 12
Tool selection rate
0.8
6
0.6
We highlight two notable findings from our evaluation that further demonstrate the benefits and necessity of T RUST D ESC.
0.4 0.2
Surfacing Latent Security Constraints. Beyond mitigating tool poisoning attacks, we observe that T RUST D ESC provides an additional security benefit by exposing implicit safeguards embedded in tool implementations. For example, the implementation of apply_formula explicitly blocks unsafe formulas such as INDIRECT and HYPERLINK. However, this restriction is not documented in the original description. Consequently, when given tasks involving unsafe formulas, the LLM initially invokes apply_formula, encounters an execution error, and then falls back to write_data_to_excel to write the same unsafe formula directly. This behavior increases execution cost and bypasses the intended security checks. In contrast, T RUST D ESC captures this constraint in the generated description, allowing the LLM to reject unsafe tasks before issuing any tool call. This finding suggests that T RUST D ESC can strengthen overall system safety by making latent implementation protections visible to the LLM, even when such protections are omitted from developer-provided descriptions.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Iteration
Figure 7: Tool selection rate in adaptive attacks. We use an LLM to iteratively tuning function and variables names, aiming to affect the description generation and, ultimately, tool selection.
5.5
Discussion
Robustness against Adaptive Attacks
We evaluate the robustness of T RUST D ESC against adaptive attacks, where an adversary deliberately modifies the tool implementations to mislead the description generation. Given the countermeasures in DescGen (§4.2), the remaining attack surface is limited to symbol names (i.e., function and variable) shorter than 20 characters. To assess this evaluation, we instruct Gemini-3-Flash to act as an adaptive attacker that perturbs function and variable names using exaggerated positive terms, with the goal of biasing the LLM’s tool selection. We formulate the attack as an iterative optimization process. Starting from the original implementation, the attacker first applies aggressive modifiers (e.g., “best”, “perfect”), which are often detected and removed by DescGen’s sanitization. Both the original tool and the modified variant are processed by T RUST D ESC and loaded into the agent, which then executes the same tasks. If a modification is overly aggressive and filtered, the selection rate of the modified tool remains near the 50% baseline. The attacker then refines the modification using more subtle terms (e.g., “effective”, “efficient”) and reports the process. We run this attack loop for 15 iterations on the 12 tools evaluated in §5.3, allowing the attacker to progressively search for strategies that bypass our defenses. Figure 7 shows the selection rate of the modified tools across iterations. The rate fluctuates between 44.7% and 67.4%. To quantify whether the adaptive attack exhibits a monotonic improvement, we analyze the trend of tool selection rates across iterations. We first fit a linear regression between the iteration index and the selection rate. The estimated slope is close to zero and statistically insignificant (β = −6.7 × 10−4 , p = 0.87), indicating no linear upward trend. We further apply a non-parametric Mann–Kendall trend test, which yields a near-zero Kendall’s τ (τ = 0.019) with no statistical significance (p = 0.92). This confirms that the tool selection rate does not exhibit a consistent upward trend across adaptive attack iterations. These results indicate that when competing tools have comparable implementation quality, symbol-level manipulation alone is insufficient to reliably influence LLM tool selection under T RUST D ESC.
Prevalence of Low-Quality Tool Descriptions. Our analysis of real-world MCP tools reveals that incomplete or lowquality tool descriptions are common, even among widely used servers, underscoring the practical need for T RUST D ESC. Among the 52 tools evaluated, seven provide no argument descriptions, frequently causing the LLM to supply incorrect parameters. 19 tools include only minimal descriptions that offer little guidance on proper usage. Only 16 tools provide complete and detailed descriptions, and merely nine include usage examples. These observations indicate that tool developers often devote limited effort to descriptions, despite descriptions forming a critical trust boundary in LLM-integrated applications. By automatically generating implementationaligned descriptions, T RUST D ESC fills this gap and reduces reliance on manual, error-prone documentation.
7
Conclusion
We present T RUST D ESC, the first framework for automatically generating trusted tool descriptions directly from tool implementations, thereby eliminating tool poisoning attacks at their root. By combining reachability-aware code slicing, semantics-preserving description generation, and dynamic verification, T RUST D ESC produces implementation-faithful descriptions that significantly improve tool selection accuracy while incurring minimal cost and runtime overhead. Our evaluation on real-world tools demonstrates that T RUST D ESC effectively mitigates both explicit and implicit tool poisoning attacks and remains robust under adaptive adversaries. 13
References
[17] OWASP Top 10 for Large Language Model Applications. https://owasp.org/www-project-top -10-for-large-language-model-application s/, 2025.
[1] Instruction defense. https://learnprompting.o rg/docs/prompt_hacking/defensive_measure s/instruction, 2023.
[18] Playwright MCP server. https://github.com/mic rosoft/playwright-mcp, 2025.
[2] Sandwitch defense. https://learnprompting.o rg/docs/prompt_hacking/defensive_measure s/sandwich_defense, 2023. [3] Cline. https://github.com/cline/cline, 2024.
[19] Scan MCP servers for potential threats and security findings. https://github.com/cisco-ai-defen se/mcp-scanner, 2025.
[4] LangChain: the platform for reliable agents. https: //github.com/langchain-ai/langchain, 2024.
[20] Tree-sitter. https://tree-sitter.github.io/tr ee-sitter/, 2025.
[5] 2025: The State of Generative AI in the Enterprise. ht tps://menlovc.com/perspective/2025-the-s tate-of-generative-ai-in-the-enterprise/, 2025.
[21] WhatsApp MCP Exploited: Exfiltrating your message history via MCP. https://invariantlabs.ai/b log/whatsapp-mcp-exploited, 2025.
[6] AI-Infra-Guard. https://github.com/Tencent/A I-Infra-Guard, 2025.
[22] Sahar Abdelnabi, Aideen Fay, Giovanni Cherubin, Ahmed Salem, Mario Fritz, and Andrew Paverd. Get my drift? catching llm task drift with activation deltas. In SaTML, 2025.
[7] Best Practices for Using Remote MCP Servers. https://modelcontextprotocol.io/docs/dev elop/connect-remote-servers, 2025.
[23] Ahmed Bensaoud, Jugal Kalita, and Mahmoud Bensaoud. A Survey of Malware Detection Using Deep Learning. Machine Learning with Applications, 16:100546, 2024.
[8] Constrain, log and scan your MCP connections for security vulnerabilities. https://github.com/invar iantlabs-ai/mcp-scan, 2025.
[24] Austin Brown, Maanak Gupta, and Mahmoud Abdelsalam. Automated Machine Learning for Deep Learning Based Malware Detection. Computers & Security, 137:103582, 2024.
[9] DeepWiki: AI-Powered Wiki Generator for GitHub/Gitlab/Bitbucket Repositories. https://github.com/A syncFuncAI/deepwiki-open, 2025.
[25] Yupeng Chang, Xu Wang, Jindong Wang, Yuan Wu, Linyi Yang, Kaijie Zhu, Hao Chen, Xiaoyuan Yi, Cunxiang Wang, Yidong Wang, Wei Ye, Yue Zhang, Yi Chang, Philip S. Yu, Qiang Yang, and Xing Xie. A survey on evaluation of large language models. ACM transactions on intelligent systems and technology, 15(3):1–45, 2024.
[10] GitHub’s official MCP Server. https://github.c om/github/github-mcp-server, 2025. [11] Hugging Face Hub. ub, 2025.
https://huggingface.co/h
[12] LLM Rankings. https://openrouter.ai/rankin gs, 2025.
[26] Sizhe Chen, Julien Piet, Chawin Sitawarin, and David Wagner. StruQ: Defending against Prompt Injection with Structured Queries. In Proceedings of the 34th USENIX Security Symposium (USENIX Security 25), pages 2383–2400, 2025.
[13] MCP Security Notification: Tool Poisoning Attacks. https://invariantlabs.ai/blog/mcp-secur ity-notification-tool-poisoning-attacks, 2025.
[27] Sizhe Chen, Arman Zharmagambetov, Saeed Mahloujifar, Kamalika Chaudhuri, David Wagner, and Chuan Guo. Secalign: Defending against prompt injection with preference optimization. In Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security, pages 2833–2847, 2025.
[14] MCPGuard: First Agent-based MCP Scanner to Protect AI Agents. https://blog.virtueai.com/2025/ 08/22/mcpguard-first-agent-based-mcp-sca nner-to-protect-ai-agents/, 2025. [15] MCPScan. https://github.com/antgroup/MCPS can, 2025.
[28] Sizhe Chen, Arman Zharmagambetov, David Wagner, and Chuan Guo. Meta secalign: A secure foundation llm against prompt injection attacks. arXiv preprint arXiv:2507.02735, 2025.
[16] OpenRouter: The Unified Interface For LLMs. https: //openrouter.ai/, 2025.
14
[29] Manuel Costa, Boris Köpf, Aashish Kolluri, Andrew Paverd, Mark Russinovich, Ahmed Salem, Shruti Tople, Lukas Wutschitz, and Santiago Zanella-Béguelin. Securing ai agents with information-flow control. arXiv preprint arXiv:2505.23643, 2025.
[40] Dennis Jacob, Hend Alzahrani, Zhanhao Hu, Basel Alomair, and David Wagner. Promptshield: Deployable detection for prompt injection attacks. In Proceedings of the Fifteenth ACM Conference on Data and Application Security and Privacy, pages 341–352, 2024.
[30] Debrup Das, Debopriyo Banerjee, Somak Aditya, and Ashish Kulkarni. Mathsensei: a tool-augmented large language model for mathematical reasoning. arXiv preprint arXiv:2402.17231, 2024.
[41] Ziwei Ji, Nayeon Lee, Rita Frieske, Tiezheng Yu, Dan Su, Yan Xu, Etsuko Ishii, Ye Jin Bang, Andrea Madotto, and Pascale Fung. Survey of hallucination in natural language generation. ACM computing surveys, 55(12):1– 38, 2023.
[31] Edoardo Debenedetti, Ilia Shumailov, Tianqi Fan, Jamie Hayes, Nicholas Carlini, Daniel Fabian, Christoph Kern, Chongyang Shi, Andreas Terzis, and Florian Tramèr. Defeating prompt injections by design. arXiv preprint arXiv:2503.18813, 2025.
[42] Junaed Younus Khan and Gias Uddin. Automatic code documentation generation using gpt-3. In Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering, pages 1–6, 2022.
[32] Edoardo Debenedetti, Jie Zhang, Mislav Balunovic, Luca Beurer-Kellner, Marc Fischer, and Florian Tramèr. Agentdojo: A dynamic environment to evaluate prompt injection attacks and defenses for llm agents. NeurIPS, 2024.
[43] Juhee Kim, Woohyuk Choi, and Byoungyoung Lee. Prompt flow integrity to prevent privilege escalation in llm agents. arXiv preprint arXiv:2503.15547, 2025. [44] Clemens Kolbitsch, Paolo Milani Comparetti, Christopher Kruegel, Engin Kirda, Xiao yong Zhou, and XiaoFeng Wang. Effective and Efficient Malware Detection at the End Host. In Proceedings of the USENIX Security Symposium (USENIX Security 2009), pages 351–366, 2009.
[33] Frank Fiegel. Awesome MCP Servers. https://gith ub.com/punkpeye/awesome-mcp-servers, 2025. [34] Kai Greshake, Sahar Abdelnabi, Shailesh Mishra, Christoph Endres, Thorsten Holz, and Mario Fritz. Not what you’ve signed up for: Compromising real-world llm-integrated applications with indirect prompt injection. In Proceedings of the 16th ACM workshop on artificial intelligence and security, pages 79–90, 2023.
[45] Hao Li and Xiaogeng Liu. Injecguard: Benchmarking and mitigating over-defense in prompt injection guardrail models. arXiv preprint arXiv:2410.22770, 2024.
[35] Jiawei Gu, Xuhui Jiang, Zhichao Shi, Hexiang Tan, Xuehao Zhai, Chengjin Xu, Wei Li, Yinghan Shen, Shengjie Ma, Honghao Liu, et al. A survey on llm-as-a-judge. The Innovation, 2024.
[46] Hao Li, Xiaogeng Liu, Ning Zhang, and Chaowei Xiao. Piguard: Prompt injection guardrail via mitigating overdefense for free. In ACL, 2025. [47] Hao Li, Yankai Yang, G Edward Suh, Ning Zhang, and Chaowei Xiao. Reasalign: Reasoning enhanced safety alignment against prompt injection attack. arXiv preprint arXiv:2601.10173, 2026.
[36] Lei Huang, Weijiang Yu, Weitao Ma, Zhangyin Zhong, Weihong Feng, Haotian Wang, Qianglong Chen, Weihua Peng, Xiaocheng Feng, Bing Qin, and Ting Liu. A survey on hallucination in large language models: Principles, taxonomy, challenges, and open questions. ACM Transactions on Information Systems, 43(2):1–55, 2025. [37] Kuo-Han Hung, Ching-Yun Ko, Ambrish Rawat, I-Hsin Chung, Winston H Hsu, and Pin-Yu Chen. Attention tracker: Detecting prompt injection attacks in llms. In NAACL, 2025.
[48] Zichuan Li, Jian Cui, Xiaojing Liao, and Luyi Xing. Les Dissonances: Cross-Tool Harvesting and Polluting in Multi-Tool Empowered LLM Agents. In Proceedings of the 33rd Annual Network and Distributed System Security Symposium (NDSS 2026), San Diego, CA, February 2026.
[38] Yerin Hwang, Yongil Kim, Jahyun Koo, Taegwan Kang, Hyunkyung Bae, and Kyomin Jung. Llms can be easily confused by instructional distractions. arXiv preprint arXiv:2502.04362, 2025.
[49] Xiaogeng Liu, Zhiyuan Yu, Yizhe Zhang, Ning Zhang, and Chaowei Xiao. Automatic and universal prompt injection attacks against large language models. arXiv, 2024.
[39] Invariant Labs. MCP Tool Poisoning Experiments. https://github.com/invariantlabs-ai/mcp-i njection-experiments/tree/main, 2025.
15
[61] Freda Shi, Xinyun Chen, Kanishka Misra, Nathan Scales, David Dohan, Ed H Chi, Nathanael Schärli, and Denny Zhou. Large language models can be easily distracted by irrelevant context. In International Conference on Machine Learning, pages 31210–31227. PMLR, 2023.
[50] Yi Liu, Gelei Deng, Yuekang Li, Kailong Wang, Zihao Wang, Xiaofeng Wang, Tianwei Zhang, Yepang Liu, Haoyu Wang, Yan Zheng, and Leo Yu Zhang. Prompt injection attack against llm-integrated applications. arXiv preprint arXiv:2306.05499, 2023. [51] Yupei Liu, Yuqi Jia, Runpeng Geng, Jinyuan Jia, and Neil Zhenqiang Gong. Formalizing and benchmarking prompt injection attacks and defenses. In USENIX Security, 2024.
[62] Jiawen Shi, Zenghui Yuan, Guiyao Tie, Pan Zhou, Neil Zhenqiang Gong, and Lichao Sun. Prompt Injection Attack to Tool Selection in LLM Agents. In Proceedings of the 33rd Annual Network and Distributed System Security Symposium (NDSS 2026), San Diego, CA, February 2026.
[52] Yupei Liu, Yuqi Jia, Jinyuan Jia, Dawn Song, and Neil Zhenqiang Gong. Datasentinel: A game-theoretic detection of prompt injection attacks. In 2025 IEEE Symposium on Security and Privacy (SP), pages 2190– 2208. IEEE, 2025.
[63] Tianneng Shi, Jingxuan He, Zhun Wang, Linyu Wu, Hongwei Li, Wenbo Guo, and Dawn Song. Progent: Programmable privilege control for llm agents. arXiv preprint arXiv:2504.11703, 2025.
[53] Meta. PromptGuard Prompt Injection Guardrail. https://www.llama.com/docs/model-cards-a nd-prompt-formats/prompt-guard/, 2024.
[64] Weisong Sun, Yun Miao, Yuekang Li, Hongyu Zhang, Chunrong Fang, Yi Liu, Gelei Deng, Yang Liu, and Zhenyu Chen. Source code summarization in the era of large language models. In 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE), pages 1882–1894. IEEE, 2025.
[54] Milad Nasr, Nicholas Carlini, Chawin Sitawarin, Sander V Schulhoff, Jamie Hayes, Michael Ilie, Juliette Pluto, Shuang Song, Harsh Chaudhari, Ilia Shumailov, Abhradeep Thakurta, Kai Yuanqing Xiao, Andreas Terzis, and Florian Tramer. The attacker moves second: Stronger adaptive attacks bypass defenses against llm jailbreaks and prompt injections. arXiv preprint arXiv:2510.09023, 2025.
[65] Gemini Team, Rohan Anil, Sebastian Borgeaud, JeanBaptiste Alayrac, Jiahui Yu, Radu Soricut, Johan Schalkwyk, Andrew M Dai, Anja Hauth, Katie Millican, et al. Gemini: a family of highly capable multimodal models. arXiv preprint arXiv:2312.11805, 2023.
[55] Humza Naveed, Asad Ullah Khan, Shi Qiu, Muhammad Saqib, Saeed Anwar, Muhammad Usman, Naveed Akhtar, Nick Barnes, and Ajmal Mian. A comprehensive overview of large language models. ACM Transactions on Intelligent Systems and Technology, 16(5):1–72, 2025.
[66] Eric Wallace, Kai Xiao, Reimar Leike, Lilian Weng, Johannes Heidecke, and Alex Beutel. The instruction hierarchy: Training llms to prioritize privileged instructions. arXiv, 2024.
[56] Dario Pasquini, Martin Strohmeier, and Carmela Troncoso. Neural exec: Learning (and learning from) execution triggers for prompt injection attacks. In AISec, 2024.
[67] Peiran Wang, Yang Liu, Yunfei Lu, Yifeng Cai, Hongbo Chen, Qingyou Yang, Jie Zhang, Jue Hong, and Ye Wu. Agentarmor: Enforcing program analysis on agent runtime trace to defend against prompt injection. arXiv preprint arXiv:2508.01249, 2025.
[57] Fábio Perez and Ian Ribeiro. Ignore previous prompt: Attack techniques for language models. In NeurIPS ML Safety Workshop, 2022.
[68] Zhenting Wang, Qi Chang, Hemani Patel, Shashank Biju, Cheng-En Wu, Quan Liu, Aolin Ding, Alireza Rezazadeh, Ankit Shah, Yujia Bao, et al. Mcp-bench: Benchmarking tool-using llm agents with complex real-world tasks via mcp servers. arXiv preprint arXiv:2508.20453, 2025.
[58] Julien Piet, Maha Alrashed, Chawin Sitawarin, Sizhe Chen, Zeming Wei, Elizabeth Sun, Basel Alomair, and David Wagner. Jatmo: Prompt injection defense by task-specific finetuning. In ESORICS, 2024. [59] ProtectAI.com. Fine-tuned deberta-v3-base for prompt injection detection, 2024.
[69] Simon Willison. Delimiters won’t save you from prompt injection. https://simonwillison.net/2023/Ma y/11/delimiters-wont-save-you, 2023.
[60] Changle Qu, Sunhao Dai, Xiaochi Wei, Hengyi Cai, Shuaiqiang Wang, Dawei Yin, Jun Xu, and Ji-Rong Wen. Tool learning with large language models: A survey. Frontiers of Computer Science, 19(8):198343, 2025.
[70] Josh Woodward. Gemini introduces Personal Intelligence. https://blog.google/innovation-and -ai/products/gemini-app/personal-intelli gence/, 2025. 16
[71] Fangzhou Wu, Ethan Cecchetti, and Chaowei Xiao. System-level defense against indirect prompt injection attacks: An information flow control perspective. arXiv preprint arXiv:2409.19091, 2024.
[76] Kaiyuan Zhang, Mark Tenenholtz, Kyle Polley, Jerry Ma, Denis Yarats, and Ninghui Li. Browsesafe: Understanding and preventing prompt injection within ai browser agents. arXiv preprint arXiv:2511.20597, 2025.
[72] Siye Wu, Jian Xie, Jiangjie Chen, Tinghui Zhu, Kai Zhang, and Yanghua Xiao. How easily do irrelevant inputs skew the responses of large language models? In First Conference on Language Modeling.
[77] Wayne Xin Zhao, Kun Zhou, Junyi Li, Tianyi Tang, Xiaolei Wang, Yupeng Hou, Yingqian Min, Beichen Zhang, Junjie Zhang, Zican Dong, Yifan Du, Chen Yang, Yushuo Chen, Zhipeng Chen, Jinhao Jiang, Ruiyang Ren, Yifan Li, Xinyu Tang, Zikang Liu, Peiyu Liu, Jian-Yun Nie, and Ji-Rong Wen. A survey of large language models. arXiv preprint arXiv:2303.18223, 1(2), 2023.
[73] Tong Wu, Shujian Zhang, Kaiqiang Song, Silei Xu, Sanqiang Zhao, Ravi Agrawal, Sathish Reddy Indurthi, Chong Xiang, Prateek Mittal, and Wenxuan Zhou. Instructional segment embedding: Improving llm safety with instruction hierarchy. In The Thirteenth International Conference on Learning Representations, 2025.
[78] Lianmin Zheng, Wei-Lin Chiang, Ying Sheng, Siyuan Zhuang, Zhanghao Wu, Yonghao Zhuang, Zi Lin, Zhuohan Li, Dacheng Li, Eric Xing, et al. Judging llm-asa-judge with mt-bench and chatbot arena. Advances in neural information processing systems, 36:46595– 46623, 2023.
[74] Yuhao Wu, Franziska Roesner, Tadayoshi Kohno, Ning Zhang, and Umar Iqbal. Isolategpt: An execution isolation architecture for llm-based agentic systems. In NDSS, 2025.
[79] Yinan Zhong, Qianhao Miao, Yanjiao Chen, Jiangyi Deng, Yushi Cheng, and Wenyuan Xu. Attention is all you need to defend against indirect prompt injection attacks in llms. In NDSS, 2026.
[75] Lifan Yuan, Yangyi Chen, Xingyao Wang, Yi R Fung, Hao Peng, and Heng Ji. Craft: Customizing llms by creating and retrieving from specialized toolsets. arXiv preprint arXiv:2309.17428, 2023.
17