A new attack against AI coding and automation agents does not hide its instructions in one place. It hides them in three, four, or five places at once, splits mathematically so that no single piece means anything on its own. Researchers at Shanghai Jiao Tong University call it ShareLock, and in testing across four large language models it hijacked AI agents more than 90 percent of the time while evading the tool-description scanners built to catch exactly this kind of attack.
The paper, posted to arXiv on June 25, 2026 by Liwei Liu, Tianzhu Han, Zijian Liu, Zishu Dong, and Na Ruan, targets the Model Context Protocol, the open standard Anthropic introduced in 2025 to let AI agents call external tools. MCP has since become the default way products like Claude Desktop, Cherry Studio, and Cline connect language models to web search, file systems, and terminals. That growth created an obvious weak point: the natural-language descriptions that tell an agent what a tool does are themselves untrusted text sitting inside the model’s prompt.
ShareLock does not exploit a bug in MCP. It exploits the protocol working exactly as designed, combined with a cryptographic trick borrowed from a 1979 paper that has nothing to do with AI at all.
The mechanism: turning a defense into an attack
Tool Poisoning Attacks are not new. Since Invariant Labs first documented them in 2025, security researchers have known that a malicious MCP server can embed hidden instructions inside a tool’s description field, the text the model reads to decide when and how to call that tool. Anthropic’s own MCP documentation warns that the model treats these descriptions as part of its system prompt. If an attacker controls the server, they control part of what the model believes it was told to do. MITRE’s ATLAS framework for cataloging AI attack techniques already lists tool poisoning as a distinct technique class, and a benchmark this site covered, LLMail-Inject, found similar injection attacks succeeding against email agents at rates the defenders did not expect.
The problem for attackers is that this trick is now well known. Guard models like Llama Prompt Guard and scanners like MCPSafetyScanner and MCP-Guard flag tool descriptions that contain obvious commands (“ignore previous instructions,” “read the file at…”). Even encoded payloads, where the malicious text is written as Base64 or hex to dodge keyword filters, get caught by dedicated detectors such as UniGuardian, which the ShareLock paper cites as capable of undoing simple encodings and restoring detectability.
The Shanghai Jiao Tong team’s insight was to stop hiding the payload and instead make it mathematically impossible to see, using Shamir’s Secret Sharing, a scheme cryptographer Adi Shamir published in 1979 for splitting a password or key among several people so that no subset smaller than an agreed threshold can reconstruct it. The scheme works through polynomial interpolation: pick a polynomial of degree t-1, set its constant term to the secret, hand out n different points on that curve as n unique “shares,” and require any t of those points to solve for the original polynomial and recover the secret. Fewer than t points reveal nothing, not even statistically. It is the same mathematics used to protect Bitcoin private keys and enterprise root certificates.
ShareLock repurposes that guarantee against the AI system it is embedded in. Instead of splitting a private key, the attacker splits a malicious instruction. The three-phase process works like this:
Phase one, encoding. The malicious prompt is converted into a numeric string using a simple, reversible mapping between characters and numbers. This step alone does nothing to hide the content; it just makes the payload usable in the arithmetic that follows.
Phase two, share generation. For a chosen threshold t, the attacker builds a random polynomial of degree t-1 with the encoded payload buried as the constant term. Every tool the attacker controls on the malicious MCP server gets assigned a unique ID, and that ID is plugged into the polynomial to produce one point, one “share.” Each share is then dressed up as an innocuous-looking parameter, given a fake name like tool_id or checksum, base64-encoded, and prefixed to look like a SHA-384 hash. To a human reviewer or an automated scanner reading any single tool description in isolation, the share looks like harmless metadata. Because Shamir’s scheme is information-theoretically secure, this is not an approximation: mathematically, a share below the threshold carries zero information about the hidden instruction, regardless of how much computing power an auditor throws at it.
Phase three, reconstruction. The attacker plants a disguised trigger tool, named something like EnvSetup, that arrives through what looks like a routine server update. Once the agent has called enough of the poisoned tools in the course of a normal task, and it has aggregated at least t shares in its context window, the trigger tool instructs the model to run Lagrange interpolation on the collected shares. The model does this itself, as part of following what it believes is a legitimate configuration step, and reconstructs the original malicious instruction from numbers that individually meant nothing.
The result is an attack with a formal robustness guarantee that traditional single-tool poisoning never had. If a security review strips out some of the poisoned tools, the attack survives as long as t shares remain, because that is precisely the fault tolerance Shamir’s scheme was built to provide. The paper’s authors even prove this as a corollary: for any surviving share set of size at least t, reconstruction succeeds with probability 1.
The numbers, and how they got them
The team tested ShareLock against four models, Google’s Gemini 2.5 Flash, DeepSeek-V3.1, DeepSeek-V3.2, and Qwen3-235B-A22B-Thinking, running inside two real MCP clients, Cherry Studio and Cline, across four simulated agent domains: a travel assistant booking flights and hotels, a coding assistant handling GitHub and deployment tools, a financial analyst, and an office manager. In every domain the attacker’s concrete goal was to make the agent read a fake local API key file and silently append a marker to it before finishing the user’s actual task, a stand-in for real-world credential theft.
With the reconstruction threshold set to t=2, meaning the agent needed only two of the scattered shares to trigger the attack, ShareLock hit an average Attack Success Rate of 94.5 percent across all four models and both clients in the travel-assistant scenario, and stayed above 90 percent averaged across all four domains. Crucially, the researchers also tracked Task Completion Rate, whether the agent still finished the user’s original request, which stayed high enough that the attack would not tip off a user through an obviously broken session. They combined both into an Attack Stealth Effectiveness score, the harmonic mean of success and stealth, which came in at roughly 94 to 99 percent depending on the model.
Why it matters
The significance here is not the specific attack scenario, since a fake api_key file is a lab stand-in. It is what ShareLock proves about the current generation of MCP defenses: they were built to catch content, and this attack has no malicious content to catch until the last possible moment, inside the model’s own reasoning process, where no external scanner is watching.
That timing gap lines up with what the National Security Agency flagged in its own May 2026 guidance on MCP, “Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation.” The NSA’s Artificial Intelligence Security Center singled out unverified task propagation and the protocol’s inversion of the usual client-server trust relationship as structural risks, and recommended treating every automated tool action as high-risk regardless of how benign its description looks. ShareLock is close to a proof of concept for exactly that warning: a benign-looking description is precisely what a t-of-n threshold share is designed to be.
It also raises the bar for what “moderate vetting” can catch. The paper explicitly frames its threat model around a defender who reviews MCP servers before connecting to them, a stronger assumption than earlier poisoning research, which often assumed no vetting at all. ShareLock still gets through, because the vetting target, a plaintext malicious string, no longer exists anywhere in the artifact being reviewed.
Limitations the paper does not hide
To its credit, the ShareLock team is direct about where the attack breaks down, and those failure conditions matter as much as the success rate.
The threat model requires the attacker to already control a multi-tool MCP server that a target has chosen to connect to, either because it offers genuinely useful functionality or through a supply-chain compromise of an existing server. ShareLock does not get an attacker onto a machine; it only makes the attack harder to catch once they are already positioned there. The paper also assumes the target agent has real multi-tool orchestration capability, since the whole scheme depends on the model naturally calling several poisoned tools in the course of a normal task, then trusting a disguised trigger tool enough to run interpolation on command.
The evaluation covers four models and two clients, a reasonable spread but not evidence that every production agent behaves the same way. Models with stricter tool-invocation guardrails, such as the Tool Invocation Prompt defenses the paper cites as already deployed in Claude Code, were not part of the benchmark. The authors also note their own failure cases in an appendix: some models refused to execute the reconstructed instruction even after successfully assembling it, particularly when the resulting action was flagrantly outside the scope of the user’s request. Refusal after reconstruction is a real, if inconsistent, backstop.
Finally, information-theoretic secrecy is a property of the mathematics, not of every real-world implementation. The paper’s own robustness proof depends on truly random polynomial coefficients and an auditor with no knowledge of the encoding scheme. A defender who suspects threshold-based obfuscation specifically, and builds a detector looking for structurally unusual numeric sequences across a tool ecosystem rather than judging each tool in isolation, is attacking a different, weaker part of the system than the one Shamir’s scheme protects.
What happens next
ShareLock’s authors frame their threshold construction as generalizable to “a broader class of distributed prompt-injection threats,” and that is the detail worth watching. Nothing about splitting a payload across benign-looking carriers is unique to MCP tool descriptions. The same construction could, in principle, distribute shares across tool return values, resource metadata, or even separate MCP servers a single agent connects to, none of which the current paper tests.
The practical response is architectural rather than another content filter. Detection that inspects each tool description in isolation cannot see a threshold scheme by construction, since that is the entire point of the mathematics. What can catch it is cross-tool statistical analysis, looking for structured numeric noise repeated with suspicious regularity across a server’s toolset, or a harder architectural fix: refusing to let a model treat any tool description as an instruction to execute arithmetic or reconstruction logic on other context in the first place. The NSA’s May guidance already points toward the second option, recommending that automated actions be scoped and permissioned independently of how trustworthy their triggering description appears. ShareLock is the clearest evidence yet of why that separation needs to be enforced by the protocol and the runtime, not by asking a language model to spot cryptography hidden in its own context window. That separation is about to get harder to enforce by default, not easier: the protocol’s own July 28 stateless rewrite adds response caching that extends exactly the window a scattered share sits trusted before anyone looks again.