Should we support cross-origin Agents across frame boundaries

[khushalsagar]

Currently the explainer says that tools can only exist on the top-level browsing context here. Maybe that makes things easier to reason about from a security perspective but also seems unnecessarily limiting. There's a couple of interesting use-cases to think about:

• A page which embeds an Agent, came up on Clarifying the scope of the proposal #43 (comment). If the site doesn't want the Agent to run script in the first party context, they could embed it in a cross-origin iframe instead.
• An Agent which embeds a cross-origin and wants to access it's WebMCP functionality.

We'd likely need a security policy to allowlist which origin can see a site's WebMCP functionality. I'm not sure how granular it needs to be, this origin can see all tools or a subset of tools etc.

For now, let's resolve on adding this use-case to our scope.

[khushalsagar]

This is distinct from #51 which is about Agents running within the same frame as the site.

[43081j]

can we not just use existing security models?

if a parent can access the window of a child frame, it can list and call tools. just the same way it can call any other web API

[khushalsagar]

Notes from TPAC discussion here. The main conclusion was that this should likely be scoped out of v1 for this API. The discussion ended up focusing on iframes declaring tools at all, filed #57 to follow up on that.

if a parent can access the window of a child frame, it can list and call tools. just the same way it can call any other web API

There's a very limited set of properties that a cross-origin frame can access from other frame's window object as a security restriction. These tools can't be a part of that list by default, we'll need some policies to gate access to origins allowed by each site.