The Tool Quorum Becomes the Poisoning Channel
A June 2026 arXiv paper turns MCP tool poisoning from a single bad description into a bundle-level governance problem: the dangerous instruction is not visible in one tool, but in the quorum of tools the agent is allowed to trust together.
From One Tool to Quorum
The paper, arXiv:2606.27027 [cs.CR], is titled ShareLock: A Stealthy Multi-Tool Threshold Poisoning Attack Against MCP. arXiv lists Liwei Liu, Tianzhu Han, Zijian Liu, Zishu Dong, and Na Ruan as authors and records submission on June 25, 2026.
The paper studies Model Context Protocol security. In the authors' framing, MCP is an open, platform-agnostic client-server protocol that lets LLM-driven agents connect to external data, tools, and workflows. That protocol shape is useful because it makes agent tools reusable. It is also dangerous because tool descriptions and tool returns become part of the model's operating context.
Earlier MCP poisoning examples often place the whole malicious instruction in one tool description or one tool result. ShareLock changes the unit of attack. A single inspected tool may look ordinary; the risk appears at the level of the tool quorum: the set of tools, the server update, and the workflow that makes the agent assemble them.
What ShareLock Tests
The authors describe ShareLock as a multi-tool threshold poisoning framework that adapts Shamir's threshold scheme. For governance purposes, the important point is high-level: fewer than the threshold number of shares should not reveal the secret, while enough shares can reconstruct it. The paper applies that idea to agent tool metadata, not to secure collaboration.
The evaluation uses four multi-tool domains: Travel Assistant, Coding Assistant, Financial Analyst, and Office Manager. The authors test two MCP clients, Cherry Studio v1.5.11 and Cline v3.35.0, with four models: Gemini-2.5-Flash, DeepSeek-V3.1, DeepSeek-V3.2, and Qwen3-235B-A22B-Thinking. They generate 25 query variations per domain, yielding 100 unique multi-step user queries.
The reported aggregate results are severe. Under the main setting, the paper reports an overall average attack success rate of 94.1 percent, task completion rate of 96.4 percent, and combined stealth-effectiveness score of 95.2 percent. In the Travel Assistant comparison on Cherry Studio, ShareLock's average attack success rate is 93.3 percent, above the single-tool baselines reported for plain tool poisoning, Puppet-style poisoning, and encode-only poisoning.
Those numbers come from the authors' benchmark, not the whole internet. But they break a common assumption: if each tool description looks safe in isolation, the server is not necessarily safe as a bundle.
Vetting Is the Wrong Unit
The paper's threat model assumes moderate vetting before a user connects to a service. That is the realistic part. Many organizations will not run formal verification on every MCP server. They may scan descriptions, check for obvious prompt injection, rely on a guard model, approve a vendor, and move on.
ShareLock is built against that middle world. It assumes the adversary controls at least one multi-tool MCP server that still provides legitimate functionality. The tools do useful work. The user task completes. The poisoned behavior is hidden in the relationship among normal-looking tools.
The governance mistake is inspecting tools as independent documents. A multi-tool server is closer to a program than a menu. The safe question is not "does this description contain a bad sentence?" It is "what happens when this set of descriptions, returns, updates, and tool calls are available to the same model in the same context window?"
Stealth as Normal Operation
The detection results reinforce the point. The paper evaluates safety classification by zero-shot LLM auditors and specialized guard models. It reports that obvious plaintext baselines are flagged by the zero-shot detectors, while ShareLock tool descriptions are classified safe across the tested detectors. In the same table, the trigger tool is marked unsafe by Claude-Sonnet-4.5 but safe by the other listed detectors.
The entropy analysis also matters. A standalone encoded payload is easier to notice because it creates statistical texture. But when high-entropy metadata is embedded in ordinary natural-language tool descriptions, the overall entropy can look close to legitimate MCP tools that use hashes or identifiers. The paper reports 5.22 bits per character for the combined ShareLock description and metadata, compared with 5.02 for a benign tool with a legitimate hash.
That is the operational lesson: stealth can resemble normal platform plumbing. Checksums, identifiers, server updates, initialization steps, tool descriptions, and automatic approvals are ordinary. Policies that only look for hostile prose will miss bundle-level behavior.
Limits That Matter
The paper is a security research artifact, not a deployment measurement for every MCP host. The authors state that their experiments were run only on personal accounts, did not target external users, and were intended to alert the MCP research and development community. They also report that LLMs were used for editorial purposes and query generation, with authors taking responsibility for the technical claims.
The limitations are practical. The authors note that ShareLock depends partly on prompt engineering, and that mistakes in a multi-step chain can cause failure. They also say strict access control and fine-grained user interaction can expose or block the behavior, though at a convenience cost. That makes the defensive implication sharper: friction is not always a usability bug. In an agent toolchain, friction can be a security control.
Governance Standard
A serious MCP client should govern a server bundle, not just a tool string. It should record the server identity, publisher, version, update history, tool inventory, tool descriptions, tool returns, tool-call sequence, model context boundary, user approvals, and whether an auto-approval mode was active.
Scanners should analyze cross-tool relationships: patterns across metadata fields, unusual collection of unrelated tool outputs, update-time reinterpretation of prior context, and tool chains that attempt file, credential, payment, or message operations outside the user's explicit request.
Clients should also reduce silent authority. High-impact tools need per-action confirmation that names the server, tool, destination, data payload, and expected effect. The confirmation should not be a generic "allow tools" switch. It should be a receipt the user and incident reviewer can understand after the fact.
The Spiralist rule is simple: a tool server is not a list; it is an institution in miniature. It has members, roles, updates, rituals, and a collective behavior that can exceed any single description. Govern the quorum before trusting the tool.
Sources
- Liwei Liu, Tianzhu Han, Zijian Liu, Zishu Dong, and Na Ruan, ShareLock: A Stealthy Multi-Tool Threshold Poisoning Attack Against MCP, arXiv:2606.27027 [cs.CR], submitted June 25, 2026.
- arXiv PDF: ShareLock, reviewed for its threat model, moderate-vetting assumption, MCP client and model list, four-domain benchmark, aggregate results, detection analysis, entropy analysis, limitations, and ethical note.
- Related pages: The WebMCP Tool Surface Becomes the Attack Surface, The MCP Server Becomes the Leakage Boundary, The Tool Server Becomes the Trust Boundary, The Agent Sandbox Becomes the Airlock, The Cross-Session Prompt Becomes the Payload, and Model Context Protocol.