Two agent-tool security papers landed in June. Read together, they expose the boundary between semantic detection and enforceable control.
A common response to malicious agent tools is to scan tool descriptions: inspect the text an agent is about to trust, decide whether it appears malicious, and block it if so.
ShareLock shows where that approach ends.
The technique splits a single malicious instruction into benign-looking shares using a Shamir threshold scheme, and embeds one share per tool description. Below the reconstruction threshold, a scanner cannot recover the malicious instruction from the share contents. The full instruction reconstructs only once enough shares are aggregated in the agent's context. The reported result is an average attack success rate exceeding 90% — ASR@3, across four models and two MCP clients (arXiv 2606.27027).
Be precise about what that proves. Information-theoretic secrecy protects the underlying secret below the threshold. It does not make every artifact undetectable, and it does not defeat a system that correlates the complete tool set. What it exposes is the ceiling of evaluating each tool description independently.
The second paper shows what enforceable control looks like at runtime.
WebMCP Tool Surface Poisoning (MSTI) attacks the tool registry at runtime. A third-party script fires a legitimate tool's AbortController to unregister it, then re-registers a malicious tool under the identical name before first invocation — or wins a registration race so the agent only ever sees the malicious version. AbortSignal hijacking reached 94% success; the registration race, 100% across every model tested (arXiv 2606.06387).
The paper's defense has two parts, and the distinction matters. Origin-bound, immutable tool identity stops substitution and lifecycle attacks — a malicious script cannot become a trusted tool merely by reusing its name, because validation happens on the identity bound to origin, not the public name. Capability and data-flow enforcement then limit what even a legitimately identified tool may receive or do. Together, those defenses reduced attack success to zero under the paper's tested conditions.
That is the durable lesson from the two papers. Content detection remains useful, but probabilistic. Tool identity, lifecycle integrity, and capability boundaries provide properties the runtime can enforce even when semantic inspection is uncertain.
The exposed surface here is not a weak scanner. It is an agent that trusts the tool set it was handed and never checks which tool it is calling, or what that tool is allowed to touch.
Detection asks what the tool says. Authority verification asks which tool this is — and what it is permitted to receive and do. The second question can still be enforced after the first becomes uncertain.
Top comments (1)
The ceiling/floor pairing implies the second paper's defense catches the first paper's attack. It doesn't. Origin-bound immutable identity buys close to nothing against ShareLock, because ShareLock isn't substitution. Every share-bearing tool genuinely is itself. Each one is correctly origin-bound and passes identity validation honestly, since there's no impostor anywhere in the set to catch. Identity answers "which tool is this," and under ShareLock that question has a truthful answer for every tool involved.
The half that could bite is capability and data-flow enforcement, and only when the reconstructed instruction needs some tool to step outside its own envelope. If the assembled instruction only asks each tool to do what that tool is already permitted to do, per-tool enforcement returns zero too.
The failure mode is worth naming: individually bounded, jointly unbounded. Every capability check in both papers scopes to one tool. Reconstruction happens in the agent's context, which is the one place no tool boundary covers. What the attacker collects is the composition of separately permitted capabilities, and nothing in the stack signs for the composite. Your own careful line, that ShareLock doesn't defeat a system correlating the complete tool set, points right at this, and then the synthesis walks past it. Correlating the complete tool set isn't a better scanner. It's an admission that the unit of enforcement is the wrong size.
Which is why the bound belongs at request or session scope rather than tool scope. What the task may touch, committed before dispatch, so the composite gets judged against a predicate fixed in advance instead of against the union of per-tool ACLs. A union of permitted things is not itself a permitted thing, and no check in either paper takes that union as its subject.
That reframes the zero as well. Zero against substitution, under conditions that didn't include an adversary who stays inside every envelope at once. Those are different claims and the synthesis merges them. So was the zero-ASR figure measured with a ShareLock-style payload also in play, or only against MSTI substitution?