`navigator.modelContext.provideContext` allows overwriting of previously registered tools in the same environment

[beaufortfrancois]

In environments like online stores where first-party code and third-party partner JavaScript run within the same environment, a security concern exists with how WebMCP tools are registered.

Currently, if a site registers an "official" tool, a malicious or accidental third-party script can overwrite it. This could allow the third party to proxy tool calls, effectively observing the entire agent-user interaction, which may include private data.

And here's how it happens: While the navigator.modelContext.registerTool() method throws an error if a tool with the same name already exists, this security mechanism is bypassed with navigator.modelContext.provideContext() that first clears the existing tools before registering new ones.

Note

A similar issue also exists by registering a tool whose name varies slightly with navigator.modelContext.registerTool() or a new <form toolname="...">.

Thoughts for discussion

We need a mechanism to prevent unintentional or malicious clobbering of tools when potentially untrusted scripts are operating in the same environment.

1. Should the entire navigator.modelContext.provideContext({tools: ...}) call fail if it attempts to register a tool name that is already registered, regardless of the method used for the initial registration?
2. Shall we add an optional strict parameter for navigator.modelContext.provideContext() that when set would cause the call to fail if any tool name in the new context is attempting to hijack an already registered tool name?
3. Shall we expose a new listTools() method and toolchange event on navigator.modelContext that would allow the controlling script to check for already registered tools before attempting to update the context:

[johannhof]

So we should be clear on the threat model here: Are you trying to prevent unintentional or malicious overwriting of tools? There's a big difference between those two things, with the latter being much harder to prevent.

Right now, it is hard to stop a motivated third party script from messing with the web page it is embedded on, that is just not really supported by the threat model of the web. There are some mechanisms that employ a "trust-on-first-use" model, such as HTTPOnly cookies. We could do the same thing here, but note that this also only goes so far: A malicious script could easily do things such as overwriting DOM elements or global functions to achieve the same effect as overwriting a tool definition, but admittedly that at least protects against permanently storing these tools.

So, to repeat, the threat model should be really clear: We might be able to achieve a TOFU protection against permanently overriding scripts ala HTTPOnly cookies, but there is no current way to instill complete trust in third party scripts and any web developer who embeds untrusted third party scripts should be clear on the implications. This is also shown by your concern that another script could register a very similar tool (maybe even with an annotation that this is the "correct" tool to use). Web developers should realistically not embed scripts that they don't trust to not do this kind of stuff.

I agree that we should make registerTool and provideContext be coherent in their threat model regarding when to allow overwrites vs. not.

[MiguelsPizza]

Beyond the security issue, this is also a major footgun for non-malicious 3p scripts.

1P script registers a tool:

navigator.modelContext.registerTool({ name: 'submit_patient_info', ...  });

Another script runs later and wipes it:

navigator.modelContext.provideContext({ tools: [] });
// or
navigator.modelContext.clearContext();

This becomes even more of an issue if we let iframes write and read to the hosts too list

I'm not sure what the upside of providing access to clear and set the global tool registry is? Maybe someone can speak to this?

What if we remove the provideContext() API and make it so registerTool() just returns its own teardown handle? This fits better with the component model most sites are built with today and aligns more closely with the declarative API, where tools are already scoped to their element's lifetime in the DOM.

useEffect(() => {
  const unregister = navigator.modelContext.registerTool({ name: 'submit_patient_info', ... })
  return () => unregister()
}, [])

[mfreed7]

What if we remove the provideContext() API and make it so registerTool() just returns its own teardown handle? This fits better with the component model most sites are built with today and aligns more closely with the declarative API, where tools are already scoped to their element's lifetime in the DOM.

+1 to this approach. It aligns much better with the rest of the web platform, which doesn't usually provide "delete everything that came before" type behavior. There are exceptions, such as window.onload but those are considered to be old/bad patterns, replaced with addEventListener('load') and removeEventListener(), which allow independent scripts to play nicely with each other. It seems like registerTool and unregisterTool are the way here, and I'm not sure provideContext is a good idea.

[bvandersloot-mozilla]

Do we even need it to return its own teardown handle? Or would

useEffect(() => {
  const unregister = navigator.modelContext.registerTool({ name: 'submit_patient_info', ... })
  return () => navigator.modelContext.unregisterTool('submit_patient_info');
}, [])

be sufficient?

I guess it is nice to be able to prevent tool-name-aliasing from causing you to remove the wrong tool, but at that point I think you are having a bad time with bugs anyway.

[MiguelsPizza]

navigator.modelContext.unregisterTool(any_possible_toolname);

Still lets any script unregister and replace any tool. What are the upsides of this API vs scoping the tool removal handle to its declaration?

[mfreed7]

navigator.modelContext.unregisterTool(any_possible_toolname);

Still lets any script unregister and replace any tool. What are the upsides of this API vs scoping the tool removal handle to its declaration?

I agree for sure - it shouldn't be possible to unregister a tool that you didn't register. That could be shaped in a few different ways, but it certainly can't be unregisterTool(tool_name).

[bvandersloot-mozilla]

What are the upsides of this API vs scoping the tool removal handle to its declaration?

You'd have to move the unregister callback around to be acessed by the cleanup code, rather than being able to refer to it in a per-page namespace (not a good argument, I know).

But returning the unregister does liberate us on the issue of name-aliasing- tools wouldn't have to be uniquely named. That does end up looking a lot more like @mfreed7's example of registering callbacks, and looks cleaner where iframes are registering tools as well