Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MCP-B: A Protocol for AI Browser Automation

mcp-b.ai

Post reply on HN
Print view View original

151–160 of 200 posts

Re: MCP-B: A Protocol for AI Browser Automation

#151

Post by ricardobeat »

miguelspizza wrote: post #148
tehryanx wrote: post #140

Earlier quoted context omitted.

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.

Re: MCP-B: A Protocol for AI Browser Automation

#152

Post by [deleted] »

sneak wrote: post #136
mattlondon wrote: post #133

Earlier quoted context omitted.

Anything that makes it easier to automate will make bad actors more efficient. So people like ticket sales sites, eBay etc. It will make it easier for those sites to have all the tickets purchased or for auctions to be sniped etc. FWIU, these sort of sites actually (currently at least) put on measures to try and stop bots using them for these reasons.

Scalping tickets and sniping auctions are legitimate use cases by customers. “Use it, but not like that” is not a legitimate position to take.

[deleted]

Re: MCP-B: A Protocol for AI Browser Automation

#153

Post by TeMPOraL »

lcnPylGDnU4H9OF wrote: post #146
owebmaster wrote: post #142

Earlier quoted context omitted.

> 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 a…

That is out of scope of the service. What kind of user agent the actual user deputizes to interact with a service, is the user's own choice and responsibility. In general, it's not something a service can solve on their end.

Re: MCP-B: A Protocol for AI Browser Automation

#154

Post by TeMPOraL »

sneak wrote: post #136
mattlondon wrote: post #133

Earlier quoted context omitted.

Anything that makes it easier to automate will make bad actors more efficient. So people like ticket sales sites, eBay etc. It will make it easier for those sites to have all the tickets purchased or for auctions to be sniped etc. FWIU, these sort of sites actually (currently at least) put on measures to try and stop bots using them for these reasons.

Scalping tickets and sniping auctions are legitimate use cases by customers. “Use it, but not like that” is not a legitimate position to take.

Indeed. Bur ironically, this is exactly the position most people propose to take with MCPs.

From the POV of the service, prompt injections are immaterial - the LLM is acting on behalf of the user, so as long as it's limited to the same actions/privileges the actual user has, it's really not the job of the service to police what the LLM does. It's the user's choice to delegate to an LLM instead of doing something themselves.

Re: MCP-B: A Protocol for AI Browser Automation

#155

Post by arnarbi »

TeMPOraL wrote: post #153
lcnPylGDnU4H9OF wrote: post #146

Earlier quoted context omitted.

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 a…

That is out of scope of the service. What kind of user agent the actual user deputizes to interact with a service, is the user's own choice and responsibility. In general, it's not something a service can solve on their end.

Services can certainly make this safer by providing means to get more restricted credentials, so that users can deputize semi-trusted delegates, such as agents vulnerable to injection.

The important point being made in this discussion is that this is already a common thing with OAuth, but mostly unheard of with web sessions and cookies.

Re: MCP-B: A Protocol for AI Browser Automation

#156

Post by Abishek_Muthian »

krashidov wrote: post #106
Abishek_Muthian wrote: post #85

I’ve haven’t used any MCP so far but as a disabled person I see use cases in accessibility for MCPs doing browser/smartphone automation. But any accessibility tool will be exploited by nefarious actors so I wonder how many main stream websites/apps would implement these MCP. Has anyone tried any MCP for improving accessibility?

> But any accessibility tool will be exploited by nefarious actors so I wonder how many main stream websites/apps would implement these MCP. How so?

Android smartphone bot farms use the accessibility service to automate usage of apps.

Audio captchas are often used by bots.

Re: MCP-B: A Protocol for AI Browser Automation

#157

Post by arkh »

mehdibl wrote: post #61

From the blog post: "The Auth problem At this point, the auth issues with MCP are well known. OAuth2.1 is great, but we are basically trying to re-invent auth for agents that act on behalf of the user. This is a good long term goal, but we are quickly realizing that LLM sessions with no distinguishable credentials of their own are difficult to authorize and will require a complete re-imagining of our authorization sy…

Wait, isn't it already part of Oauth?

> https://datatracker.ietf.org/doc/html/rfc8693#name-delegatio...

Re: MCP-B: A Protocol for AI Browser Automation

#158

Post by Aurornis »

57473m3n7Fur7h3 wrote: post #117
latexr wrote: post #114

Earlier quoted context omitted.

> Prediction: this will go the same way as RSS. Meaning what? RSS remains ubiquitous. It’s rare to find a website which doesn’t support it, even if the owners don’t realise it or link to it on their page. RSS remains as useful as it ever was. Even if some websites only share partial post content via RSS, it’s still useful to know when they are available (and can be used as an automation hook to get the full thing). R…

The built-in RSS reader in Firefox was removed. (But extensions exist to add RSS reader to Firefox.) Google killed Google Reader. (Other products exist you can use instead.) Facebook removed support for RSS feeds. (You can replace it with third party tools or API calls.) It’s not dead dead, but it did seem to lose some momentum and support over time on several fronts.

These products were phased out because most people weren't using them.

RSS is and always was very niche. There are always claims that companies killed RSS for nefarious reasons, but I think the truth is much simpler: Companies stopped putting resources into RSS tools because very few people use them.

The people who use RSS are very vocal about their support, but they're a small minority of internet users. Even I started with an RSS reader but found myself preferring a set of bookmarked favorites to the sites I wanted to read, even though they're not equivalent in functionality. For my use case, a random sampling of websites that I could visit during times I had 15 free minutes to read something was better than collecting everything into one big feed, even though I would have guessed the opposite before trying both ways.

Re: MCP-B: A Protocol for AI Browser Automation

#159

Post by tehryanx »

miguelspizza wrote: post #148
tehryanx wrote: post #140

Earlier quoted context omitted.

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

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.

Re: MCP-B: A Protocol for AI Browser Automation

#160

Post by xienze »

TeMPOraL wrote: post #120
jacquesm wrote: post #113

Prediction: this will go the same way as RSS. Companies don't like you to be in control of how you use their data.

Indeed. Though I guess a better example would be: it'll go the same way as REST APIs (which happen to be fundamentally the same thing as MCP anyway). Remember the time when REST was the new hot thing, everyone started doing API-first design, and people thought it'll empower people by letting programs navigate services for them programmatically? Remember when "mashups" were the future? It all died before it could come…

> and people thought it'll empower people by letting programs navigate services for them programmatically?

I don’t think that concept died because of nefarious business-related reasons but rather that building true HATEOAS APIs is hard and the utility of “automatically navigable APIs” is quite limited. It’s a neat trick to point a generic API client at an API and crawl it automatically, but hardly anyone consumes APIs that way. We read the API docs and construct integrations suited to the task at hand, manually.

Post reply on HN