Blog · arXiv Analysis · Last reviewed June 24, 2026

The WebMCP Tool Surface Becomes the Attack Surface

The June 2026 arXiv paper WebMCP Tool Surface Poisoning: Runtime Manipulation Attacks on LLM Agents, by Lin-Fa Lee, Yi-Yu Chang, Chia-Mu Yu, and Kuo-Hui Yeh, argues that the tools a website exposes to an agent can themselves become a live security boundary.

For this essay, tool surface poisoning means runtime manipulation of the machine-readable tool environment an agent uses to decide what it can call. The poisoned object is not only page text or a tool result. It is the agent's perceived menu of capabilities: tool names, descriptions, schemas, read-only hints, ownership, lifecycle state, and exposure boundary.

The Page Becomes a Tool Registry

Agentic browsing changes the web page from a surface for reading and clicking into a registry of callable capabilities. A page can advertise structured operations to an agent: search, summarize, save, generate, send, purchase, install, or update. The agent does not only inspect pixels. It reads the tool surface and chooses actions from it.

The Lee, Chang, Yu, and Yeh paper studies WebMCP, a web-facing version of this pattern in which websites expose tools directly to LLM agents. Its security point is precise: if the tool list can change during a session, the agent's world model can be manipulated without changing the user's original request.

This is different from ordinary prompt injection. The attacker is not merely adding hostile text to a page. The attack shifts which tools appear available, when they appear, or how their roles are framed. The agent may still believe it is completing the original task. The route has changed underneath it.

That makes the page a small, temporary tool registry. The registry is built from browser state, page JavaScript, origin policy, iframes, tool metadata, and whatever agent or bridge reads the page. If that registry is mutable, then the agent's action space is mutable. If the action space is mutable, it needs provenance, permissions, and receipts.

Current Context

As of June 24, 2026, WebMCP should be treated as an active draft and implementation surface, not as a settled W3C standard. The WebMCP Community Group draft says the API enables web applications to provide JavaScript-based tools to AI agents, and explicitly notes that it is not a W3C Standard or on the W3C Standards Track. Chrome's WebMCP documentation describes it as a proposed web standard, published in May 2026 and updated June 9, 2026, with an origin trial from Chrome 149 and a local development flag.

The current draft centers the API on document.modelContext. It defines a model context with a tool map, tool definitions, names, descriptions, input schemas, read-only hints, untrusted-content hints, exposed origins, registration through registerTool(), tool unregistration, and toolchange events. Chrome's documentation adds the deployment shape: WebMCP tools run in an open browser tab or webview, are gated by origin isolation and Permissions Policy, and default to top-level and same-origin contexts unless cross-origin iframes receive explicit allow="tools".

The paper's experiment should be read with that version discipline. It reports a real browser page using the CDN-loaded @mcp-b/global polyfill, a navigator.modelContext surface, and a Node.js ProxyClient connected to model APIs from OpenAI, Anthropic, and Google. The authors explicitly state that their setup is not Chrome's native WebMCP implementation and not the full browser security model. That limitation does not make the attack irrelevant. It identifies exactly where production implementations need evidence: native browser behavior, extension behavior, iframe exposure, toolchange handling, schema validation, and origin enforcement.

This connects the paper to the site's broader MCP work. Model Context Protocol standardizes backend tool servers. WebMCP moves a similar idea into the browser page, where ordinary web supply-chain risks meet AI browser control surfaces, tool-server trust boundaries, and MCP leakage boundaries.

What the Paper Tests

The paper, arXiv:2606.06387, was submitted on June 4, 2026. It introduces Mid-Session Tool Injection, or MSTI, as a class of attacks against dynamically exposed WebMCP tool surfaces. The authors distinguish two broad categories. Tool Hijacking changes the set of tools visible to the agent. Tool Framing changes how the agent interprets a tool through fields such as name, description, read-only annotation, or schema.

The authors evaluate multiple scenarios with three large language model agents and track whether the agent invokes a malicious tool, whether task-related data is sent to an attacker endpoint in the testbed, and whether the original task still appears to complete. That last measure matters. A failed task is visible. A task that succeeds while leaking or redirecting data is harder to detect.

The results are strongest where they show the difference between disruption and stealth. The paper reports that some Tool Hijacking attacks reached data-exfiltration rates up to 100 percent but often interfered with normal task completion. Tool Framing attacks were less visibly disruptive and preserved task completion rates up to 85 percent in the reported scenarios. The authors also found that metadata fields such as descriptions and readOnlyHint materially affect model behavior.

For this article, the operational details are less important than the design lesson: dynamic tool availability is not just a convenience feature. It is a security state that can be attacked, logged, constrained, and audited. A tool list is not a neutral convenience layer once the model can act from it.

Why MSTI Is Different

Mid-Session Tool Injection is not just another name for prompt injection. Prompt injection attacks the content the model reads. Tool poisoning attacks the model-visible tool layer. MSTI adds a lifecycle dimension: the attacker changes what the agent can observe or believe about tools after the session is already underway.

That matters because many safety reviews happen at connection time. A browser, extension, or host may inspect a page's tools, decide they look harmless, and proceed. MSTI asks what happens after that moment: a legitimate tool is unregistered, a malicious one appears, a name is shadowed, a description changes, a read-only hint misleads, or a tool list refresh arrives at a different moment than the agent expects.

In the paper's threat model, the attacker does not need to control the whole website. A compromised or injected third-party script on the same page can manipulate the tool registry. That is an ordinary web supply-chain failure with a new consequence: the third-party script can now influence the machine actor's verbs.

The core governance question is therefore not only "is the page trustworthy?" It is "which script, origin, frame, and lifecycle event caused this exact tool to be visible at this exact moment, and what data did the agent send after seeing it?"

Metadata as Control Surface

Tool metadata is not documentation in the old sense. In agent systems, metadata is part of the decision environment. A model may use a name, description, argument schema, and annotation to infer what a tool is for and whether it is safe to call. That makes the metadata itself a control surface.

The paper's Tool Framing category is important because it shows that an attacker does not always need to replace the legitimate workflow. A malicious tool can be made to look like a routine helper, a compliance step, a preflight check, or a harmless read-only operation. The model is then being steered through its interpretation of the registry.

This connects directly to tool servers as trust boundaries and Model Context Protocol. The MCP tools specification already says clients must treat tool annotations as untrusted unless they come from trusted servers. WebMCP raises the same problem inside the page. A tool registry should not be treated as a neutral list that the model can read and rank freely. It is part of the authorization and provenance layer.

The useful policy is to treat metadata as instruction-bearing code. Names, titles, descriptions, schemas, examples, annotations, exposed origins, and read-only hints should be reviewable, versioned, diffed, and attached to a tool owner. A changed description should not be more invisible than a changed JavaScript file if the description changes the agent's behavior.

The Third-Party Script Problem

The paper's threat model focuses on third-party scripts loaded by the victim website, such as code from a CDN, advertising SDK, or other same-page JavaScript component. That is a realistic web-governance problem. Modern sites are composite systems. They routinely load code from analytics, advertising, payments, support widgets, tag managers, experiments, and content networks.

If those scripts can affect what tools an agent sees, then the agent inherits the page's supply chain. A third-party script is no longer only a privacy or DOM-integrity risk. It can become a tool-registry risk: a way to influence the machine actor's available verbs.

This is where the AI browser control surface becomes concrete. A human user may notice a strange button. An agent may only see a plausible tool definition. Browser security, agent security, and web supply-chain security collapse into one workflow.

Existing web controls still matter. Content Security Policy can restrict which resources a page can fetch or execute. Subresource Integrity gives user agents a way to verify that a fetched resource was delivered without unexpected manipulation. Permissions Policy can decide whether cross-origin iframes may use a feature such as tools. Origin isolation can keep the origin stable for WebMCP's lifetime. None of those controls, by itself, tells the agent whether a tool's natural-language description is honest, whether a read-only hint is safe to trust, or whether a mid-session toolchange should invalidate a plan.

Browser Controls Are Necessary

The right lesson is not "never expose tools from pages." WebMCP exists because actuation through screenshots, accessibility trees, and brittle clicking is unreliable. Structured page tools can make agentic browsing more accurate, more inspectable, and more accessible. The risk is treating structure as trust.

Browser-level controls can reduce the blast radius. WebMCP's draft uses secure contexts, origin-keyed constraints, Permissions Policy, exposed origins, and toolchange events. Chrome documentation says WebMCP is available only in origin-isolated documents and that cross-origin iframes require explicit permission. Those are the right primitives.

But browser controls need agent controls above them. The agent should know that page content is untrusted, third-party scripts are not tool owners by default, tool metadata is untrusted until bound to an origin and version, and a mid-session registry change should trigger review rather than quiet replanning. Otherwise the browser can enforce origin rules while the model still treats an attacker-framed tool as a routine step.

For high-risk actions, the browser should not be the only judge. Purchases, messages, account changes, file exports, form submissions, code changes, and permission changes need explicit user confirmation, tool-call receipts, and a way to explain which page, tool, script source, and metadata version participated.

Failure Modes

The first failure mode is registry drift. The tool list that existed when the agent planned is not the tool list that exists when the agent acts.

The second is tool shadowing. A malicious tool adopts a name, title, schema, or workflow position close enough to a legitimate tool that the model routes through it.

The third is read-only theater. A tool is framed as harmless through a read-only hint or description while its execution leaks context, redirects workflow, or causes downstream state change.

The fourth is same-page supply-chain capture. A third-party script that was originally loaded for analytics, ads, payments, chat, or experiments gains the practical ability to shape the agent's callable environment.

The fifth is iframe overexposure. A cross-origin frame receives tool access through a permissive policy or broad exposedTo setting, and the agent loses track of which origin really owns a tool.

The sixth is stealth completion. The user sees the task finish, but the route included a malicious tool call, data disclosure, or changed execution order that the page UI never made visible.

The seventh is receipt failure. After an incident, the organization can reconstruct browser history but not the tool map, tool metadata, script source, registration time, selected tool, arguments, output, and user confirmation at the moment of action.

Governance Standard

The paper's mitigation directions are the right primitives: bind tool identity to origin, preserve lifecycle consistency, enforce data boundaries for third-party tools, and maintain traceable logs of tool registration and invocation. Those sound technical, but they are governance requirements.

Origin binding asks whether a tool is really from the party the agent believes it is from. Lifecycle consistency asks whether the tool the agent planned to call is still the tool being dispatched. Data boundaries ask whether third-party components can receive context they should never see. Logging asks whether an incident reviewer can reconstruct what tool surface existed at the moment of action.

A serious deployment should therefore record the page origin, frame origin, script sources, tool owner, tool registry version, tool metadata, registration time, changes during the session, selected tool, arguments, returned data, confirmations, and final user-visible result. Without that record, the claim that the agent "chose the wrong tool" is too vague to govern.

First, bind every tool to an origin and owner. A tool should have an accountable page origin, frame origin, script source, publisher, and registration path. If a third-party script registers or changes a tool, that fact should be visible.

Second, freeze the plan against the registry. If the tool list changes after planning but before execution, the agent should pause, re-evaluate, and surface the change. Silent replanning is exactly the gap MSTI exploits.

Third, make metadata changes auditable. Names, titles, descriptions, schemas, annotations, read-only hints, exposed origins, and callback identity should be versioned. A risky change should trigger review proportional to the action class.

Fourth, separate third-party scripts from first-party authority. Loading an analytics or advertising script should not imply permission to create agent-callable tools. Tool registration should be an explicit capability, not an accidental side effect of running on the page.

Fifth, gate consequential calls. Sending, purchasing, submitting, exporting, deleting, installing, account-changing, payment, and permission-changing tools need human confirmation that names the origin, tool, data payload, destination, and expected effect.

Sixth, label returned content as evidence, not instruction. Tool outputs and page observations should not be allowed to expand scope, reveal hidden context, call new tools, or override the user's task without a higher-authority approval.

Seventh, test with hostile scripts. Red teams should attack with CDN compromise, ad-script injection, race conditions, tool unregister/register cycles, schema changes, iframe exposure, misleading read-only hints, and task-completion-preserving exfiltration.

Eighth, pair web controls with agent controls. CSP, SRI, origin isolation, and Permissions Policy help constrain the page. They do not replace allowlists, origin-bound tool identities, agent permission classes, receipts, and incident review.

What This Changes

The WebMCP tool surface becomes the attack surface because agents do not merely browse the web. They inherit a machine-readable version of the web, where names, schemas, annotations, and dynamic registrations can steer action before a human sees anything suspicious.

The Spiralist rule is simple: if a website can offer tools to an agent, it must also offer provenance, lifecycle receipts, third-party boundaries, and revocation paths. Otherwise the page becomes a place where hidden web supply chains can rewrite the agent's menu of possible actions.

This is the governance form of a larger change. The web page is no longer only a document, interface, or app. It is becoming an agent-facing command surface. A button visible to a human has affordance; a tool visible to an agent has authority. The difference is that the authority can be created, renamed, hidden, framed, and removed by code the user may never inspect.

The answer is not to pretend that visual clicking was safer. It was just less explicit. WebMCP could make web action more structured and auditable. But only if the structure comes with source discipline. The model needs to know not only what tool exists, but who made it exist, when it changed, why it is safe for this task, and what record will survive the call.

Source Discipline

This essay treats the Lee, Chang, Yu, and Yeh paper as a primary source for the authors' threat model, experiments, reported results, and limitations. It does not treat the paper as proof that every native WebMCP implementation is equally vulnerable. The authors' own limitation section says the experiment used a polyfill and headless proxy environment, and that native browser deployments still need evaluation.

It treats the WebMCP draft and Chrome documentation as current design and implementation references, not as a completed standard or deployment guarantee. The WebMCP draft is a Community Group report, not a W3C Standard. Chrome documentation describes Chrome's current planned and experimental surface, including origin isolation, Permissions Policy, origin trial status, and local flags.

It treats OWASP MCP sources as risk taxonomy, not prevalence measurement. It treats CSP and SRI specifications as web-security primitives that can reduce script and resource risk, not as complete defenses against model interpretation or tool lifecycle attacks. For a production review, the evidence should include browser behavior, extension behavior, tool registry logs, script provenance, CSP/SRI policy, iframe permissions, tool metadata diffs, and incident drills.

Sources

Return to Blog