Comment by bustodisgusto
2 days ago
Not sure I understand. The model has no more access than the user does. proper security implementation still lies with the website owner
2 days ago
Not sure I understand. The model has no more access than the user does. proper security implementation still lies with the website owner
I think the point is that you shouldn't be giving the agent the same privileges as the user. This is one of the biggest issues with how people are using agents rn imo. The agent should be treated as an untrusted user in your client, given restricted privileges scoped to only the exact access they need to perform a given task.
Again, that's up to the website owner. They can give the model anywhere from no access to full access to the client side api.
> The agent should be treated as an untrusted user in your client, given restricted privileges scoped to only the exact access they need to perform a given task
I agree, this is exactly what MCP-B does
The data you give it can be shared with any other website, at the agent's discretion. Some of it might be safe to share with the user, but not with third parties; at a minimum this should request permission when trying to share data between different websites/servers.
3 replies →
I'm not following.
Say I have your browser extension running, and it's interfacing with an MCP-B enabled banking application using my session to access my data in that app.
I also have it connected to MCP-B enabled rogue web app that I mistakenly trust.
My browser has an entire architecture built around preventing data from crossing between those two origins, but what's stopping a malicious instruction from the rogue app asking the extension agent to include some data that it pulled into the context window from the banking app?
Further, when I use MCP in my IDE I have to deliberately provide that MCP server with a token or credentials to access a protected resource. With MCP-B, isn't it just automatically provided with whatever credentials are already stored in cookies/etc for a given MCP-B enabled app? If I load an MCP-B enabled app, does the agent automatically have access or do I have to configure it somewhere?
> If a website wants to expose a "delete all user data" tool, that's on them. It's no different than putting a big red delete button on the page.
It is different though, because the directive to push that button can come from somewhere other than the user, unless you've somehow solved prompt injection.
The point I'm driving toward is that I think you're violating the most common assumption of the web's long-standing security model, that data is protected from leaking cross origin by the browser. There's no SOP or CORS for your agent extension, and that's something that web apps have been built to expect. You're basically building an SOP bypass extension.
8 replies →
> The agent should be treated as an untrusted user in your client,
An untrusted user in a client is a hacker/invasor, not an agent.
That’s not really a reason not to treat the agent like it’s “rogue”. The point is, if it accepts any untrusted inputs then, from a security perspective, it is possible for any given (untrusted) input to contain a prompt injection payload that jailbreaks the model and tells it to do things it shouldn’t do.
As such, it can be told to do bad stuff in a way that can’t be prevented and therefore should not be given read access to anything you don’t want others to know about, nor write access to any data of which you care about the integrity.
2 replies →
an untrusted, but permitted, user is why sandboxes exist. There are plenty of times you want to allow an untrusted user to have capabilities in a system, that's why you restrict those capabilities.
2 replies →
When you say "the user", do you mean that if Alice set up the MCP, and Bob, Charlie, and Dave all access it, the MCP will only execute commands as Bob, or Charlie, or Dave, depending on who is accessing it?