WebMCP tool surface poisoning: hijacking a browser agent mid-session

What is this?

WebMCP is an emerging web capability that lets a website expose structured tools directly to an AI agent driving the browser — including agents that run inside an extension. Instead of the agent guessing how to click a page, the site declares callable tools (with names, parameters, and descriptions) that the agent can invoke. That convenience creates a new, dynamic attack surface: the set of tools available to an agent, and the metadata describing them, are supplied by the very web page the agent is reading, and they can change at runtime.

A June 2026 arXiv paper, WebMCP Tool Surface Poisoning: Runtime Manipulation Attacks on LLM Agents (2606.06387), formalises this as Mid-Session Tool Injection (MSTI) — manipulating an agent’s tool surface during an active session rather than through a static, pre-registered manifest. In the same month, Chrome published official security guidance for agents that use WebMCP (June 9, 2026), and Adversa AI’s July 2026 MCP roundup listed the technique among the month’s notable agent threats. Because this is a design-level weakness of how agents consume tool definitions, it is worth understanding before WebMCP adoption widens.

How it works

MSTI works because an LLM treats tool metadata and tool output as part of the same token stream it reads for instructions — the classic indirect prompt injection problem, applied to a live tool registry. The research groups the attacks into two families.

Tool hijacking changes which tools the agent sees. A third-party script on the page can register or deregister tools after the agent has already started a task, exploiting timing gaps — for example a registration race, or cancelling an in-flight registration via the browser’s AbortSignal API — so the agent ends up with a tool set the site author never intended. Tool framing leaves the tool set alone but manipulates how the agent perceives each tool, by planting misleading content in metadata fields such as the tool name, description, readOnlyHint, or inputSchema. A tool annotated as read-only, or described as harmless, can thereby be steered toward an action the user never authorised.

Chrome’s guidance frames the same surface as two vectors: malicious manifests (hidden instructions embedded in tool names, parameters, or descriptions) and contaminated outputs (a trustworthy site returning third-party data — a user comment, say — that carries injected instructions). The conceptual flow, with no working payload reproduced:

[ web page ] -- declares/mutates --> [ WebMCP tool surface ]
      │                                        │
      │ third-party script                     │ metadata: name, description,
      │ (registration race / AbortSignal)      │ readOnlyHint, inputSchema
      ▼                                        ▼
[ tool set the agent sees ]  ◄── poisoned ──  [ attacker-influenced framing ]
      │
      ▼
[ agent plans + calls tools in the user's authenticated session ]

The paper reports high attack success rates for these runtime manipulations. Because the injected control lives in the tool layer rather than in the visible page text, it can slip past defenses that only inspect page content.

Why it matters

The severity comes from where browser agents run: inside the user’s authenticated session. An agent logged into email, a CRM, a code host, or an accounting app inherits every permission that session already holds. A hijacked or misframed tool call can then read, send, modify, or delete data with no additional authentication prompt. MSTI raises the stakes over static tool poisoning because the manifest an agent validated at the start of a task is not guaranteed to be the manifest it acts on moments later — trust established once does not hold for the session.

Defenses

Chrome’s June 2026 guidance recommends a defense-in-depth split between deterministic and probabilistic guardrails, and it maps cleanly onto MSTI.

Set deterministic guardrails: cap inbound tool-response tokens and reject payloads that exceed the limit; restrict the set of web origins an agent may interact with to those relevant to the current task, shrinking the exfiltration surface; and keep a human in the loop by requiring confirmation for state-changing actions — assume a tool mutates state unless its annotations clearly prove otherwise, and never trust readOnlyHint as a security control.

Add probabilistic guardrails: apply spotlighting so the model treats tool output and tool metadata as untrusted data, not instructions. Chrome describes two methods — lightweight delimiting for low-risk content, and base64-encoding untrusted content for high-risk cases (robust against delimiter-injection evasion, at roughly a third more tokens) — anchored by a system instruction that tells the model to decode for inspection only and never execute what it finds.

Layer classifiers and critics: scan tool descriptions and tool output for injected instructions before any call executes, and use a separate “critic” model — not exposed to the untrusted content — to check that each planned tool call aligns with the user’s actual goal and carries only the minimum data required. Finally, re-validate the tool surface continuously rather than once at task start, treat mid-session tool registration and deregistration as security events, and watch production for anomalies such as token-exhaustion spikes. Open-source red-teaming suites (for example Promptfoo) and agent-auditing tools can quantify whether these mitigations actually hold before shipping.

Status

Item	Reference	Date	Notes
Research paper	WebMCP Tool Surface Poisoning, arXiv 2606.06387	June 2026	Formalises Mid-Session Tool Injection (MSTI)
Attack families	Tool hijacking; tool framing	June 2026	Registration race / AbortSignal; metadata manipulation
Vendor guidance	Chrome — Agent security considerations for WebMCP	2026-06-09	Deterministic + probabilistic guardrails
Industry tracking	Adversa AI — MCP security roundup	2026-07-06	Listed as a July 2026 agent threat
Affected surface	WebMCP-enabled browser agents, incl. extensions	—	Runs inside the user’s authenticated session