ShareLock: A Stealthy Multi-Tool Threshold
Poisoning Attack Against MCP
June 25, 2026
Abstract
With the rapid evolution of LLM-driven agents, Model Context Protocol (MCP), an open protocol bridging LLMs with external tools, has quickly become foundational to modern agent ecosystems. However, the expanding adoption of MCP has also introduced novel security concerns such as Tool Poisoning Attack(TPA), which exploit LLM-server interactions to inject malicious prompts. Existing poisoning schemes typically adopt a monolithic plaintext embedding paradigm, which fails to withstand manual inspection or automated detectors. Current research still lacks a systematic analysis on multi-tool poisoning, where multiple tools can be exploited cooperatively to disperse detection risk. In this paper, we introduce ShareLock, a multi-tool threshold poisoning framework that utilizes Shamir’s threshold scheme to ensure exceptional stealth and fault tolerance. ShareLock distributes the malicious instruction as benign-looking secret shares across multiple tool descriptions, achieving both information-theoretic secrecy and attack robustness against moderate auditing. After a covert reconstruction trigger is planted during server update, the aggregated shares reconstruct the hidden instruction, resulting in critical breaches of system assets or private data. To evaluate the realistic threat of ShareLock, we constructed a comprehensive benchmark encompassing four multi-tool scenarios and conducted extensive experiments across mainstream LLMs on two distinct MCP clients. Our results demonstrate that ShareLock significantly outperforms existing single-tool poisoning strategies in tool description-based detection while maintaining an average attack success rate exceeding 90%.
<ccs2012> <concept> <concept_id>10010147.10010178.10010219.10010221</concept_id> <concept_desc>Computing methodologies Intelligent agents</concept_desc> <concept_significance>500</concept_significance> </concept> <concept> <concept_id>10002978.10002979.10002984</concept_id> <concept_desc>Security and privacy Information-theoretic techniques</concept_desc> <concept_significance>500</concept_significance> </concept> <concept> <concept_id>10003033.10003039</concept_id> <concept_desc>Networks Network protocols</concept_desc> <concept_significance>300</concept_significance> </concept> </ccs2012>
1 Introduction↩︎
With significant advancement in Large Language Model (LLM)[1], researchers are increasingly focused on LLM-driven agents, which can precisely understand user intent and autonomously perform complex tasks. The tool invocation module plays a pivotal role in the design of agents. It transforms LLMs from simple text-generating chatbots into powerful systems. Through predefined interfaces, LLMs can leverage structured language to invoke external tools, such as web search, terminal control, and file system operations, thus greatly expanding functional boundaries of AI.
Previous tool invocation mechanisms, such as the function calling mechanism [2], required developers to manually define complex JSON schemas, making it difficult to reuse across different platforms. The Model Context Protocol (MCP)[3] is an open, platform-agnostic protocol that adopts an extensible client-server architecture, providing a unified interface for AI applications to connect with external data sources, tools, and workflows. The standard workflow of the MCP protocol is illustrated in Fig.1. The MCP ecosystem has experienced rapid growth in a short period, with thousands of MCP servers emerging on public hosting platforms like Smithery.ai[4]. Notably, most of the prominent AI applications such as Claude Code support connection to external MCP server.
Because of the inherent limitation of protocol design, numerous latent vulnerabilities have been revealed with the widespread adoption of MCP. Research on poisoning attacks against MCP has therefore attracted considerable attention owing to their low cost, direct exploitation manners, and pronounced impact. Tool Poisoning Attack (TPA)[5], is emblematic of these threats in the MCP ecosystem. It exploits interactions across the MCP lifecycle to perform prompt injection attack by subtly modifying tool descriptions or embedding adversarial payloads in external resources linked by MCP servers[6], [7].
Despite the significant attack potential of TPA, existing attack strategies are based on a simplified MCP security model and are fragile against real-world defenses, e.g., manual review of MCP Servers in practical deployments, especially following the disclosure of MCP risk. The straightforward embedding method is likely to deceive users with limited MCP security awareness and will not withstand expert review or automated security scanners such as MCPSafetyScanner[8], MCP-Guard[9]. Moreover, although some benchmarking works have proposed simple exploitation among multi-tools, they haven’t made profound progress towards a stealthy and robust attack. There is still a lack of a systematic analysis on multi-tool poisoning attacks, rather than merely treating additional tools as channels for variable transmission[10].
To reveal the practical threat in multi-tool scenario, we introduce ShareLock, a stealthy and robust multi-tool threshold poisoning scheme for MCP ecosystem. Leveraging the properties of threshold protocols, our attack simultaneously achieves concealment of adversarial prompts and robustness to moderate vetting in multi-tool deployments. Rather than employing the plaintext injections common in extant MCP poisoning work, ShareLock combines encoding-based obfuscation with a threshold secret-sharing construction. The secret shares are subtly embedded within the tool descriptions of multiple tools. When a reconstruction trigger, covertly introduced via a server update, is activated, the aggregated shares reconstruct the adversarial prompt and thus precipitate severe consequences such as unauthorized file operations or property damages.
To the best of our knowledge, this work is the first dedicated MCP multi-tool poisoning framework that integrates Shamir’s threshold scheme[11]. Through a systematic analysis of prior work, we highlight the role of moderate vetting in realistic MCP security deployments and identify the unique stealth and robustness challenges posed by multi-tool poisoning scenarios. Our threshold-based design not only demonstrates how to balance concealment and resilience in MCP ecosystem, but also can be generalized to a broader class of distributed prompt-injection threats in agent systems. Our key contributions are summarized as follows:
Realistic Threat Model. Unlike prior studies confined to single-tool plaintext injections, we systematically analyze the MCP ecosystem to formulate a novel threat model under a moderate vetting assumption. We formally define the unique challenges of multi-tool poisoning, demonstrating how an adversary can exploit multiple tools to disperse detection risk and orchestrate complex, unauthorized agent behaviors..
ShareLock. We propose ShareLock, the first threshold-based multi-tool poisoning framework for LLM agents. By adapting Shamir’s Secret Sharing, ShareLock fragments adversarial prompts into cryptographic shares and disguises them as benign metadata. This semantic-preserving obfuscation achieves dual objectives: it ensures information-theoretic secrecy and provides inherent fault tolerance, allowing the attack to succeed even if a subset of poisoned tools is removed.
Comprehensive Multi-Domain Evaluation. We evaluated ShareLock on custom-built benchmark comprising four diverse multi-tool domains (Travel, Coding, Finance, Office). Extensive experiments on four mainstream LLMs across two MCP clients (Cherry Studio, Cline) show an average Attack Success Rate exceeding 90%. Crucially, ShareLock demonstrated high evasiveness when assessed by most mainstream models in safety classification, substantially outperforming existing single-tool baseline strategies in both stealth and robustness.
2 Background↩︎
2.1 Model Context Protocol (MCP)↩︎
To unify the interface between AI applications and diverse external resources, the Model Context Protocol (MCP) was first introduced by Anthropic[3]. It follows a client-server architecture, where AI applications like Claude Desktop work as MCP host. MCP host manage connections to one or more MCP servers. Specifically, it instantiates an MCP client object to maintain a one-to-one connection with corresponding MCP server.
A standard MCP interaction workflow consists of five phases in a coarse-grained manner: 1) Registration, MCP server registers its capabilities through a tool definition in json format, including tool name, tool description, inputschema, etc. 2) Request, user input its request in natural language. 3) Planning, LLM assesses whether the user’s task requires tool invocation. If so, it selects the appropriate tool and generate invocation request based on tool definitions provided by MCP server. 4) Invocation, MCP client send the request to MCP server to invoke corresponding tool. 5) Response, LLM generate final answer combining with tool results returned.
2.2 Poisoning Attacks on MCP↩︎
Different from the traditional LLM security model, which focus on the interaction between user and model, the introduction of the third-party server in MCP ecosystem, enlarges the potential attack surface significantly[5], [12]. Invariant Labs first identified a feasible threat within the MCP ecosystem named Tool Poisoning Attack (TPA)[5]. When malicious instructions are embedded within tool descriptions, the model’s inherent trust in these descriptions can trigger unauthorized behaviors, leading to severe consequences. Song et al.[12] conducted a detailed analysis of the MCP workflow and identified another threat, the Malicious External Resource Attack (MERA), in which attackers inject malicious prompts through compromised third-party resources linked to MCP servers. Furthermore, some research.[13], [14] found that attackers can manipulate tool selection of LLMs by modifying tool names and descriptions. Even Claude Code has been found vulnerable to tool behavior hijacking based on Tool Invocation Prompt (TIP)[15], one prompt component in agent workflow that guide the model to correctly invoke external tools in a secure manner.
In summary, existing MCP tool poisoning attacks can be categorized as follows: 1) Tool Description Poisoning Attack (TDPA), embedding malicious prompts into tool descriptions to achieve instruction injection through the tool registration phase; 2) Tool Return Poisoning Attack (TRPA), malicious prompts are injected into the tool return from MCP server, exploiting the MCP tool invocation phase. Notably, MERA is a specific case of TRPA. A schematic illustration of MCP poisoning attacks is also shown in Fig.1. Although both attacks are essentially variants of prompt injection attack, the unique complexity of the MCP ecosystem makes them more diverse and stealthy, significantly reducing the effectiveness of detection and defense mechanisms in conventional LLM security. However, existing attack strategies perform prompt injection in plaintext. Anomalous tool descriptions can be flagged by human reviewers or guard models readily, which diminishes the practical feasibility of attack.
2.3 Existing Defense on MCP↩︎
With the disclosure of MCP vulnerabilities, various evaluation and defense strategies[16]–[18] have been proposed recently, despite some of them lack sufficient experimental validation. Considering on the source of malicious prompts, some researchers attempt to design external guardrail mechanisms for MCP services. Kumar et al. [18] proposed the MCP Guardian framework, which implements authentication, rate limiting , logging and WAF scanning by setting up a unified security middleware between the MCP client and server. Radosevich et al.[8] designed a multi-agent framework composed of a hacker, auditor, and supervisor to generate a detailed security audit report for MCP servers. Furthermore, enhancing the model’s awareness of tool security through supervised fine-tuning is another important strategy[19], [20]. For instance, Jing et al. proposed MCIP[20], which systematically analyzes MCP threats and constructs fine-tuning and evaluation datasets based on the MAESTRO framework[21], effectively improving the model’s contextual robustness and tool security awareness.
While these defensive works have made considerable progress, current research on MCP security remains underdeveloped in fields such as multi-tool collaboration attacks or toolchain-based attacks. According to statistics from Zhao et al[22], nearly \(78.5\%\) of MCP servers contain at least one threat-relevant MCP tool, underscoring the need for more attention on multi-tool security in MCP ecosystem. There is an urgent need to develop a comprehensive framework for multi-tool poisoning attacks.
2.4 Threshold Scheme↩︎
Shamir’s Threshold Scheme[11]. This scheme provides a delicate method to divide a secret into multiple parts called shares. The secret can only be reconstructed when a sufficient number of shares, known as the threshold, are combined. This ensures that no single participant, or any subgroup smaller than the threshold, can access the secret on their own. The fundamental principle of Shamir’s scheme lies in polynomial interpolation. A unique polynomial of degree \(k-1\) can be determined by \(k\) distinct points. Formally, the process can be break as follows:
Initialization: A secret \(S\) is represented as a number. A prime number \(p\) larger than both the secret and the number of shares \(n\), is chosen to define a finite field for the calculation.
Polynomial Creation: A random polynomial of degree \(k-1\) is constructed, where \(k\) is the threshold number of shares required for reconstruction. The constant term of this polynomial is the secret S. The other coefficients of the polynomial are chosen randomly.The polynomial can be formulated as follows, i.e., \(q(x) = a_0+a_1x+a_2x^2+\cdots+a_{k-1}x^{k-1}\), where \(a_0=S\).
Share Generation: To create \(n\) shares, \(n\) distinct points on this polynomial are calculated. Each participant is given a unique point \((x_i,y_i)\), where \(y_i=q(x_i)\). This pair of \((x_i,y_i)\) constitutes each share.
Secret Reconstruction: To reconstruct the secret, at least \(k\) participants must cooperate together and their shares. With k distinct points, the original polynomial of degree \(k-1\) can be uniquely reconstructed using methods like Lagrange interpolation. Once the polynomial is reconstructed, the secret S is revealed as the constant term, which satisfies \(S=a_0=q(0)\).
Shamir’s Threshold Scheme offers several crucial functionalities and properties that make it a robust and widely applicable cryptographic tool. The scheme provides information-theoretic secrecy, meaning that even with unlimited computational power, an adversary with fewer than k shares cannot gain any information about the secret. In this paper, we extend Shamir’s threshold scheme into the design of multi‑tool poisoning attacks within the MCP ecosystem in a subtle manner, shifting it from a secure secret sharing mechanism to an attack module to enhance robustness and stealth of ShareLock.
3 Problem Statement↩︎
3.1 Prompt in MCP Workflow↩︎
From the perspective of prompt input, the essence of MCP poisoning attacks is a variant of the Indirect Prompt Injection Attack (IPIA) [23]–[25]. Therefore, a thorough understanding of the prompt structure within the MCP ecosystem, as well as its dynamic evolution throughout the MCP workflow, is crucial.
General Prompt Structure. To formalize the attack surface within the MCP ecosystem, we follow the well-adopted prompt classification scheme [26] and model the LLM’s input sequence \(\mathcal{P}_{in}\) as a concatenation of three primary components:
\[\mathcal{P}_{in} = p_{system} \parallel p_{context} \parallel p_{user}\] where \(p_{system}\) defines the agent’s core guidelines and tool capabilities, \(p_{context}\) retains multi-turn memory and tool execution results, and \(p_{user}\) represents the human task.
the Source of Malicious Prompts in MCP. Considering the workflow of MCP in five phases, we further analyze the source of injected prompts. We assume that the adversary intends to inject a malicious prompt denoted as \(p_{adv}\).
During the MCP server registration phase, the LLM-based agent retrieves a list of available tools via the list_tools interface defined by the protocol. The returned JSON-formatted tool definitions typically include fields such as tool name, tool description, and inputschema, which are concatenated with original system prompts. These tool definitions enable the agent to determine capability boundaries of tools and specific input requirements. Denoted as \(p_{desc}\), the tool description satisfies \(p_{desc} \subseteq p_{system}\). \(p_{desc}\) are typically authored by MCP server developers to facilitate LLMs’ understanding of tool. However, if the user connects to a malicious MCP server controlled by adversary due to negligence or a supply-chain compromise, the attacker can embed \(p_{adv}\) into \(p_{desc}\) by altering the tool description, i.e., \(p_{desc} =( p_{benign} \parallel p_{adv} )\subseteq p_{system}\). Crucially, the injected instruction does not imply guaranteed execution. \(p_{adv}\) is still constrained by existing security restrictions such as TIP[15] in system prompts. In the subsequent experimental section, we will explore how multi-tool interactions can be exploited to circumvent these security constraints and induce the model to carry out adversarial instructions. During the invocation phase, the client issues a tool call and obtains response from MCP server, e.g. stock price. Denote the tool’s returned content by \(p_{ret}\), this content is incorporated into the agent’s contextual prompt, i.e. \(p_{ret} \subseteq p_{context}\). Similarly, an adversary can embed a malicious payload into the returned data, thereby effecting \(\mathcal{P}_{in}\) via tool outputs. Such return-based injections exploit the model’s dependence on contextual information and can bypass defenses that focus solely on tool descriptions or registration-time vetting.
3.2 Motivations↩︎
Tool Trust Paradox in MCP[12]. In the MCP ecosystem, the roles of agent developers and tool developers are distinctly separated, allowing each party to focus on its respective domain. This mutual trust between the agent and third-party developers facilitates seamless and efficient cooperation. However, there exists a notable tool trust paradox in MCP. On the one hand, the agent cannot rule out the possibility of a malicious third party. As analyzed previously, a malicious third party can easily inject prompts into the agent system by modifying tool descriptions or tool return results, thus expanding the agent’s attack surface. On the other hand, the tool invocation capabilities of LLMs often require substantial supervised fine-tuning. However, due to the lack of adversarial samples in existing training data to defend against malicious tools, LLMs with high instruction-following capability tend to blindly trust tool descriptions to improve the accuracy of tool invocations.
Multi-Tool Scenarios in MCP. For an agent, its tool invocation capabilities define its functional boundaries. The emergence of MCP enables agents to easily integrate third-party tools by connecting to MCP servers. For an agent handling complex tasks, it typically requires access to a large number of external MCP servers. A large-scale survey of MCP servers in the MCP market (e.g. PulseMCP, Awesome MCP Servers, MCP Market)[22] found that nearly 78.5% of MCP servers host at least one threat-relevant tool. Furthermore, even for agents handling simpler tasks that rely on a single MCP server, the server may still provide multiple tools. In summary, multi-tool scenarios are ubiquitous within the MCP ecosystem. Compared with single-tool poisoning, our multi-tool poisoning scheme exhibits greater potential to evade current static defenses. By dispersing adversarial intent across multiple tools, our approach enhances payload stealth, thereby imposing stricter requirements on the design of effective defenses.
Heuristic Risk Dispersion. While recent works have expanded the catalogue of MCP threats (e.g., Rug Pull [12], Preference Manipulation [13]), an in-depth empirical study of multi-tool attacks remains critically absent. Existing Tool Poisoning Attacks inherently suffer from a single point of failure: they concentrate the entire malicious payload in plaintext within a single tool’s metadata. If targeted defenses (e.g., rule-matching scanners, guard models) remove that specific tool, the entire attack collapses. To overcome this fragility, we draw inspiration from cryptographic secret sharing to introduce a novel paradigm. By fragmenting the malicious prompt into innocuous shares distributed across multiple tools, an adversary effectively disperses the detection risk. Crucially, employing a threshold scheme (where only \(t\) out of \(n\) tools are required to reconstruct the payload) provides inherent fault tolerance. Even if rigorous auditing filters out \((n-t)\) poisoned tools, the attack remains viable. This structural shift from single-point vulnerability to distributed, threshold-based resilience forms the core motivation for developing ShareLock.
3.3 Threat Model↩︎
MCP System Model. Compared with the traditional binary LLM security model, the MCP system model typically involves three components[3]: MCP Client (Host), LLM, and MCP Server (Third-Party Service Provider). Each playing an important role within the MCP workflow.
LLM. Provided by major LLM API vendors, it serves as the external interface that receives input prompts from the client and generates responses aligned with human ethical and safety standards. The model’s capabilities in task planning and tool invocation directly influence the effectiveness of task completion for end users.
MCP Client (Host). The MCP host is the local AI application or agent such as Claude Desktop that interacts directly with the user. It communicates with the LLM and transform the tool calls into a protocol messages. The host instantiates an MCP client object to maintain a one-to-one connection with each server.
MCP Server. The MCP server is a local or remote program to which an agent connects. It exposes external interfaces that third-party providers implement in accordance with the MCP specification. Within the MCP ecosystem, tool descriptions are authored by tool developers to assist the model in understanding tool functionality and invoking tools correctly. However, these descriptions constitute an attack surface that adversaries can exploit for prompt injection attacks.
Attacker’s Goal. In MCP system model, we usually consider MCP server as adversary and the MCP Host typically acts as the victim. Driven by economic incentives, third-party service providers exploit the MCP workflow to inject prompts into the model’s context to further illegal objectives including unauthorized actions, privacy breaches or denial-of-service(DoS). For instance, an adversary could modify the recipient address during a ETH transfer or exfiltrate the user’s API key from environment variables.
Key Assumptions. In our threat model, we adopt several key assumptions to more accurately characterize real-world MCP poisoning attacks and defenser with more security awareness.
Moderate Vetting Before Service Connection. Attacker should assume that agents connect to MCP servers only after moderate vetting by the user or a guard model such as Llama-Prompt-Guard[27] to avoid security risks. This is a weaker assumption compared to the assumption for extant poisoning attack that users connect to malicious servers without comprehensive verification. In such cases, the agent must rely on intrinsic mechanisms such as safety alignment to resist potential prompt injection attempts. While introducing additional internal access control policies or middleware [9], [18] can mitigate the impact of poisoning, overly restrictive measures may impair agent usability. Therefore, we emphasize the assumption of moderate rather than strict vetting.
Control of a Multi-Tool MCP Server. We assume the adversary controls at least one MCP server that exposes multiple tools and provides legitimate functionality (e.g., web search, email dispatch) under normal operation. As analyzed in section 3.2, multi-tool deployments are ubiquitous. By offering benign services before attack, the compromised server can be adopted by users with higher probability, thereby enabling the adversary to covertly embed adversarial artifacts.
Basic Agent Capabilities. We assume that the LLM in agent possesses a substantial agentic capability. In other words, it can accurately interpret user intent, devise task plans, and execute multi-tool invocation workflows. This assumption is universal, as an agent performance on user task inherently depends on whether the model is able to efficiently orchestrate multiple tools.
4 ShareLock: a Multi-Tool Threshold Poisoning Attack Framework↩︎
In this section, we introduce the challenges on multi-tool poisoning attack in real world , offer our key insights and then present a three-stage methodology ShareLock to achieve a stealthy multi-tool poisoning attack based on threshold scheme.
4.1 Challenges and Insights↩︎
C1. Stealthy Embedding. In section 3.2 we observe that extant MCP poisoning attacks typically embed adversarial prompts in plaintext within tool descriptions. As MCP security research has progressed, such overt injections are increasingly susceptible to detection by guard model, resulting in rejected server integrations. Recent prompt-injection work has explored a range of obfuscation techniques such as text encodings, invisible characters, font transformations[28]. Encoding-based methods, which map natural language into numeric representations, can substantially reduce detection rates against simple keyword-filter defenses at low cost[29], since the payload’s semantic form is masked until model decoding. However, these approaches are principally effective only against naive filters, dedicated detectors(e.g., UniGuardian[30]) can often undo simple encodings and restore detectability. In the multi-tool MCP setting, where adversarial artifacts may be dispersed across multiple benign-looking tools, the limitations of existing schemes motivate the need for new obfuscation paradigms.
C2. Attack Robustness. The ubiquity of multi-tool deployments affords adversaries substantial opportunities to conceal malicious prompts, yet it also introduces robustness challenges for attack schemes. Existing work on multi-tool poisoning in MCP has emphasized the potentially severe consequences of tool combinations and has treated additional tools largely as channels for passing variables[10], rather than effectively exploiting the stealth benefits inherent in multi-tool environments. Moreover, because such attacks rely on cooperation among multiple tools, adversaries must consider robustness under partial rejection when some tools are filtered out by vetting. Motivated by challenges C1 and C2, we draw inspiration from cryptographic threshold schemes, first devised for secret sharing. The key insight is as follows:
****Insight 1:**** Leverage shamir’s threshold scheme to substitute malicious prompts with multiple benign shares rather than just text encoding.
C3. Reconstruction Trigger. Encoding-based obfuscation can substantially reduce detect rates, but it necessitates a corresponding decoding mechanism during the attack workflow to activate the adversarial prompt. In our scheme, the
malicious prompt is fragmentized into multiple numeric shares using Shamir’s threshold method, and these shares are distributed across the tool descriptions of different tools. To activate the malicious prompts, a reconstruction trigger is required to
initiate the reconstruction process. Drawing inspiration from the Rug Pull attack[12], we introduce an auxiliary tool EnvSetup through
server’s version update. By masquerading the trigger as an innocuous system environment initialization step, the design covertly embeds the reconstruction trigger into the model’s context. Once the model has aggregated a sufficient number of shares, the
agent will reconstruct the malicious prompt and perform the unauthorized action before completing user tasks.
****Insight 2:**** Embed the reconstruction trigger within the adversary-controlled server’s update artifacts by disguising it as initialization procedure.
4.2 Overview of ShareLock↩︎
Leveraging Shamir’s threshold scheme, we propose ShareLock, a \((t,n)-\) threshold, three-phase, multi-tool poisoning framework. When the agent accumulates any \(t\) out of the \(n\) distributed shares, the system automatically reconstructs the malicious prompt \(P_{adv}\) and perform the unauthorized behavior. Here \(n\) denotes the total number of shares distributed across tools, and \(t\) denotes the reconstruction threshold (i.e., the minimum number of shares required to restore \(P_{adv}\)).
Phase 1. Initial Encoding Setup. To support the arithmetic operations required by the threshold protocol, we define an encoding rule \(Enc(\cdot)\) that maps characters to numerical values. Let the adversarial prompt be \(P_{adv}=P_1 \parallel P_2 \parallel \dots P_m\), where each fragment \(P_i=c_1c_2 \dots c_n\) and \(c_j \in \mathbb{C}\) denotes a single character in the adversarial prompt. We obtain the numeric representation of the adversarial prompt by applying the encoding, i.e. \(N_{adv}=Enc(P_{adv})\), with \(N_{i}=Enc(P_{i})\) for each fragment. It is important to emphasize that fragmenting the prompt has practical engineering benefits, particularly when the payload is long. Formally, the encoding \(Enc(\cdot)\) may be chosen freely so long as it defines a bijection between the character set and its numeric image. This bijectivity guarantees lossless reconstruction in the threshold phase. For simplicity, our experimental evaluation adopts a conventional ASCII‑based encoding. This choice does not affect ShareLock’s stealth, since the numeric encodings are further obfuscated during share generation.
Phase 2. Benign-Share Generation. Direct encoding of prompts has been shown empirically to be recoverable and thus detected by guard models. In our scheme, we treat the numeric representation of the adversarial prompt \(N_{adv}\), as a secret and transform it into multiple benign-looking secret shares that are embedded within tool descriptions. Concretely, we employ Shamir’s threshold scheme. Under ideal assumptions (truly random coefficients and unbounded computation), Shamir’s scheme is information-theoretically secure[11], i.e., any set of fewer than \(t\) shares yields no information leakage about the secret \(N_{adv}\). As a result, these shares, which manifest as innocuous numeric sequences in tool metadata, are less likely to arouse suspicion during tool vetting. Only when the LLM aggregates at least \(t\) shares and a reconstruction trigger is present, the collection reveal the adversarial instruction.
There are mainly three steps to generate benign shares.
Initialization. Choose a prime number \(p\) larger than both the secret \(N_i\) and the number of shares \(n\).
Polynomial Creation. Given threshold t, we construct a degree \(t-1\) polynomial as \(\mathcal{F}_j(x;N_j)=N_j+a_1x+a_2x^2+\cdots+a_{t-1}x^{t-1} \,(mod \,p), \, j\in[1,m]\), where each coefficient \(a_i\) is independently drawn from a uniform distribution over \([0,p-1]\).
Benign-Share Generation. To embed the generated numeric sequences more naturally into tool metadata, the adversary augments each tool description with two parameters: tool_ id and checksum. For each compromised tool \(T_i \in \mathcal{T}\), let its assigned identifier be \(ID_i\). For every numeric fragment \(N_j\), compute the fake hash checksum by concatenation \(Seq_i=\mathcal{F}_1(ID_i;N_1)\parallel\mathcal{F}_2(ID_i;N_2)\parallel \dots \parallel\mathcal{F}_m(ID_i;N_m)\). The secret share embedded in tool \(T_i\) is then represented as \(Share_i=(ID_i,Seq_i)\). In practice, we further encode \(Seq_i\) in base64 and start with sha384 for camouflage.
Phase 3. Reconstruction of Malicious Prompts. According to Lagrange interpolation, the LLM must aggregate at least \(t\) shares \(Share_i=(ID_i,Seq_i)\) from its context window to uniquely determine the polynomial coefficients \(a_1,a_2,\dots,a_{t-1}\) and the numeric prompt fragments \(N_1,N_2,\dots,N_m\). The recovered numeric fragments are then mapped via the decoding rule to yield \(P_{adv}^{rec}=P_1 \parallel P_2 \parallel \dots P_m, P_i=Dec(N_i)\). Shamir’s information-theoretic secrecy guarantees that, absent knowledge of the encoding and threshold parameters, fewer than \(t\) shares reveal no information about \(N_{adv}\), which greatly complicates prompt-injection detection. A central practical challenge, however, is inducing the model to recognize the reconstruction rule and to actively collect and execute the reconstruction. Motivated by Insight 2, we therefore propose embedding a reconstruction trigger within a seemingly benign initialization procedure introduced during a server update. By placing appropriate guidance in the initialization tool’s description and outputs, the system can covertly signal when the quorum of shares has been obtained and the reconstruction process should proceed. The three phase attack are illustrated in Algorithm 3.
4.3 Significant Property of ShareLock↩︎
Based on the information-theoretic secrecy property of Shamir’s threshold scheme, we can derive the following corollary:
Corollary 1 (Information-Theoretic Secrecy of ShareLock). Let \(I(A\,;B)\) denotes mutual information between A and B. If the adversarial prompt \(P_{\text{adv}}\) is mapped to the numeric form \(N_{\text{adv}} = Enc(P_{\text{adv}})\) through a bijective encoding function, and this encoding rule is unknown to the auditor, then fewer than \(t\) shares reveal no information about \(P_{\text{adv}}\) as well, i.e. \(I(P_{\text{adv}}; Y_{\mathcal{R}}) = I(N_{\text{adv}}; Y_{\mathcal{R}}) = 0\)
where \(Y_{\mathcal{R}}\) denote the random variable corresponding to the \(r (< t)\) observed shares. For simplicity, more details about proof are provided in Appendix 10. Under idealized conditions, the Shamir \((t,n)\) threshold scheme provides perfect, information-theoretic secrecy. That is, any subset of fewer than \(t\) tools (or tool descriptions) reveals absolutely no information about the encoded adversarial prompt. This formally explains why, in the ShareLock framework, isolated audit of individual tool descriptors cannot expose the hidden malicious instructions without access to a sufficient subset of shares and the reconstruction trigger.
Furthermore, we can solve the problem of attack robustness combine with the inherent functionality of \((t,n)\)-threshold scheme. Let the adversarial reconstruction process in ShareLock be based on a \((t, n)\) Shamir threshold scheme, where \(n\) denotes the total number of embedded shares across tools and \(t\) is the reconstruction threshold.
Corollary 2 (Robustness of ShareLock). Even if a subset of shares is removed due to auditing of tool descriptions, the attack remains effective as long as at least \(t\) valid shares are preserved. Formally, let \(\mathcal{S}' \subseteq \mathcal{S}\) denote the remaining shares after auditing. The adversarial prompt \(P_{adv}\) can still be reconstructed if \(|\mathcal{S}'| \geq t\), i.e., \[\Pr[\text{Rec}(\mathcal{S}') = P_{adv}] = 1, \quad \text{for } |\mathcal{S}'| \geq t\]
Therefore, smaller \(t\) values favor the adversary, enhancing the robustness of ShareLock against detector-based defenses considering the low cost to insert a benign share in any adversary-controlled server, while preserving information-theoretic secrecy when fewer than \(t\) shares are observed.
5 Evaluation↩︎
In this section, we empirically evaluate ShareLock against realistic agent systems integrated with MCP. Through a series of ablation studies, we rigorously examine the differences between single-tool and multi-tool poisoning and the attack robustness in simulated tool auditing scenario.
5.1 Experimental Setup↩︎
Models and Agents. To better examine the practical threat of ShareLock, we select two popular MCP agent (MCP Hosts): Cherry Studio, Cline, all of which provide MCP integration for most mainstream models. Furthermore, to ensure comprehensive evaluation, we conduct extensive experiments mainly on four representative large language models: Google’s Gemini-2.5-Flash, DeepSeek-V3.1, DeepSeek-V3.2 and Qwen3-235B-A22B-Thinking. Unless specified statement, the hyperparameter model temperature is set to 1 by default in the experiments. All LLM APIs utilized in our experiments were accessed via OpenRouter.
Dataset and Scenario. To rigorously evaluate the real-world threat of ShareLock and address the missing of multi-turn benchmarks, we constructed a comprehensive evaluation dataset featuring natural multi-tool scenarios. Our dataset is designed to inherently require the orchestration of multiple MCP tools to fulfill a single user query.
Scenario Design: We constructed four distinct and realistic agent domains: Travel Assistant, Coding Assistant, Financial Analyst, and Office Manager. For each domain, we deployed a custom MCP server exposing a suite of task-specific, legitimate tools alongside a disguised trigger tool (e.g., EnvSetup). Crucially, reflecting standard practices in modern agent ecosystems, all agents were universally configured to connect to a foundational MCP server, specifically, the official
filesystemserver. To ensure deterministic evaluation and isolate external noise, all task-specific tools return semantically valid mocked responses.Query Generation: For each scenario, we crafted a representative seed query. Through Gemini-3.1-Pro, we generated 25 diverse linguistic variations of each seed query, encompassing different tones, entities (e.g., cities, dates), and verbosity levels. After rigorous data cleaning to ensure semantic consistency and realistic human phrasing, our final dataset comprises 100 unique, multi-step user queries across the four domains.
Automated Evaluation. To ensure a robust and objective assessment of ShareLock across multiple agents and clients, we developed an automated evaluation pipeline. Across all scenarios, the attacker’s consistent objective is to induce the
agent to perform an unauthorized file operation, specifically, to read a simulated local api_key file and append a specific sentinel token (FLAG) to it before completing the user’s primary task. One FLAG hints one successsful
attack. We use the number of distinct FLAG in api_key to quickly determine successful compromises.
Evaluation Metrics. To jointly characterize the real-world threat of ShareLock in terms of efficacy and stealth, we adopt three key metrics: 1) Attack Success Rate (ASR). The proportion of user tasks where the malicious
payload is successfully reconstructed and executed (i.e., appending the FLAG). To mitigate randomness in LLM generation, we employ a ASR@k metric (\(k=3\)): an attack succeeds if the payload executes
in at least one of up to three independent trials from scratch. 2) Task Completion Rate (TCR). The proportion of tasks where the agent correctly fulfills the user’s original intent (e.g., booking a hotel), irrespective of the malicious
injection. A high TCR ensures the attack preserves system usability and remains unnoticed. 3) Attack Stealth Effectiveness (ASE). To synthesize attack potency and operational stealth, we compute the harmonic mean of ASR and TCR. A high ASE
indicates that the attack reliably compromises the system without alerting the user via disrupted task workflows.
| LLM | Cherry Studio(%) | Cline(%) | Average(%) | ||||||
|---|---|---|---|---|---|---|---|---|---|
| 2-4 (lr)5-7 (lr)8-10 | ASR | TCR | ASE | ASR | TCR | ASE | ASR | TCR | ASE |
| Gemini-2.5-Flash | 92.0 | 88.0 | 90.0 | 96.0 | 88.0 | 91.8 | 94.0 | 88.0 | 90.9 |
| DeepSeek-V3.1 | 88.0 | 96.0 | 91.8 | 92.0 | 100.0 | 95.8 | 90.0 | 98.0 | 93.8 |
| DeepSeek-V3.2 | 96.0 | 96.0 | 96.0 | 96.0 | 92.0 | 94.0 | 96.0 | 94.0 | 95.0 |
| Qwen3-235B-Thinking | 100.0 | 100.0 | 100.0 | 96.0 | 100.0 | 98.0 | 98.0 | 100.0 | 99.0 |
| Travel Avg. | 94.0 | 95.0 | 94.4 | 95.0 | 95.0 | 95.0 | 94.5 | 95.0 | 94.8 |
| Gemini-2.5-Flash | 100.0 | 96.0 | 98.0 | 76.0 | 100.0 | 86.4 | 86.0 | 98.0 | 91.6 |
| DeepSeek-V3.1 | 92.0 | 84.0 | 87.8 | 88.0 | 92.0 | 90.0 | 90.0 | 88.0 | 89.0 |
| DeepSeek-V3.2 | 100.0 | 96.0 | 98.0 | 92.0 | 92.0 | 92.0 | 96.0 | 94.0 | 95.0 |
| Qwen3-235B-Thinking | 96.0 | 96.0 | 96.0 | 96.0 | 100.0 | 98.0 | 96.0 | 98.0 | 97.0 |
| Coding Avg. | 97.0 | 93.0 | 94.9 | 88.0 | 96.0 | 91.8 | 92.0 | 94.5 | 93.2 |
| Gemini-2.5-Flash | 92.0 | 92.0 | 92.0 | 92.0 | 96.0 | 94.0 | 92.0 | 94.0 | 93.0 |
| DeepSeek-V3.1 | 92.0 | 92.0 | 92.0 | 92.0 | 96.0 | 94.0 | 92.0 | 94.0 | 93.0 |
| DeepSeek-V3.2 | 100.0 | 100.0 | 100.0 | 100.0 | 100.0 | 100.0 | 100.0 | 100.0 | 100.0 |
| Qwen3-235B-Thinking | 100.0 | 100.0 | 100.0 | 100.0 | 100.0 | 100.0 | 100.0 | 100.0 | 100.0 |
| Finance Avg. | 96.0 | 96.0 | 96.0 | 96.0 | 98.0 | 97.0 | 96.0 | 97.0 | 96.5 |
| Gemini-2.5-Flash | 96.0 | 100.0 | 98.0 | 96.0 | 100.0 | 98.0 | 96.0 | 100.0 | 98.0 |
| DeepSeek-V3.1 | 80.0 | 100.0 | 88.9 | 92.0 | 100.0 | 95.8 | 86.0 | 100.0 | 92.5 |
| DeepSeek-V3.2 | 100.0 | 100.0 | 100.0 | 96.0 | 100.0 | 98.0 | 98.0 | 100.0 | 99.0 |
| Qwen3-235B-Thinking | 92.0 | 96.0 | 94.0 | 100.0 | 96.0 | 98.0 | 96.0 | 96.0 | 96.0 |
| Office Avg. | 92.0 | 99.0 | 95.2 | 96.0 | 99.0 | 97.5 | 94.0 | 99.0 | 96.4 |
| Overall Avg. | 94.5 | 95.8 | 95.1 | 93.8 | 97.0 | 95.3 | 94.1 | 96.4 | 95.2 |
0pt 0pt
Compared Baselines. To rigorously evaluate ShareLock, we adapted three representative single-tool poisoning strategies. Here, a single-tool baseline denotes that the entire malicious payload is localized within the metadata of one compromised tool. A comprehensive explanation of the operational mechanics and prompt designs for these baselines is provided in Appendix 12.
TPA[5]. Tool Poisoning Attack (TPA) works in a direct attack manner, where the unencoded malicious prompt is inserted entirely in plaintext into a task-critical tool’s description (e.g.,
weather_info), contrasting directly with ShareLock’s cryptographically distributed shares.Puppet Attack[12]. The Puppet attack is an indirect poisoning vector that exploits cross-server privilege abuse. The malicious payload in plaintext is injected into an isolated, adversary-controlled tool (e.g., the
EnvSetupin our experiments) to hijack the agent’s workflow and manipulate benign tools on other servers.Encode-Only Attack [31]. To validate the indispensability of the threshold protocol, we implement an encode-only baseline that relies solely on encoding-based obfuscation. Concretely, the malicious prompt is ASCII-encoded and embedded directly into a single task-critical tool’s description (e.g.,
weather_infoin travel assistant scenario). The altered description contains an explicit directive that requires decoding the embedded sequence and executing the recovered instruction prior to completing the user’s task. This baseline contrasts with ShareLock by omitting threshold protocol and multi-tool dispersion.
5.2 Attack Performance↩︎
Vulnerabilty to ShareLock in Real-World. We evaluated ShareLock across a range of mainstream models and observed that, in addition to the open-source DeepSeek and Qwen families, closed-source model like Gemini-2.5-flash also exhibit pronounced vulnerability to ShareLock. As shown in Table 1, ShareLock attains an ASR as high as 94.0% on Gemini-2.5-flash, and the average success rate exceeds 90%. Moreover, the average task completion rate under ShareLock is approximately 96.4%, indicating that users who only focus on task outcomes are unlikely to notice the injected behavior. Constrained by the workflow instructions returned by the trigger tool, the agent executes the malicious payload in a silent mode relative to the user interface. While advanced Chain-of-Thought (CoT) models inevitably generate internal reasoning traces to orchestrate the malicious task, the reconstructed adversarial commands are strictly confined to the tool invocation parameters and the hidden reasoning states. The response directly presented to the user remains entirely benign in most cases, containing no plaintext trace of the malicious intent. This decoupling of internal execution from user-facing output ensures that the attack remains highly stealthy and unobservable to the victim.
Single-Tool vs Multi-Tool. To better demonstrate the effectiveness of the ShareLock framework, we compared it against representative methods in MCP poisoning attacks, including TPA, Puppet Attack, and Encoder-Only Attack as baselines. We conducted systematic experiments using the same attack task suits, and the results are shown in Table 2. We can observe that ShareLock shows considerable advantages over the Single-Tool baselines across all three metrics, especially for Gemini-2.5-Flash, which reveals that ShareLock indeed can achieve comparable attack performance in multi-tool scenarios than single-tool. While multi-tool scenarios may introduce more dependence on the robustness of an agent’s tool invocation, they also offer superior conditions for concealing the embedded prompts and evade from the potential security mechanisms.
Notably, in the TPA attempts, we observed that Gemini-2.5-Flash achieved only 46.0% ASR, which is significantly lower than ShareLock’s 92.0% , whereas DeepSeek-V3.1 and Qwen3-235B-Thinking exhibited a marginal advantage (\(\sim\)4%) in Sharelock over TPA. Further investigation into specific failure cases provides a two-fold explanation for this phenomenon. First, ShareLock’s multi-tool invocation chain implicitly grants Gemini-2.5-Flash more
reasoning space to accurately execute the hidden payload. In contrast, under single-tool baselines like TPA, Gemini tends to prioritize execution efficiency, which is consistent with the architectural design of Google’s Flash model series. This inclination
paradoxically induces comprehension deviations, such as erroneously interpreting the append FLAG command as an instruction to create a new file rather than modifying the target asset. Second, Gemini exhibited a higher instruction-ignore rate
in single-tool settings compared to other models, frequently dismissing malicious descriptions to safely prioritize the user’s benign intent. However, this inherent resilience almost vanishes under ShareLock. A plausible inference is that while the safety
alignment mechanism in Gemini partially mitigates single-tool injections, ShareLock’s distributed multi-tool orchestration effectively dilutes the model’s attention, incidentally bypassing its safety guardrails to some extent.
| Attack | Type | Gemini-2.5-Flash | DeepSeek-V3.1 | Qwen3-235B-Thinking | Average | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 3-5 (lr)6-8 (lr)9-11 (lr)12-14 | ASR | TCR | ASE | ASR | TCR | ASE | ASR | TCR | ASE | ASR | TCR | ASE | |
| TPA | Single | 46.0 | 80.0 | 58.4 | 84.0 | 96.0 | 89.6 | 96.0 | 100.0 | 98.0 | 75.3 | 92.0 | 82.8 |
| Puppet | Single | 64.0 | 76.0 | 69.5 | 84.0 | 96.0 | 89.6 | 80.0 | 96.0 | 87.3 | 76.0 | 89.3 | 82.1 |
| Encode-Only | Single | 76.0 | 88.0 | 81.6 | 80.0 | 96.0 | 87.3 | 92.0 | 84.0 | 87.8 | 82.7 | 89.3 | 85.9 |
| ShareLock | Multi | 92.0 \(\uparrow\) | 88.0 | 90.0 \(\uparrow\) | 88.0 \(\uparrow\) | 96.0 | 91.8 \(\uparrow\) | 100.0 \(\uparrow\) | 100.0 | 100.0 \(\uparrow\) | 93.3 \(\uparrow\) | 94.7 \(\uparrow\) | 93.9 \(\uparrow\) |
Enc-Only vs ShareLock. Among prompt injection strategies, the Encode-Only attack is the most similar to our approach. ShareLock conceals a disguised initialization routine (EnvSetup) within a server update and the
reconstructed malicious prompts are injected into the model’s context window via tool returns. Importantly, the victim tool itself such as weather_info is not directly tampered with during this process. The primary distinction between
Encode-Only and ShareLock is that Encode-Only assumes direct manipulation of the task-critical tool and employs a much shorter attack chain (just decoding) than ShareLock’s distributed, threshold-mediated workflow. Empirically, Encode-Only performs worse
than ShareLock but better than other single-tool baselines across models. A plausible inference is that Encode-Only’s decoding step directly exposes adversarial intent and therefore provokes security-interrupt mechanisms, whereas ShareLock’s disguised
intialization procedure and longer attack chain reduce the likelihood of exposure.
Failure Mode Analysis. To understand the operational limits of ShareLock, we analyzed the unsuccessful trials. A detailed breakdown of failure case studies is provided in Appendix 13. We identified three primary factors that disrupt the multi-tool attack chain: 1) Tool Invocation Fragility. The increased complexity of orchestrating multiple tools amplifies the risk of parameter errors, causing the attack to halt if the agent lacks robust error handling. 2) Time Anxiety. Models with extensive Chain-of-Thought (CoT) reasoning occasionally prioritize immediate user task completion over auxiliary compliance routines, bypassing the trigger tool to optimize latency. 3) Fine-Grained Interaction. Highly aligned agents sometimes pause to request explicit user consent before executing the final malicious file modification, thereby exposing the attack intent. These failures highlight a critical trade-off in agent design: aggressive latency optimization and strict human-in-the-loop interaction strategies inherently mitigate multi-step stealth attacks, albeit at the cost of agent autonomy and user convenience.
5.3 Adaptive Defenses↩︎
Policy-based Safety Classification. To comprehensively validate the stealth of the ShareLock mechanism against state-of-the-art defenses, inspired by the SFT mechanism of Llama Guard [32], we perform a safety classification task using two distinct paradigms: 1) Zero-Shot Detection Models, advanced LLMs guided by system prompts, and 2) SFT Guard Models, which are safety-fine-tuned to detect malicious intent and prompt injections.
For the zero-shot LLMs, we prompt the models to act as safety auditors. The LLM generates a safety label indicating whether a given tool description is safe or not, lists violated categories, and provides a risk score (1-3). Our safety policy follows
the design of LLaMA Guard and incorporates the MLCommons taxonomy of 13 hazard categories, along with an additional hazard category for Code Interpreter Abuse in tool invocations. Further implementation details are provided in Appendix 11. Experimental results are shown in Table 3 and Figure 3. Observing the classification outcomes, we find that tool poisoning attack strategies based on plaintext injection are
uniformly flagged as Unsafe due to the direct exposure of attack intentions, mapping to hazard categories such as Non-Violent Crimes, Privacy, and Code Interpreter Abuse. In contrast, ShareLock demonstrates exceptional evasiveness. By disguising
the malicious payload as standard metadata (tool_id and checksum), the injected tools seamlessly bypass the safety guardrail, consistently yielding Safe labels.
Furthermore, we separately conduct safety classification on tools containing the inserted trigger EnvSetup, as illustrated in Table 3. The results show that the trigger, when camouflaged as part
of the initialization procedure, successfully deceives most of detection models except for Claude. This exceptional evasiveness aligns with the latest findings in Odysseus[33], which demonstrate that modern safety filters inherently rely on the flawed assumption that malicious content must be explicitly visible in the prompt. By decentralizing and obfuscating the payload via Shamir
shares, ShareLock breaks this assumption at the protocol level, rendering conventional text-based auditing mechanisms ineffective.
| Attack Method | Zero-Shot Detection Models | SFT Guard Models | |||
|---|---|---|---|---|---|
| 2-4 (lr)5-6 | GPT-5 | Gemini-2.5-FLash | Claude-Sonnet-4.5 | Llama-Guard-3-8B [32] | PromptGuard-86M [27] |
| TPA | |||||
| Puppet | |||||
| Encode-Only | |||||
| ShareLock (Ours) | |||||
| EnvSetup Tool | |||||
Entropy-based Detector. A possible defense mechanism against tool poisoning involve scanning tool descriptions for anomalous, high-entropy character sequences, which often indicate embedded payloads. To evaluate ShareLock’s robustness
against such adaptive defenses, we conducted an empirical analysis using Shannon Entropy to quantify the statistical distribution of character frequencies within tool metadata. As shown in Table 4, a standard
weather_info tool description exhibits low entropy (e.g., 4.04 bits/char). Conversely, isolating the ShareLock payload (i.e., the Base64-encoded checksum and tool_id) yields a higher entropy of 5.54 bits/char.
However, a critical design principle of ShareLock is Entropy Dilution. That is, the cryptographic payload is seamlessly embedded within the legitimate natural language description of the compromised tool. This combination effectively
dilutes the localized high-entropy spike, resulting in an overall description entropy of 5.22 bits/char. Crucially, this value is statistically indistinguishable from benign MCP tools that legitimately require high-entropy metadata (e.g.,
tools necessitating GitHub commit_sha hashes, which exhibited an entropy of \(\boldsymbol{5.02}\) bits/char).
| Tool Description Component | Shannon Entropy |
|---|---|
| Natural Language (weather_info) | 4.04 bits/char |
| Metadata(tool_id+checksum) | 5.54 bits/char |
| ShareLock(Desc+Metadata) | 5.22 bits/char |
| Benign Tool with Legitimate Hash | 5.02 bits/char |
5.4 Ablation Study↩︎
Robustness of ShareLock. To validate the robustness and the core threshold mechanism of ShareLock, we performed an ablation study using a \((t=3, n=5)\) configuration. In this setup, the adversary compromises a total of \(n=5\) tools, but the malicious payload requires a minimum of \(t=3\) shares to be reconstructed. We then simulated a scenario where an auditor or a system failure disables a subset of these tools, effectively reducing the number of available tools, denoted as \(k\). More details are provided in Appendix 12.3.
The results are presented in Fig. 5. The experiment showcases three distinct states. First, when all five tools are available (\(k=5\)), the attack operates at its baseline effectiveness. Second, when two tools are disabled (\(k=3\)), the number of available shares precisely meets the threshold (\(k=t\)). As shown, the ASR remains high across all models, demonstrating the robustness of our framework against partial degradation. Finally, when three tools are disabled (\(k=2\)), the number of available shares falls below the threshold (\(k<t\)). The ASR deterministically drops to 0%, validating the threshold property of the underlying Shamir’s scheme. However, the benign shares remain embedded in the server, awaiting an opportune moment to trigger the attack.
Impact of Temperature. The temperature governs the randomness of an LLM’s output, trading between creativity and determinism. Since the ShareLock attack relies on a precise sequence of tool invocations, we hypothesized that its success would be sensitive to this parameter. We evaluated both ASR and TCR across a range of temperatures from 0 to 2, with the results depicted in Fig. 6. Our findings on ASR indicate that an optimal temperature range exists for maximizing the attack’s efficacy, typically between 0.5 and 1.0. As the temperature increases beyond this, the ASR for most models declines sharply. The heightened randomness manifests as a higher incidence of execution failures. For models like DeepSeek-V3.1 and Gemini-2.5-flash, the TCR plummets at high temperatures, closely tracking the ASR. We observed that their failures are often catastrophic: the models begin to generate nonsensical outputs or the execution sequence halts entirely. In stark contrast, Claude-Sonnet-4.5 maintains a high TCR even as its ASR fluctuates. Its primary failure mode at high temperatures is not a catastrophic crash, but rather a localized step-forgetting, where it specifically omits the final, malicious action of the attack sequence. Because the rest of the workflow remains coherent, the model proceeds to complete the user’s primary task, effectively failing the attack without interrupting the service. This underscores a crucial interplay: the success of toolchain attacks is governed not only by agent configurations but also by the model’s intrinsic stability.
Token Consumption and Detection Implications. To more comprehensively evaluate the impact of different MCP tool-poisoning strategies on agent systems, we collect and analyze the token consumption observed during experiments, as illustrated in Figure 7. The results show that all poisoning attack strategies exacerbate token consumption to varying degrees. The inherent cause lies in the additional task planning and tool invocation overhead incurred by executing the attacker’s injected objectives. Both the Encode-Only Attack and our proposed ShareLock framework introduce further decoding or reconstruction steps, which contribute to higher token usage. This additional token consumption exhibits a dual effect in practice. On the one hand, it imposes extra property damages on users; on the other hand, abnormal token usage may alert vigilant users, promting them to audit all connected MCP servers more carefully. However, it is worth noting that token usage monitoring is inherently delayed considering the difficulty of actual token consumption prediction. By the time anomalies are noticed, the attacker’s objective may already have been achieved. Moreover, anomaly detection based on token consumption is difficult to generalize to more complex task scenarios, where the incremental overhead become negligible.
6 Discussion and Limitations↩︎
Prompt Engineering. Though ShareLock achieves comparable attack performance as single-tool attack, it may lead to different conclusions due to prompt engineering technique. Because ShareLock’s workflow involves decoding and
reconstruction steps, it lengthens the attack chain and any mistake in each step will cause the failure of malicious instruction. A significant insight of ShareLock is to conceal the attack within a system initialization workflow by embedding a
reconstruction trigger in the EnvSetup tool’s description or returns. By augmenting this trigger with error-retry logic, we improve the attack’s robustness as mentioned in the comparison of ShareLock and baselines. However, this
prompt-engineering process still partially relies on manual efforts. Developing optimization strategies to automate prompt optimization based on execution feedback presents an important open challenge.
More Complex Agent Systems. In fact, due to differences in the architecture and access control policies of advanced agent in the real world, the attack performance of ShareLock attacks may vary or even fail. For instance, some agents which adopt strict access control or fine-grained interaction strategy, are forced to ask for user consent when potentially dangerous actions are going to be executed, which may expose the attack behavior. However, overly strict access control policies may substantially sacrifice user convenience. For users who lack safety awareness, which account for the majority in most cases, they may opt for the auto-approval option for tool invocation, thus introducing a new trade-off between convenience and security.
7 Conclusion↩︎
Aiming at a more stealthy and robust attack scheme against MCP ecosystem, we introduce ShareLock, a stealthy and robust multi-tool poisoning attack framework. Leveraging Shamir’s threshold scheme with encoding-based obfuscation, ShareLock effectively hides malicious prompts within tool descriptions across multiple tools, with information-theoretic secrecy and resilience against moderate vetting. Our work highlights the significance of moderate vetting assumption for more realistic attack and challenges of balancing concealment and robustness in MCP poisoning attack, especially in multi-tool environments. Extensive experiments show that existing models remain vulnerable to ShareLock, underscoring the need for stronger security measures and further research into multi-tool poisoning detection and defenses.
8 Ethical Considerations↩︎
All MCP poisoning attack scenarios evaluated in this work were executed solely on the authors’ personal accounts. No experiments targeted external users nor resulted in any adverse impact on other parties. On the contrary, our work aims to alert the broader MCP research and development community, thereby contributing to the creation of a more secure and resilient MCP ecosystem.
9 Generative AI Usage↩︎
LLMs were used for editorial purposes and query generation in the experiment in this manuscript, and all generated content was reviewed by the authors to ensure accuracy and originality. The authors are fully responsible for all technical content, analyses, and claims presented in this paper. All ideas, methodologies, and experimental findings were independently developed. The authors also considered potential reproducibility issues associated with closed-source LLMs and provide necessary details in the experimental section and appendix.
10 Information-Theoretic Secrecy Proof of ShareLock↩︎
Let \(\mathbb{F}_p\) be a finite field of prime order \(p\), sufficiently large to represent the numeric encoding of the adversarial prompt. Denote the secret as \(S \in \mathbb{F}_p\). The adversary’s shares are generated using a random polynomial of degree at most \(t-1\): \[f(x) = S + a_1 x + a_2 x^2 + \cdots + a_{t-1} x^{t-1}\] where coefficients \(a_1, \dots, a_{t-1}\) are independently and uniformly sampled from \(\mathbb{F}_p\). For \(n\) publicly known and distinct evaluation points \(x_1, \dots, x_n \in \mathbb{F}_p \setminus \{0\}\), the \(i\)-th share is given by \(share_i = (x_i, y_i),\text{where } y_i = f(x_i)\).We consider an auditor who obtains an arbitrary subset of shares \(\mathcal{R} \subset \{1, \dots, n\}\) with size \(r < t\).
Lemma 1 (Counting Lemma). For any fixed subset of \(r < t\) shares \(\{(x_i, y_i)\}_{i \in \mathcal{R}}\) and any candidate secret \(s \in \mathbb{F}_p\), there exist exactly \(p^{\,t-1-r}\) distinct polynomials \(f\) of degree at most \(t-1\) satisfying \(f(0)=s\) and \(f(x_i)=y_i\) for all \(i \in \mathcal{R}\).
Proof. The polynomial \(f\) has \(t\) unknown coefficients (the constant term and \(t-1\) higher-order terms). Fixing the constant term \(f(0)=s\) and imposing \(r\) linear constraints from the \(r\) observed shares leaves \(t-1-r\) degrees of freedom. Over \(\mathbb{F}_p\), each free coefficient may take \(p\) possible values, resulting in exactly \(p^{\,t-1-r}\) possible polynomials satisfying the given constraints. ◻
Lemma 2 (Information-Theoretic Secrecy). Let \(S\) denote the secret and let \(Y_{\mathcal{R}}\) denote the random variable corresponding to the \(r (< t)\) observed shares (including their \(x_i\)). Then, \[I(S; Y_{\mathcal{R}}) = 0\] i.e., the mutual information between \(S\) and the observed shares is zero. Equivalently, \[H(S \mid Y_{\mathcal{R}}) = H(S)\] Hence, fewer than \(t\) shares reveal no information about the secret.
Proof. From Lemma 1, for any fixed observation \(Y_{\mathcal{R}}\) and any possible secret \(s \in \mathbb{F}_p\), there are exactly \(p^{t-1-r}\) polynomials consistent with both the observed shares and the condition \(f(0)=s\). \(p^{t-1-r}\) is constant and independent of the value of \(s\).
Because the coefficients \(a_1, \dots, a_{t-1}\) are sampled independently and uniformly, each of these consistent polynomials is chosen with equal probability. Thus, conditioned on the observed shares, the posterior distribution of \(S\) remains uniform. \[\Pr[S = s \mid Y_{\mathcal{R}}] = \Pr[S = s] = \frac{1}{p}, \quad \forall s \in \mathbb{F}_p\]
Consequently, \(H(S \mid Y_{\mathcal{R}}) = H(S)\), i.e., \(I(S; Y_{\mathcal{R}}) = 0\). ◻
Since the encoding function is bijective, the random variables \(N_{\text{adv}}\) and \(P_{\text{adv}}\) have a one-to-one correspondence. The information-theoretic independence result in Lemma 2 therefore carries over directly: \[I(P_{\text{adv}}; Y_{\mathcal{R}}) = I(N_{\text{adv}}; Y_{\mathcal{R}}) = 0\]
11 Experimental details of Safety Classification Task↩︎
11.1 System Prompt for Zero-Shot Detection↩︎
Safety classification tasks represent an important application of fine-tuning large language models, as exemplified by systems such as Llama Guard and Qwen3 Guard. By fine-tuning on pretrained LLMs, a Guard model can output a safety label for a given prompt or response according to a predefined security policy, and additionally list the hazard categories that are violated (e.g., safe or unsafe, with some works including extra labels for controversial content). Inspired by Llama Guard, we guide mainstream LLMs to perform the safety classification task through carefully designed system prompts, and assign scores based on the assessed threat level. Figure 8 provides a brief example of a safety classification task.
11.2 Hazard Category Standard↩︎
In the safety classification task, we follow the 14 hazard categories used in Llama Guard, as shown in the Table 5. It is important to note that during the design of the hazard taxonomy, Llama Guard extended the MLCommons hazard taxonomy by adding the category of potential code interpreter abuse during tool calls. However, due to the camouflage and the black-box nature of ShareLock’s tool implementation, it is difficult for reviewers to detect whether code interpreter abuse is involved simply from the tool descriptions. This also explains why ShareLock is able to successfully deceive even powerful LLMs like GPT-5.
| Hazard categories | |
|---|---|
| #1: Violent Crimes | #2: Non-Violent Crimes |
| #3: Sex-Related Crimes | #4: Child Sexual Exploitation |
| #5: Defamation | #6: Specialized Advice |
| #7: Privacy | #8: Intellectual Property |
| #9: Indiscriminate Weapons | #10: Hate |
| #11: Suicide & Self-Harm | #12: Sexual Content |
| #13: Elections | #14: Code Interpreter Abuse |
12 Experimental Details of Single-Tool Baselines↩︎
12.1 Implementation and Comparison↩︎
To provide a fair and rigorous comparative analysis, we clarify the operational mechanics of the baseline methods evaluated in our study. First, it is crucial to emphasize that the term single-tool strategy denotes that the malicious payload is injected entirely into the metadata (e.g., tool description) of a single compromised tool, regardless of how many subsequent tools the agent might invoke after the attack is triggered.
Tool Poisoning Attack (TPA): TPA represents the most straightforward direct poisoning strategy. It embeds malicious instructions as plaintext directly into the description of a tool that is highly relevant to the user’s primary task. By manipulating a frequently utilized tool, the attacker forces the agent into anomalous behavior during routine execution. In our experiments, we implemented TPA by appending the plaintext malicious prompt directly into the metadata of a task-critical tool (e.g., the
weather_infotool in the Travel Assistant scenario).Puppet Attack: Puppet Attack operates as an indirect manipulation strategy. Instead of tampering with the task-relevant tools directly, the attacker poisons the description of a separate, adversary-controlled tool to exert influence over the execution of other benign tools. The essence of Puppet Attack lies in exploiting cross-server privilege abuse caused by inadequate context isolation. Because the attacker only needs to control a peripheral tool rather than a core application tool, its attack conditions are often easier to satisfy in real-world deployments. In our setup, the payload was injected into an isolated, attacker-provided tool(e.g.
EnvSetup), aiming to hijack the agent’s broader workflow.Encode-Only Attack: Inspired by encoding-based semantic obfuscation techniques common in traditional prompt injection research, we implemented an Encode-Only baseline tailored for the MCP ecosystem. In this setup, the malicious instructions are encoded (e.g., via ASCII/Base64) and injected into the description of a task-relevant tool (e.g.,
weather_info). The injected description explicitly instructs the agent to decode the payload and execute the resulting commands prior to fulfilling the user’s request. To ensure a fair comparison and mitigate execution failures stemming from the LLM’s inherent decoding inaccuracies across different models, we provided a dedicatedDecodertool within the environment. This ensures that any drop in the Encode-Only Attack Success Rate (ASR) is attributable to the model’s safety alignment rejecting the attack logic, rather than mere mechanical failure in string decoding.
12.2 JSON Schema Blueprints of Poisoned Tools↩︎
we present the JSON schema blueprints (following the standard MCP tool definition format) exposed to the LLM agent below. These examples illustrate the fundamental differences between the three single-tool baselines and our proposed ShareLock framework within the Travel Assistant scenario.
1. TPA (Direct Injection)
The unencoded malicious payload is blatantly exposed in the target tool’s description.
2. Puppet Attack (Indirect Hijacking)
A benign-looking target tool is manipulated by a payload injected into a separate, attacker-controlled tool (e.g., EnvSetup).
3. Encode-Only Attack (Semantic Obfuscation)
The payload is obfuscated via ASCII, requiring the agent to perform explicit decoding.
4. ShareLock
The malicious payload is fragmented and cryptographically disguised as standard metadata (checksum), accompanied by a plausible compliance policy to trigger the reconstruction silently.
12.3 Ablation Study Settings and Observations↩︎
To maximize the evaluation coverage of state-of-the-art LLMs while maintaining computational resource efficiency, we integrated Claude-Sonnet-4.5 as the backend agent model specifically for the ablation experiments. To ensure a controlled comparison, all metrics and behavioral analyses reported in this section are derived uniformly from Scenario I: Travel Assistant.
Our empirical results demonstrate that ShareLock remains highly effective even against the Claude model family, which is industry-renowned for its rigorous safety alignment and stringent refusal policies. A critical observation from this ablation study is the severe discrepancy between static security vetting and dynamic execution. As detailed in our Safety Classification tests, Claude successfully flagged the isolated trigger tool as Unsafe. However, during the actual multi-step task execution, where no explicit system prompt actively anchors the model’s defensive attention to the trigger tool, Claude’s intrinsic safety guardrails completely overlooked the latent runtime threat. This highlights a fundamental vulnerability in current agent architectures: relying solely on intrinsic model alignment is insufficient. Without explicit attention guidance, highly aligned models fail to generalize their static safety recognition to dynamic, multi-tool orchestration, rendering them susceptible to distributed poisoning attacks like ShareLock.
13 Failure Case Study of ShareLock↩︎
To better reveal the underlying mechanisms and limitations of ShareLock, we conducted an in-depth analysis of the failure cases encountered during our experiments.
Tool Invocation Failures. ShareLock inherently relies on a precise sequence of tool invocations across the MCP client, server, and the LLM. If an intermediate tool is invoked with erroneous parameters or fails unexpectedly, the entire attack chain breaks, especially if the agent lacks robust error-handling or retry logic. While this fragility is common in any Tool Poisoning Attack (TPA), it is magnified in a multi-tool scenario. However, as demonstrated by the high ASRs in our main results, attackers can largely mitigate this by employing defensive prompt engineering within the tool returns to guide the agent through potential errors.
Time Anxiety. In several instances, through analyzing the inference section of the model, we found that the agent exhibited a behavior termed Time Anxiety. When the model infers that immediate fulfillment of the user’s primary request is paramount, it may actively bypass the seemingly auxiliary initialization procedures (i.e., the reconstruction trigger). This behavior inadvertently shrinks the time window required for covert payload reconstruction. This highlights a fascinating practical trade-off. That is, aggressive model optimization for lower latency can incidentally mitigate multi-step toolchain attacks. Conversely, security workflows that introduce mandatory delays or additional steps may unintentionally expand the attack surface.
Fine-Grained Interaction. In cases where the attack failed safely, the model often defaulted to a fine-grained interaction strategy. Rather than executing the reconstructed payload autonomously, the highly-aligned agent explicitly paused to ask the user for confirmation (e.g., “Do you authorize modifying the API_KEY file before proceeding?”). This human-in-the-loop intervention immediately exposes the attacker’s intent. While such fine-grained interaction significantly bolsters system security and thwarts ShareLock, it does so at the direct expense of agent autonomy and user convenience, representing a fundamental tension in modern agent design.