Hmm... this smells a lot like "account takeover as a service". I think it works fine for the test user use case, where you basically have a machine identity, but I wouldn't want to use it on a real user's account or my own account because of the risk involved.

I'm biased as we are working on similar problems at Stytch, but I do think OAuth-style scoped consent flows are a better way of handling this: https://stytch.com/blog/connected-apps-consent/ . Otherwise, the blast radius is enormous. Any plans to support OAuth or some other scoped-down permissioning?

This is a great point. I'm assuming when you mention blast radius you're mentioning the risk of the account being banned for being a bot.

One risk with these new standards for agent auth - which we will of course support if our customers want it - is that the websites that need them the most are the least likely to adopt them.

The main use cases for browser agents are for paying utility bills on old government websites or finding receipts for an expense report on a website without an API. There is a no reason to use browser agents on a website like Linear for example. A developer is better off integrating via API or MCP.

Therein lies the main challenge; the websites where browser agents are most useful are the same websites that are least likely to adopt new technology (it was their not adopting new technologies that made them good candidates for this browser agents in the first place).

I think this new standard is awesome, but I fear that the websites that support it will be those websites that didn't need it in the first place (because they could just as easily add an API).