ShareLock: Shamir's Secret Sharing Applied to MCP Tool Poisoning
Existing MCP tool poisoning embeds the entire malicious payload in a single tool description, which is detectable by both manual review and automated scanners. ShareLock, published in an academic paper on arXiv on 25 June 2026, takes a fundamentally different approach: it distributes the payload as cryptographic secret shares across multiple tool descriptions using Shamir's threshold scheme. No individual tool description contains a complete instruction. None looks suspicious in isolation. A covert reconstruction trigger planted during a server update reassembles the shares at runtime, producing the original instruction inside the agent's context with an attack success rate exceeding 90 per cent and entropy characteristics statistically indistinguishable from benign tool descriptions.
What happened
Standard MCP tool poisoning embeds malicious instructions directly inside a single tool's description field, the natural-language metadata that tells the agent what a tool does and when to invoke it. The attack works because the model treats description text as part of its instruction context. The weakness is that a complete instruction is detectable: automated scanners like MCPSafetyScanner can flag suspicious strings, and a careful human reviewer can spot embedded commands in a tool description.
ShareLock addresses this by applying Shamir's threshold secret-sharing scheme to the poisoning problem. The attacker chooses a threshold k out of n tools. The malicious instruction is split into n shares, each of which looks like a plausible fragment of natural language when read in isolation. Each share is embedded across the description fields of one of the target tools in an MCP server under attacker control. The shares are individually harmless; no single tool description contains a complete instruction, and each is statistically indistinguishable from a benign description by entropy analysis.
A covert reconstruction trigger is planted separately, typically in a server update. When the trigger fires, the agent aggregates the shares from the threshold set of tools, Shamir's algorithm reconstructs the original instruction from any k shares, and the assembled payload enters the agent's context as if it were legitimate tool metadata. The agent acts on it with whatever permissions it holds. Researchers evaluated ShareLock across four multi-tool scenarios against GPT-5, Claude Sonnet 4.5, and Gemini 2.5 Flash, achieving attack success rates above 90 per cent while the same mainstream models classified the individual tool descriptions as safe.
The paper also demonstrates fault tolerance: even if the agent only loads a subset of the poisoned tools, a threshold configuration of k out of n means the attack succeeds as long as the minimum threshold is met, giving the attack resilience against partial tool allowlists. The researchers open-sourced a benchmark and released code demonstrating the technique.
The PolicyLayer angle
ShareLock is the answer to the question: what happens when defenders rely on single-tool description scanning to detect poisoning? The answer is that the attack moves to multiple tools and distributes the payload below any per-tool detection threshold. This has a direct consequence for how tool allowlists should be constructed: an allowlist that approves individual tools in isolation without tracking the aggregate of what their descriptions say collectively leaves the door open to distributed poisoning.
The control that addresses ShareLock specifically is cross-tool description analysis at the session level. Before an agent session begins, the policy layer should treat the complete set of tool descriptions for the session as a joint input surface, not a set of independent strings. A scan that looks for semantic coherence across descriptions, not just flagged strings within each one, can detect fragment-based payloads that pass per-tool inspection. This is a different capability than what existing per-tool scanners provide.
The reconstruction trigger mechanism gives a second interception point: the trigger must fire during a server update and must somehow reach the agent's context. A policy that gates on tool description changes at session boundary, requiring re-review when any tool in the session has an updated description, breaks the trigger delivery path. This is the same re-validation control that addresses the Microsoft Copilot Studio rug-pull pattern; ShareLock confirms it is the right default for multi-tool sessions regardless of the specific attack variant.
Mitigations
ShareLock has no vendor patch; it targets the MCP tool-description trust model rather than a single product bug. Reduce exposure by minimising the number of tools any one agent session loads and preferring MCP servers whose full tool set you can review. Detection requires cross-tool analysis: evaluate the complete set of tool descriptions presented in a session together rather than each description in isolation, because individual shares are statistically indistinguishable from benign text. Re-review tool metadata after any server update, since reconstruction triggers are typically introduced through an update. Gate any high-impact tool call behind out-of-band approval so a reconstructed instruction cannot act autonomously.
FAQs
No. The attacker needs to control a single MCP server that exposes multiple tools. Each tool in that server carries one share of the distributed payload. Because a single malicious MCP server can register many tools, the threshold configuration can be entirely within one server the agent has been permitted to connect to.
The paper's entropy analysis shows that ShareLock payloads are statistically indistinguishable from benign tool descriptions at the per-tool level. Current scanners that evaluate individual descriptions in isolation, including MCPSafetyScanner, do not detect the distributed form. Detection requires cross-tool semantic analysis across the full tool set presented in a session.
Standard tool poisoning embeds the complete malicious instruction in one tool's description. ShareLock distributes the instruction as cryptographic shares across multiple tools, using Shamir's secret-sharing mathematics to ensure that any k-of-n subset reconstructs the full payload. Individual shares are not instructions; they read as natural language fragments. The attack only becomes active after reconstruction inside the agent's context, after which existing in-context safety classifiers also fail to detect it at the same rates as baseline poisoning.