ShareLock: threshold poisoning hides MCP payloads across many tools

What is this?

On June 25, 2026, Liwei Liu, Tianzhu Han, Zijian Liu, Zishu Dong and Na Ruan published ShareLock: A Stealthy Multi-Tool Threshold Poisoning Attack Against MCP on arXiv. It studies a blind spot in how the Model Context Protocol (MCP) ecosystem defends against tool poisoning: nearly every scanner inspects one tool description at a time, and ShareLock shows how to slip a payload past exactly that assumption.

Classic tool-poisoning attacks embed a malicious instruction as plaintext inside a single tool’s description, where the agent reads it and acts on it. That is effective but fragile — a monolithic malicious string is precisely what manual review and automated detectors are built to catch. ShareLock’s contribution is to remove the single point of detection. The authors report an average attack success rate above 90% across mainstream LLMs on two different MCP clients, while significantly outperforming single-tool poisoning against description-based detection. This is peer-reviewable academic work describing an attack class and its defenses; no operational payload is reproduced here.

How it works

ShareLock borrows an idea from cryptography: Shamir’s threshold secret sharing. A secret is split into n shares such that any k of them reconstruct it, but any smaller subset reveals nothing — not even partially. ShareLock treats the malicious instruction as that secret and distributes benign-looking shares across multiple tool descriptions on one or more MCP servers.

The consequence is what makes it stealthy: below the threshold, the shares carry information-theoretic secrecy. Any individual poisoned tool description, read on its own, is genuinely non-malicious — there is no hidden instruction to find in it, because a single share mathematically contains none. A per-tool scanner, an LLM-judge reviewing descriptions one by one, or a human auditor spot-checking tools all see nothing actionable.

malicious instruction  ──►  split into shares  s1 … sn   (Shamir, threshold k)

   tool A description  ⊃  s1     ← benign in isolation
   tool B description  ⊃  s2     ← benign in isolation
   tool C description  ⊃  s3     ← benign in isolation
        …                         (any < k shares reveal nothing)

   [covert reconstruction trigger planted during a server update]
        ▼
   agent aggregates ≥ k shares  ──►  reconstructs hidden instruction  ──►  action

Reconstruction is deferred. The authors describe planting a covert reconstruction trigger during a routine server update — the shares sit dormant across tools until the trigger causes the agent to aggregate at least k of them, at which point the hidden instruction reassembles and drives a breach of system assets or private data. The evaluation spans four multi-tool scenarios and two MCP clients, and it is the combination of tools, not any one of them, that is dangerous.

Why it matters

MCP’s design encourages agents to load many tools, often from several servers, and the security community has largely responded with per-tool hygiene: scan each description, gate each server, judge each tool. ShareLock shows that a detection strategy scoped to individual tools can be sound on every tool yet blind to the whole. The attack surface is the set of installed tools and how the agent composes them — a property no single-tool check can observe.

The fault tolerance is the uncomfortable part. Because reconstruction needs only k of n shares, an auditor who removes or fixes one poisoned tool has not necessarily removed the attack, as long as the threshold is still reachable. This pushes MCP defense toward the same territory as malicious MCP servers beyond tool poisoning and tool-description rug pulls: the threat lives in relationships and change over time, not in a static string.

Defenses

For teams running MCP clients or curating tool registries, the lesson is to widen the unit of analysis.

Analyze tools together, not just one at a time. Detection that scores each description in isolation is exactly what ShareLock is built to defeat. Evaluate the joint set of installed tools — cross-tool correlation, shared unusual tokens, descriptions that only make sense in aggregate — rather than assuming per-tool cleanliness composes into whole-system safety.

Treat server updates as a security event. The reconstruction trigger is planted during an update, so pin tool descriptions to a reviewed hash, diff every change, and re-audit the full tool set — not only the tool that changed — before trusting new versions.

Constrain and observe at the action layer. Because the payload only matters when it becomes an action, keep the classic control-flow defenses in place: least-privilege tool permissions, human confirmation for sensitive operations, and runtime monitoring that flags an agent doing something no individual tool’s stated purpose justifies.

Minimize and provenance-check the tool surface. Fewer tools from fewer trusted publishers lowers the odds of reaching a reconstruction threshold; require signed, provenance-tracked tool descriptions so that shares cannot be quietly distributed across a marketplace.

Status

Item	Detail
Disclosure	arXiv preprint 2606.27027 v1, submitted June 25, 2026 (CC BY-NC-SA 4.0), 16 pages
Class	Attack technique — multi-tool threshold poisoning of MCP tool descriptions via Shamir secret sharing
Mechanism	Malicious instruction split into benign-looking shares; covert reconstruction trigger planted during server update
Evaluation	Four multi-tool scenarios · two MCP clients · mainstream LLMs
Reported result	Average attack success rate > 90%; outperforms single-tool poisoning against description-based detection
Core defensive gap	Per-tool scanners cannot see a payload that exists only in the aggregate of ≥ k tools