{"slug": "webmcps-cross-origin-tools-need-three-opt-ins-cloudflares-backends-differ", "title": "WebMCP’s Cross-Origin Tools Need Three Opt-Ins. Cloudflare’s Backends Differ", "summary": "The WebMCP Community Group draft dated November 2, 2026 places WebMCP APIs behind a policy-controlled feature named `tools` with a default allowlist of `'self'`, and adds two further cross-origin controls — the `fromOrigins` parameter on `getTools()` and the provider-set `exposedTo` property — so that exposure is checked at both discovery and invocation. The draft, which is not a W3C Standard and is not on the W3C Standards Track, states that browser agents retrieve tools through a separate, implementation-defined mechanism, so `fromOrigins` is not a documented universal switch for agents. Cloudflare's Browser Run guide lists two backend paths, Chrome Lab and Kitesurf, and Cloudflare says Kitesurf does not implement the `tools` Permissions Policy or origin-based tool filtering and does not expose iframe or popup tools through CDP; Cloudflare's changelog records WebMCP support on April 15, 2026 through an experimental lab browser pool that it says should not be used for production workloads.", "body_md": "A draft can define a careful cross-origin gate without making every browser use that same gate. The [WebMCP Community Group draft](https://webmachinelearning.github.io/webmcp/), 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.\n\n## Three gates for in-page access\n\nThe 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.\n\nFor 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](https://developer.chrome.com/docs/ai/webmcp/) describes the iframe delegation, and its [security guidance](https://developer.chrome.com/docs/ai/webmcp/secure-tools) advises exposing tools only to trusted origins.\n\nThese 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.\n\n## Browser agents are a separate mechanism\n\nThe 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.\n\n## Cloudflare implementation paths\n\n[Cloudflare Browser Run’s guide](https://developers.cloudflare.com/browser-run/features/webmcp/) 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](https://developers.cloudflare.com/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.\n\n## Authorization boundary\n\nThe 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.", "url": "https://wpnews.pro/news/webmcps-cross-origin-tools-need-three-opt-ins-cloudflares-backends-differ", "canonical_source": "https://forkast.news/webmcps-cross-origin-tools-need-three-opt-ins-cloudflares-backends-differ/", "published_at": "2026-11-05 22:03:43+00:00", "updated_at": "2026-11-05 22:24:06.074835+00:00", "lang": "en", "topics": ["agent-protocols", "ai-agents", "ai-tools", "developer-tools"], "entities": ["WebMCP Community Group", "W3C", "Chrome", "Cloudflare", "Cloudflare Browser Run", "Kitesurf", "Chrome Lab"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/webmcps-cross-origin-tools-need-three-opt-ins-cloudflares-backends-differ", "markdown": "https://wpnews.pro/news/webmcps-cross-origin-tools-need-three-opt-ins-cloudflares-backends-differ.md", "text": "https://wpnews.pro/news/webmcps-cross-origin-tools-need-three-opt-ins-cloudflares-backends-differ.txt", "jsonld": "https://wpnews.pro/news/webmcps-cross-origin-tools-need-three-opt-ins-cloudflares-backends-differ.jsonld"}}