A draft can define a careful cross-origin gate without making every browser use that same gate. The WebMCP Community Group draft, dated November 2, 2026, proposes a way for web pages to expose structured tools. It is not a W3C Standard and is not on the W3C Standards Track. For builders, the key distinction is between the draft’s in-page JavaScript access model and the separate way a browser agent may inspect tools.
Three gates for in-page access #
The draft puts WebMCP APIs behind a policy-controlled feature named tools, with a default allowlist of 'self'. This first gate acts as a high-level permission switch: if a page embeds a cross-origin iframe that needs the API, the embedding document must explicitly delegate the feature using allow="tools". This delegation answers a binary question: may the framed document use the feature at all? It does not by itself authorize a particular tool caller or make every tool visible.
For in-page JavaScript callers using getTools(), two additional controls shape cross-origin discovery. The second gate is the fromOrigins parameter. When a caller requests tools, it can include a target origin here; without this request, getTools() defaults to including only same-origin documents. The third gate is the exposedTo property, which the tool provider sets to specify which caller origins may access the tool. Chrome’s WebMCP guide describes the iframe delegation, and its security guidance advises exposing tools only to trusted origins.
These three controls belong to different parties: the embedder delegates the API, the consumer requests tools from a particular origin, and the provider agrees to expose a tool to specified callers. The draft checks exposure during both discovery and invocation. A tool appearing in a list is therefore not a universal permission slip: the call is checked too. This is a model for cross-origin documents using the in-page API, not a summary of every browser’s internal tool access.
Browser agents are a separate mechanism #
The draft specifies that browser agents use a different internal mechanism to retrieve tools. Its description of browser-agent observations is implementation-defined, and it does not prescribe the format in which tools reach the browser agent. That distinction limits what can be inferred from fromOrigins: it is a parameter of the in-page getTools() API, not a documented universal switch for browser agents. The draft neither promises uniform browser-agent behavior nor says that browser agents use the exact same sequence of checks. Builders should inspect the implementation they rely on rather than silently extending the in-page rules beyond their stated scope.
Cloudflare implementation paths #
Cloudflare Browser Run’s guide lists two backend paths: Chrome Lab and Kitesurf. Lab sessions use an experimental Chrome pool for testing experimental features, and Cloudflare says they should not be used for production workloads. Kitesurf has its own WebMCP implementation. Cloudflare explicitly says Kitesurf does not implement the tools Permissions Policy or origin-based tool filtering, and does not expose iframe or popup tools through CDP. The Browser Run changelog records WebMCP support on April 15, 2026 through an experimental lab browser pool. That record is a useful implementation timeline, not evidence that the two backends are equivalent or that every draft provision is present. The documented Kitesurf exception alone is enough to show why testing one path cannot establish behavior on the other. The available documentation does not establish a security outcome, nor does it show that Kitesurf’s limits amount to a vulnerability.
Authorization boundary #
The draft notes that a tool callback runs in the registering document’s context, with access to that origin’s DOM, storage, and ambient credentials. It also warns that tool descriptions and annotations can be misrepresented. Origin filtering narrows which documents may discover or invoke a tool; it does not decide whether a particular action is allowed for the current account, session, or business rule. That remains a responsibility of the application’s implementation, including server-side checks where the action depends on them. The practical takeaway is a layered one. Use the proposed gates for their stated purpose, treat browser-agent behavior as implementation-specific, and enforce application authorization at the point where the action is carried out. The draft sketches who must opt in for a cross-origin in-page tool call; it does not turn origin matching into proof that an operation is safe or authorized.