Chromium has implemented document.modelContext.getTools(), which I'm planning to spec, but we should discuss an important security implication before doing so.

As planned (and as currently implemented), getTools() resolves to a list of all tools that a Document has access to, controlled only by those that choose to register tool for the caller of getTools(). If in a frame tree, if both Evil.com and Victim.com have the tools permission, then Evil.com can "inject" tools into Victim.com's getTools() list, without Victim.com ever knowing about Evil.com or opting-in to see tools from that origin.

The onus is on Victim.com to manually check the tool's origin to see if it trusts the vendor of the tool, just like postMessage(): the onus is on the recipient of the message, to vet the sender's origin. Some of the web platform security folks we've been talking to believe it's best to force the caller of getTools() to supply a list of origins that it would like to see tools from, effectively making the resolved list the intersection of:

• Tools that have been explicitly exposed to the getTools() caller's origin; and
• Tools from the set of origins that the caller passes to getTools()

We were planing to add * wildcard as a supported value to the exposedTo array, so that the provider of a tool can send it to everyone. We should figure out how the proposal of locking down getTools() intersects with that. There are a few options:

1. Same-origin default; opt-in wildcard
   • getTools() defaults to showing same-origin tools only
   • registerTool() defaults to exposing tools to same-origin, if exposedTo isn't included
   • Both support the * wildcard, so you can expose and receive tools from any origins, if you so dare to
2. No wildcard; only explicit origin sharing/calling
   • Same defaults as above, but neither support wildcard. All tool sharing/invoking has to be via explicit origin
3. Something in between
   • exposedTo doesn't support wildcard (this matches the spec today), but getTools() defaults to *, and the caller is responsible for vetting each tool's origin before running

(1) Is ultra usable, and supports the most use cases. (2) Is ultra secure, but requires explicit origin negotiation probably through postMessage(), and probably means JS agents/tool vendors will need to ship down static origin allowlists to approve/deny embedders and tools on the fly. This is tedious and might seriously hurt adoption, especially for third-party agents that are meant to be embedded on thousands of sites, and accept tools from thousands of origins. (3) This is a little—exposedTo is more secure that postMessage()'s targetOrigin since it doesn't allow *, but getTools() is just as secure as onmessageevent handlers, since the onus is on the tool retriever to vet the supplier of the tool. Probably this option is weird and no more secure than postMessage() today.

I personally would love to see us go with (1)—it's safe by default, but maximally useful/open when users of both sides of the tool ecosystem choose to be.

/cc @johannhof @camillelamy