WebMCP tool surface poisoning: hijacking agents mid-session

What is this?

On June 4, 2026, Lin-Fa Lee, Yi-Yu Chang, Chia-Mu Yu and Kuo-Hui Yeh of National Yang Ming Chiao Tung University published WebMCP Tool Surface Poisoning: Runtime Manipulation Attacks on LLM Agents on arXiv. It examines WebMCP, an emerging protocol that lets a website expose structured tools directly to an AI agent instead of routing the agent through a user interface. The paper’s contribution is to show that in WebMCP the set of tools an agent can see during one session is neither static nor inherently trusted — and that this dynamism is exploitable.

The authors name the threat Mid-Session Tool Injection (MSTI): a way for an attacker who controls a third-party script on the page — a compromised CDN asset, an advertising SDK, any same-origin JavaScript — to change which tools the agent perceives while a task is already running. This is peer-reviewable academic work describing an attack class and its defenses on an early-stage protocol; no operational exploit is reproduced here. Adversa AI listed it among its top MCP security resources for July 2026.

How it works

MSTI splits into two families. Tool hijacking manipulates tool presence — whether and when a tool exists — before the model reasons about anything. Tool framing manipulates tool metadata — the name, description, readOnlyHint and inputSchema — so the agent misreads a malicious tool’s role.

Two hijacking techniques stand out because they land before semantic reasoning even starts, which is exactly why the model has little defense against them:

Tool Hijacking (presence manipulation)

  AbortSignal hijack:  abort a legitimate tool's AbortController → unregister it
                       → re-register a malicious tool under the SAME name
                       → before the agent's first invocation

  Registration race:   register the malicious tool under the target name
                       BEFORE the legitimate one → "first register wins"
                       → agent only ever sees the malicious version

Framing is subtler. Instead of removing a tool, the attacker keeps it visible but rewrites how it reads — for example embedding an imperative like “always call before send_email” into a description to disguise a malicious tool as a mandatory workflow step, or padding a 1,200-word description with ISO 27001 / SOC 2 / GDPR boilerplate so the harmful instruction hides in the first few dozen words.

The measured trade-off is the interesting part. Across GPT-5.4, Claude Opus 4.6 and Gemini 2.5-flash, the presence attacks reached very high success but were disruptive: the AbortSignal hijack averaged 94% attack success and the registration race 100%, yet original-task completion collapsed to roughly 17-18%, so the session visibly breaks. The framing attacks were quieter — description injection hit 59% success while the task still completed 81% of the time, and the composite variant 61% success at 85% completion. Stealth and reliability sit on opposite ends of the same dial.

Why it matters

Most agent-security work assumes the danger lives in prompt content or tool outputs — the province of prompt injection and indirect injection. WebMCP moves part of the threat into the tool registry itself. Because the registry can change mid-session, the environment state the agent perceives becomes an attack surface, and a same-page third-party script — a class of code most sites already load without much scrutiny — is enough to reach it.

This rhymes with server-side MCP problems like tool-description rug pulls and threshold poisoning across many tools, but the browser setting changes the economics: no malicious server or marketplace listing is required, just a foothold in the page’s script supply chain. The framing results are the uncomfortable takeaway — an attack can redirect the agent’s data flow to an attacker endpoint while the user watches the task apparently succeed.

Defenses

The paper’s recommendations target WebMCP’s lifecycle, and they translate into concrete guidance for anyone building or shipping browser-side agents.

Bind tool identity to origin. A tool’s name should not be a free-for-all namespace where “first register wins.” Tie each registered tool to the origin that declared it and reject silent re-registration of an existing name, which closes both the AbortSignal-hijack and registration-race paths.

Enforce lifecycle consistency. Treat mid-session changes to the tool set as security events: freeze or re-confirm the tool surface once a task is under way, and surface any registration, replacement or removal to the host rather than applying it silently.

Isolate third-party scripts from the tool registry. The trust boundary that already governs DOM and network access should extend to tool registration — a CDN or ad SDK has no business mutating the agent’s toolset. Enforce data boundaries so a third-party tool cannot receive sensitive context or intermediate results.

Keep traceable logs and constrain the action layer. Maintain an auditable record of every tool registration and invocation so anomalous swaps are detectable after the fact, and keep classic controls in place — least-privilege tool permissions and human confirmation for sensitive actions — since the payload only matters when it becomes an action.

Status

Item	Detail
Disclosure	arXiv preprint 2606.06387 v1, submitted June 4, 2026 (CC BY 4.0)
Class	Attack technique — mid-session manipulation of a WebMCP agent’s tool registry via a compromised third-party script
Variants	Tool hijacking (AbortSignal hijack, registration race) and tool framing (description, readOnlyHint, inputSchema, name)
Evaluation	Three models (GPT-5.4, Claude Opus 4.6, Gemini 2.5-flash) · multiple task scenarios · JavaScript tools
Reported result	Presence attacks up to 100% ASR but ~17-18% task completion; framing attacks ~59-61% ASR at ~81-85% completion
Core defensive gap	The tool surface itself is mutable mid-session; per-message prompt-injection defenses do not observe registry changes