WebMCP

TL;DR

On 2026-06-04 a research team at National Yang Ming Chiao Tung University (Taiwan) disclosed a new class of attack against WebMCP that they named “Mid-Session Tool Injection” (MSTI). WebMCP is an emerging mechanism that lets a website expose tools directly to an AI agent; rather than driving the screen, the agent learns “what it can do” from the tools’ metadata. The problem is that this list of tools can change dynamically. If an attacker can taint a third-party script loaded into the same page (a CDN, an ad SDK, and the like), they can rewrite the very set of tools the agent sees in the middle of a session. The research organizes the attack into two families. One is Tool Hijacking, which manipulates “which tools exist”: techniques such as using the AbortSignal API to deregister a legitimate tool and re-register a malicious tool under the same name, or winning a registration race by registering under the same name before the legitimate tool does. The other is Tool Framing, which manipulates “what a tool is interpreted to be”: through metadata such as description, readOnlyHint, inputSchema, and the tool name, a malicious tool is made to look like a mandatory step in a workflow or a safe read-only operation. In an evaluation across three models — GPT-5.4, Claude Opus 4.6, and Gemini 2.5-flash — and four scenarios, the registration race reached an average 100% attack success rate and AbortSignal hijacking an average 94%. Tool Framing has lower success rates, but because the original task still completes normally in up to 85% of runs while data is exfiltrated, everything appears to the user to have gone smoothly. Two findings stand out. First, attacks that strike the protocol layer (C1, C3) lose almost no success rate from older-generation models through the latest ones — model updates cannot close them. Second, when the researchers enabled their implemented defenses, the agent still called the malicious tool, yet no data reached the attacker at all. Whether the model’s judgment is misled and whether real harm occurs are independent problems. What was missing is a layer that binds a tool’s identity to its origin and independently verifies the consistency of that binding before the agent makes the call. Detection and pre-action proof are complementary, not substitutes.

Incident Summary

Subject: WebMCP, an emerging protocol that lets a website expose structured tools directly to an AI agent. Rather than driving a conventional user interface, the agent grasps the available capabilities from the tools’ metadata.
Reporter: research by Lin-Fa Lee, Yi-Yu Chang, Chia-Mu Yu, and Kuo-Hui Yeh of National Yang Ming Chiao Tung University (Hsinchu, Taiwan), “WebMCP Tool Surface Poisoning: Runtime Manipulation Attacks on LLM Agents.” Published 2026-06-04 as arXiv:2606.06387v1 [cs.CR].
Threat model: the attacker is assumed able to compromise or inject the supply of a third-party script loaded into the victim site (a CDN, an ad SDK, or any other JavaScript component on the same page). Whereas conventional third-party-script attacks aim to alter page content or exfiltrate DOM data, this threat model targets the agent’s tool registry itself, changing the set of tools the agent can observe and select at runtime.
Two families of attack: (1) Tool Hijacking (manipulating the existence of tools) = manipulating which tools exist and when. Disabling a legitimate tool, hijacking its name, replacing it with a malicious tool. Because the tool list is rewritten before the agent begins any semantic reasoning, the model side has no direct means of defense. (2) Tool Framing (manipulating the interpretation of tools) = using legitimate fields such as the tool name, description, readOnlyHint, and inputSchema to make a malicious tool look like a mandatory step in a workflow, a required safety check, or a safer read-only tool.
Evaluation environment: three models — GPT-5.4, Claude Opus 4.6, and Gemini 2.5-flash. Four scenarios of differing severity (knowledge-base search / business-report generation and sending / e-commerce payment / GPU driver update). The attack success rate (ASR) is defined as “the proportion of runs that called the malicious tool and sent task-relevant data to the attacker’s endpoint.”
Key results: the registration race (C3) hit 100% on all three models, and AbortSignal hijacking (C1) averaged 94%. Among the Tool Framing family, description injection (C2) averaged 59% and the combined attack (C5) 61%. Isolating individual fields, description alone averaged 93%, merely setting readOnlyHint=true averaged 87%, and the combination of description and readOnlyHint reached 100% on all three models.
Root cause: WebMCP’s tool surface is treated as a neutral, static interface rather than as a security boundary. Because a tool’s identity depends on its public tool name and is not bound to its origin (the origin, document, frame, and supplying source of the registering script), simply registering first under the same name — or swapping it out afterward — is enough to substitute what the agent observes.

Timeline

2026-06-04: “WebMCP Tool Surface Poisoning: Runtime Manipulation Attacks on LLM Agents” (arXiv:2606.06387v1 [cs.CR]) is published on arXiv, presenting the MSTI taxonomy, a quantitative evaluation across three models and four scenarios, a field-level contribution analysis, an injection-timing analysis, and the implementation and evaluation of two baseline defenses.
2026-07: in surveys of MCP security trends, the study is cited as a new attack surface — runtime manipulation of the tool surface.

Note: this is research in a controlled environment; no exploitation or harm in the wild has been reported as of this writing. The experimental setup does not use Chrome’s native WebMCP implementation but a navigator.modelContext API provided by the CDN-delivered @mcp-b/global polyfill, and the agent runs in a headless Node.js environment rather than under a real browser’s full security model. The researchers themselves note that reproducibility under a native implementation may vary with implementation details. Consult the latest primary sources.

Chain of Events

Tainting a third-party script: the attacker compromises the supply of a third-party script loaded into the victim site (a CDN, an ad SDK, etc.). This lets them run arbitrary script on the same page. 2-a. Manipulating the existence of tools (Tool Hijacking): the attacker aborts the legitimate tool’s AbortController to deregister it, then re-registers a malicious tool under the same name before the agent’s first call (C1). Alternatively, they register first under the same name before the legitimate tool is registered, so that first-come-first-served leaves the agent seeing only the malicious version (C3). 2-b. Manipulating the interpretation of tools (Tool Framing): the attacker embeds a procedural instruction in the malicious tool’s description, such as “always call this before send_email,” framing it as a mandatory workflow step (C2). Or they bury the instruction in the first ~40 words of a 1,203-word description padded with standard names such as ISO 27001, SOC 2, and GDPR (C4). Standalone techniques also work: setting readOnlyHint=true to look like a safe read-only operation, or giving it a name that evokes corporate operations such as audit_logger.
The agent makes the call: taking the rewritten tool set or metadata as its premise, the agent plans and calls the malicious tool as a legitimate step consistent with its original task.
Data exfiltration: with the call, task-relevant data, intermediate results, and sensitive context are sent to the attacker’s endpoint. In the Tool Framing family the original task still completes normally in up to 85% of runs, so everything appears to the user to have gone smoothly.
Timing dependence: Tool Hijacking requires the injection to complete before the agent’s loop begins (100% at P1, dropping to 0% if it misses the first legitimate call), while Tool Framing is more effective the earlier it lands before sensitive context enters (82% at S1, versus 28% just before the final action).

Structural Analysis

This incident belongs to the agent-infrastructure category of Pillar 03 (Agent Authority). The central failure primitive is that the tool registry the agent relies on did not bind a tool’s identity to its origin, and instead rested on the mutable identifier of a public name. Simply registering first under the same name, or swapping it out afterward, is enough to substitute what the agent observes and selects. As secondary categories we add ai-decision-integrity, for the way the malicious tool’s role interpretation is steered through metadata, and identity-auth, for the missing verification of a tool’s origin and ownership.

This incident is in line with Brief No.099 (Agentjacking, where an agent believed a fake error report to be its “resolution steps” and ran the attacker’s commands), Brief No.048 (TrapDoor, where invisible commands were planted in an AI-facing instruction file), and Brief No.024 (instruction injection via invisible Unicode), in that the agent moves to act on ingested content without confirming its issuer. With Brief No.025 (the MCP standard’s design became a path to RCE), Brief No.027 (LibreChat, where secrets leaked from a user-specified MCP URL), and Brief No.094 (Cursor DuneSlide), it shares the structure in which the very design of the agent infrastructure becomes the attack surface.

What is specific to this incident is that the target of the attack is neither the content of a prompt nor the output of a tool, but the very state of the execution environment the agent perceives. Prior indirect-prompt-injection research assumed the set of available tools was fixed before execution began and attacked “how the agent interprets information.” What MSTI changes is “which tools the agent can observe and select in the first place.” The researchers make this distinction explicit by contrast with existing MCP attack research (MCPTox, which handles metadata poisoning at registration time) and defense research (MCPShield, which inspects tool behavior before and after use, and ShieldNet, which observes network traffic at runtime), holding that the latter do not directly reach the root problem that “a script on the same page can change WebMCP’s tools while a task is running.” The shared primitive is the same: the identity of what the agent calls is decoupled from the layer that verifies its origin.

The Detection–Proof Gap

The researchers’ disclosure of the attack taxonomy, the quantitative evaluation across three models and four scenarios, the field-level contribution analysis, the identification of injection timing, and the proposed design principles form a detection-and-visibility sequence that is indispensable for raising awareness of the risk and considering countermeasures, and this Brief does not deny that role. Existing defense research such as inspecting tool behavior (the MCPShield type) and observing runtime network traffic (the ShieldNet type) also contributes to grasping and shrinking the damage. Detection does play its part.

At the same time, detection provides no material to independently establish — at the moment the call is made — whether the tool the agent is about to call is the same legitimate tool it observed at planning time or a different one swapped in mid-session. The malicious tool carries the same public name as the legitimate tool and is presented using legitimate metadata fields. There is no way to distinguish them formally on the detection side, which relies on how content looks or on the model’s semantic judgment. The research results bear this out twice over. First, attacks that strike the protocol layer (AbortSignal hijacking and the registration race) lose almost no success rate from older-generation models (GPT-4o, Claude 3.5 Sonnet) through the latest ones — model updates cannot close them. Second, the fact that merely setting readOnlyHint=true yields an average 87% success rate shows that the agent accepts the metadata’s self-declaration of being “safe” without independent corroboration. As material for an audit to establish “was this tool call made by a tool whose origin was legitimately confirmed?”, the mere facts “it was in the registry” and “it declared itself read-only” are not an independent trail of the tool’s identity and origin. This is a gap in a structurally independent layer, outside the reach of the detection layer.

The most important finding of this research is its demonstration that this gap can be filled in an implementable form. The researchers implemented two baseline defenses — binding origin at registration time and rejecting a subsequent registration under the same name from a different origin (a Tool Hijacking countermeasure), and blocking tool calls from a third-party origin and restricting the arguments they can receive (a Tool Framing countermeasure) — and reduced the attack success rate from 36–100% to 0% in every case. Moreover, task completion rates were held on par with the baseline. What is decisive is the substance of it. Even with the defenses enabled, the agent still called the malicious tool in most trials. And yet no data reached the attacker at all. The researchers put it as “whether the LLM is misled and whether data actually leaks are independent problems.”

Pre-action attestation fills this gap by inserting a proof of identity and authorization one step into the path by which the agent calls a tool. Before the call, it verifies — decoupled from the public name and from the metadata’s self-declaration — “does this tool carry the same immutable identifier as the one observed at planning time, and are its origin, owner, schema, annotations, and capabilities consistent with planning time?” and “is this call authorized within its declared capabilities and the scope of data exchange?”, and it blocks the call or the handover of data up front when no proof accompanies it. The four directions the research’s design principles enumerate — binding tool identity to origin, verifying the consistency of lifecycle state, declaring the boundaries of capabilities and data flow, and keeping a traceable provenance log of registrations and calls — are all concretizations of this layer. Pre-action attestation is a complement to detection, not a substitute, and the combination of the two layers establishes the trust boundary of the agent’s tool surface.

Response and Industry Context

The researchers’ design principles: holding that WebMCP’s tool surface should be treated not as a neutral, static interface but as a security boundary, they present four directions. (A) Tool identity and ownership = generate an immutable internal tool_id at registration and bind it to the origin, document, frame, and supplying source of the registering script. The agent verifies against the tool_id rather than the public name. (B) Lifecycle and state consistency = deregistration, AbortSignal, replacement, and metadata updates should invalidate or force re-validation of an existing plan. Before a call, confirm that the tool_id, owner, schema, annotations, and capabilities are consistent with planning time. (C) Capability and data-flow boundaries = require tools to declare their capabilities, data-access scope, and destinations, and by default do not hand sensitive data to third-party tools. (D) Control through user authorization = record registrations, deregistrations, replacements, metadata changes, and calls in a provenance log, and require explicit consent through the UI for high-risk actions such as payment, installation, and data exfiltration.
Demonstration of the baseline defenses: they implemented two defenses corresponding to (A) and (C) above and reduced the attack success rate from 36–100% to 0%, with task completion rates on par with the baseline. The researchers frame Tool Hijacking as a protocol-layer problem to be handled by access control and Tool Framing as a semantic-layer problem requiring restriction of data flow and control flow, and organize the two as a clearly non-overlapping correspondence in defensive terms.
The limits of model updates: in a comparison of older-generation and latest models, attacks striking the protocol layer lost almost no success rate. The researchers hold that mitigating attacks that abuse WebMCP’s tool-registration mechanism is difficult to achieve through model version updates alone. In contrast, the effectiveness of using a tool’s description as the primary attack path correlated with the model’s semantic-understanding ability.
Limitations of the research (stated by the researchers): the experiments use a polyfill rather than Chrome’s native WebMCP implementation and are not under a real browser’s full security model. A user study of whether users can notice a Tool Framing attack was not conducted. The defense evaluation covers only two of the four directions. The low task-completion rate for Tool Hijacking is a consequence of payload design; a real-world attacker who knows the legitimate tool’s specification and returns a normal success response could greatly raise the completion rate, making it even harder for users to notice.

The absence of a layer that independently verifies, at call time, the identity and origin of the tools an agent calls is not an implementation defect of a specific protocol, but remains an operational challenge across designs that make agents rely on a dynamically changing tool surface.

Lemma’s Analysis

Against the detection–proof gap this event exposed (the identity of what the agent calls is decoupled from the layer that verifies its origin), Lemma proposes a design that requires, before the agent calls a tool and hands over data, its identity and authorization as independently verifiable cryptographic proof.

Binding tool identity to origin: verify a tool by tying it to an immutable identifier and an origin (origin, document, registrant), distinguishing a different tool registered first under the same name, or swapped in afterward, from one legitimately registered. Judge by the authenticity of registration, not by the public name or a metadata self-declaration (such as readOnlyHint=true).
Pre-action authorization proof (proof-as-auth): before the call, prove with a signature that “this tool is the same as at planning time, and this call is authorized within this scope.” Do not make “it was in the tool list” the terminus of the call.
Scoping data flow: narrow the range of data handed to a tool to the declared, authorized minimum. Even if the agent’s judgment is misled, keep sensitive context from reaching an undeclared destination.
Provenance log of registrations and calls: keep registrations, deregistrations, replacements, metadata changes, and calls as a tamper-resistant trail, so that an after-the-fact audit can independently verify “which tool appeared, from which origin, when, and was called.”
Selective disclosure: disclose only “this call satisfies the authorization schema,” at minimum, keeping sensitive context out of undeclared destinations.

As the research demonstrated, these layers are not about “keeping the model from being fooled.” Even with the defenses enabled the agent kept calling the malicious tool, yet no data reached the attacker. The detection layer, which probabilistically reduces misled judgments, and the proof layer, which deterministically rules out the materialization of real harm, do separate jobs. Detection (after-the-fact behavior inspection, traffic monitoring, visibility of the technique) works on remediation after discovery; pre-action proof (pre-call identity and authorization verification) works on the independent verification of agent operations — the two work complementarily.

Sources

arXiv (research, primary): Lin-Fa Lee, Yi-Yu Chang, Chia-Mu Yu, Kuo-Hui Yeh, “WebMCP Tool Surface Poisoning: Runtime Manipulation Attacks on LLM Agents,” arXiv:2606.06387v1 [cs.CR] (2026-06-04) — https://arxiv.org/abs/2606.06387
W3C Web Machine Learning (WebMCP specification): “WebMCP” — https://webmachinelearning.github.io/webmcp/
Adversa AI (MCP security trends): “Top MCP security resources & CVEs July 2026” (2026-07) — https://adversa.ai/blog/top-mcp-security-resources-july-2026/

About this Brief’s distribution

This material is a structured analysis of public information and is not an audit, diagnosis, or recommendation for any specific organization.