Comment by owebmaster
2 days ago
a sandboxed user is not an untrusted user of the client but an unstrusted user of the host, that is why the client is sandboxed.
2 days ago
a sandboxed user is not an untrusted user of the client but an unstrusted user of the host, that is why the client is sandboxed.
sandboxing is a general term for actor isolation, and its context agnostic.
For example, when you use the sandbox attribute on an iframe in a web application, it's not the user that's untrusted, it's some other user that's attempting to trigger actions in your client.
I've thought more about this and I think the only way to make completely sure that sensitive data does not get leaked is by making sure it never makes it into the models context in the first place.
The issue is even if the MCP-B extension makes it so the user has to give confirmation when the agent want's to call a tool on a new domain after interacting with another domain, there is no clear way to determine if a website is malicious or not.
A solution to this might be to give server owners the ability to write the restricted data to extension storage on tool response instead of returning it to the models context. Instead, a reference to this location in extension storage get's passed to the model. The model then has the ability to "paste" this value into other website via tool call without ever actually seeing the value itself.
That way, MCP-B can put lots of warnings and popups when this value is requested to be shared.
Any thoughts?