Threat Model for WebMCP

1. Introduction

This threat model covers WebMCP specifications and uses selected implementation evidence where it clarifies the modeled flows. WebMCP is a browser-side API surface that allows a web document to expose page functionality as structured tools that can be discovered and invoked by browser-integrated or in-page agents (for example, PageAgent [PAGEAGENT]). Not every threat in the model originates in WebMCP. The model separates threats inherent to agentic navigation, threats introduced by MCP-style tool mediation, and threats specific to WebMCP.

Note: WebMCP is not a backend MCP deployment. Instead, it brings MCP-like tool interaction into the browser by reusing an existing web application’s functionality and state and exposing that functionality to agents through browser-side mechanisms.

1.1. Terminology

This threat model uses the terminology defined in the WebMCP Terminology section [WEBMCP] and its accompanying explainer [WEBMCP-EXPLAINER].

1.2. Related Work

• WebMCP [WEBMCP]

• WebMCP Explainer [WEBMCP-EXPLAINER]

• Declarative WebMCP API Explainer [WEBMCP-DECLARATIVE-EXPLAINER]

• WebMCP Self-Review Questionnaire: Security and Privacy [WEBMCP-SPQ]

• Managing action specific permissions [WEBMCP-ISSUE-44]

• Chrome WebMCP guide [CHROME-WEBMCP]

• WebMCP tool security [CHROME-WEBMCP-SECURITY]

• Agent security considerations for WebMCP [CHROME-AGENT-SECURITY]

• WebMCP Tool Surface Poisoning: Runtime Manipulation Attacks on LLM Agents [LEE-WEBMCP-POISONING]

• Breaking Origin Isolation without Breaking the Browser [FERNANDES-WEBMCP-SAMEORIGIN]

• Agentic Browsing and the Web’s Security Model [AGENTIC-BROWSING-TPAC-2025]

• Threat Modeling Community Group Meeting Minutes [TMCG-MINUTES-2026-07-14]

1.3. Methodology

This threat model follows the Threat Modeling Guide [THREAT-MODELING-GUIDE]. It begins by modeling the system under analysis and identifying its elements, data flows, and trust boundaries.

Threat elicitation uses STRIDE as a first pass across those elements and flows. PHANTOM-B complements this analysis for threats associated with the LLM-dependent parts of the system.

The model also draws on Threat Model for the Web [THREAT-MODEL-WEB] and its Web Security Model, particularly the concepts of origin, isolation, browser mediation, and untrusted web content.

2. What are we working on?

The L0 views start from the generic high-level Web API diagram in the Threat Model for the Web [THREAT-MODEL-WEB]. The methods-level views add the specification’s WebIDL, methods, and dictionaries.

2.1. Scenario

This threat model considers an agentic Web in which AI agents can navigate and interact with web pages and web applications on a user’s behalf. WebMCP describes two relevant deployment models: an AI agent integrated into the browser, and an author-provided in-page agent implemented in JavaScript, either embedded directly in a page or running in an iframe [WEBMCP] [WEBMCP-EXPLAINER]. Alibaba’s PageAgent [PAGEAGENT] illustrates the latter without being a WebMCP implementation or normative example. It is an in-page JavaScript agent that operates a web interface through the page’s DOM.

WebMCP provides an MCP-like interaction model for a web application. Rather than requiring an agent to infer an action from the rendered interface — for example, by inspecting the DOM or using screenshots to find a product-search control — a page can expose a structured search-products tool with a description and input schema. The agent can discover that tool and invoke it with structured arguments, while the page executes its existing application logic and returns a structured result.

A page can expose this functionality in two ways. The imperative API lets page code register tools directly in JavaScript. The declarative API allows the browser to derive tools from existing HTML forms and standard inputs.

Both mechanisms are intended to make existing web application functionality available to agents without requiring the agent to operate the user interface as a sequence of low-level interactions. The threat model separates three sources of threats:

• threats inherent to agentic web navigation, independently of WebMCP;

• threats that arise when an agent uses a web page through an MCP-like tool interface; and

• threats specific to the WebMCP surface, including tool registration, discovery, invocation, browser mediation, and the declarative and imperative exposure mechanisms.

The categories can overlap, but keeping them separate makes three questions explicit:

• Which threats may WebMCP reduce?

• Which threats remain outside WebMCP’s scope?

• Which new threats may WebMCP introduce?

2.2. L0: High-Level Deployment Views

WebMCP supports two deployment models that place the agent on different sides of the document/origin boundary. Because the placement of PO-03 and TB-03 changes the trust-boundary topology, each deployment is shown as a complete diagram.

2.2.1. Browser-integrated agent

2.2.2. Author-provided in-page agent

Pastel yellow is only a provenance fill: it identifies shapes inherited from the generic Web API L0 model. Unfilled white shapes are WebMCP additions.

The inherited elements are EE-01, EE-02, PO-01, PO-02, TB-01, and TB-02; WebMCP additions are PO-03, DS-01, DS-02, EE-03, and TB-03.

In L0-BI, TB-03 AI Agent Boundary is inside TB-01 and outside TB-02. In L0-IP it is a logical author/agent responsibility boundary inside the TB-02 boundary family. It may collapse into the same-origin page context or correspond to a separate iframe origin; the diagram does not imply a new browser-enforced isolation primitive.

The specification explicitly distinguishes JavaScript in-page agents using ModelContext APIs from the browser’s agent, which uses an implementation-defined observation and internal invocation mechanism [WEBMCP]. No normative WebMCP algorithm creates, mutates, or enters PO-03; it is a deployment actor whose exchanges with browser-controlled algorithms are represented in the DFD.

2.2.3. L0 Elements

2.2.4. L0 Trust Boundaries

2.2.5. L0 Data Flows

2.3. L1: Methods-Level Deployment Views

The L1 views use different invocation paths:

• The author-provided in-page agent uses getTools() to discover tools and executeTool() to invoke them. Its executeTool() path uses the specification’s traversable-scoped pending tool executions map and unloading cleanup.

• The browser-integrated agent receives observations and invokes tools through a browser-controlled adapter.

Registration and registered-tool state are shared.

2.3.1. Browser-integrated agent

2.3.2. Author-provided in-page agent

2.3.3. L1 Elements

2.3.4. L1 Trust Boundaries

2.3.5. L1 Data Flows

2.3.6. Mapping

3. What can go wrong?

The table records threats, their relationship to WebMCP, specification coverage, and proposed actions. Threat classes can overlap; inclusion does not establish an API defect or show that WebMCP introduces new threats. Threat class identifies the capability or surface involved.

Specification coverage records what is addressed, not whether a mitigation is effective. Missing discussion does not establish missing algorithmic checks. DFD coverage records what a diagram represents, independently of deployment applicability or implemented protection.

The row status distinguishes specification treatment from remaining response work. Tracked means recorded in this model with relevant discussion, partial controls, or implementation-specific follow-up; it does not imply a commitment by the specification editors. To be addressed identifies an outstanding response or responsibility question, including external dependencies, rather than proving that algorithmic checks are absent. No status asserts verified implementation protection.

T-03, T-25, T-26, and T-27 distinguish failures in mediation, confirmation, interface semantics, and agent decisions. They can occur in the same scenario and are not mutually exclusive.

4. What are we going to do about it?

The planned response table will map candidate responses.

This section is incomplete.

5. Did we do a good enough job?

The current draft contains:

• a high-level view of the WebMCP methods and surfaces in scope;

• a set of threats classified by the capability or surface involved;

• a mapping from each threat to the Security and Privacy Considerations section, showing which threats the specification already addresses and where further work may be needed.

The next pass should add the corresponding responses, determine where they belong in the specification, and compare threats, responses, and residual risk across the in-page and browser-integrated deployments. That comparison should record whether a deployment changes severity or needs a deployment-specific mitigation.

• Consider a separate mitigation-responsibility column in the threat inventory, distinguishing the specification, browser, page, agent, and provider from the threat’s origin. For T-05 and T-24, WebMCP may serve as the delivery or action path, while primary responsibility appears to sit with the agent implementer or vendor. Review this proposed allocation when developing responses.