[tehryanx]

I do think the threat model here is a bit unique though.

If I'm running two MCP servers on my machine, I'm the one that installed them, I'm the one that assigned what permissions they have in my environment, and I'm the one that explicitly decided what level of access to give them within whatever resource they're accessing. That gives me reasonably strong control over, or at least full knowledge of, what data can be shared between them.

With MCP, I can use oauth to make very deliberate decisions about the scope of access I want to give the agent.

With MCP-B, it's the web application owner that installed the interface and what access it has to my data, and the agent running in my client gets access to whatever that third party deemed appropriate.

With MCP-B the agent has the same access I do by default, with the only restrictions being up to the app owner rather than it being up to me.

MCP auth is not perfect by any stretch, but the key thing it gives the user is the capacity to restrict what the agent has access to with some granularity. That's super important because the agent can't be trusted when it's consuming inputs the user didn't explicitly define. MCP-B doesn't have this, if you have the agent in your browser it has access to whatever resources you have so long as they were exposed by a tool call, which isn't somethign the user has any say in.

[miguelspizza]

I see your point. The MCP-B zero config nature from a user perspective is simultaneous it's biggest strength and weakness. You can think of it kind of like putting your Social Security number into a website. You are putting a bunch of trust that they are going to protect it properly.

With MCP-B you are putting trust in both the model and the website owner. It opens up the user to risk for sure, but it's up to them to determine if the upside is worth it.

[tehryanx]

I appreciate your responses here. The thing that still really stands out to me as a completely novel risk in this framework is that the extension is automatically seeking out and attaching to these servers as soon as a page gets loaded.

This seems really bad to me. There are so many ways for a website to end up in one of my browser tabs without me wanting it there, or even knowing it's there.

If that happens, and that tab just so happens to be a malicious MCP-B enabled page, it could steal all kinds of data from all kinds of different web apps I'm interacting with. I think it should be seen as the responsibility of the framework to enforce some level of data isolation, or at the least opt-in consent mechanisms.

[miguelspizza]

Yea this is a really good idea, Maybe like a popup that say "hey x website has an MCP, do you trust it to connect?"

I guess there would also need to be a way to "audit" a websites full tool list at connection time and throw some sort of warning if tools show up that are not part of this list during use.

Interesting problems for sure. I really appreciate you taking to time to think them through. I'll call these out in the issues section of the repo

[miguelspizza]

Added a summary of what has been brought up here to the repo wiki. Let me know if I missed anything

https://github.com/MiguelsPizza/WebMCP/wiki/Known-Security-I...

[michaelmior]

> with the only restrictions being up to the app owner rather than it being up to me.

I don't see any reason sites using MCP-B couldn't have settings to restrict access to certain data based on user configuration.

[tehryanx]

Sure, but the leak risk is happening in a place outside the site's control.

If the purpose of the MCP-B tool on mail.com is to summarize your email, then the site needs to allow the agent to pull your email into the context window. Once it's in the context window it's available to any other MCP-B enabled site that can convince the agent to send it along.

[michaelmior]

Sure. My point was that you can limit what the agent is allowed to access at the very least. The fact that you need to trust the agent not to share the info is a n important, but separate concern.