(no title)
tehryanx | 7 months ago
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.
tehryanx | 7 months ago
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.
miguelspizza|7 months ago
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?