Hi - Rene from Casco here. Thought to share a bit about our journey of dealing with auth for browser agents before Prism. We have a diverse set of customers whose login experience differ dramatically. Sometimes it's directly accessible on request, other times, you have to click through into a "login menu", other times we'd be dealing with Google sign-in and OTP.
We initially tried manually uploading session cookies to our browser agent after we authenticate locally. But soon realized how unscalable that is. We needed a general purpose API that allows our agents to auth into any application reliably. We needed something like Prism because making an agent reliable for our vertical is hard enough and I don't want us to maintain infrastructure just for the purposes of managing test user credentials and session management. If you're using browser agents and they've "hit the auth wall", then you know what I'm talking about.
Thanks for building Prism for us and letting us be a pilot customer. The API is straightforward and a pleasure to use. Can't wait for user sign-up and GitHub auth support to come soon.
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).
For blast radius, it's also the risk of the bot doing something wrong because it's overprivileged for the task. But yes, getting banned is a problem too.
I see what you're saying here, this is a "Plaid, for everything else on the web" move. Interesting!
Does this solve Captcha? Or is this only for people who are trying to maintain browser sessions in very niche use cases. Pen Testing is cool but I feel like the main use case is by allowing agents to work across the web on any website.
Hi Rene from Casco here. I think the post just referenced us as a customer because we use it for pentesting. For us, Prism solves the "browser agents can reliably auth into any website" problem.
We setup an agent mailbox with Agentmail (https://agentmail.to/). Whoever owns the account (likely the developer) sets up a forwarding rule to this account.
When our agent signs in, we input the forwarded otp code to get access.
Hi - Rene from Casco here. Thought to share a bit about our journey of dealing with auth for browser agents before Prism. We have a diverse set of customers whose login experience differ dramatically. Sometimes it's directly accessible on request, other times, you have to click through into a "login menu", other times we'd be dealing with Google sign-in and OTP.
We initially tried manually uploading session cookies to our browser agent after we authenticate locally. But soon realized how unscalable that is. We needed a general purpose API that allows our agents to auth into any application reliably. We needed something like Prism because making an agent reliable for our vertical is hard enough and I don't want us to maintain infrastructure just for the purposes of managing test user credentials and session management. If you're using browser agents and they've "hit the auth wall", then you know what I'm talking about.
Thanks for building Prism for us and letting us be a pilot customer. The API is straightforward and a pleasure to use. Can't wait for user sign-up and GitHub auth support to come soon.
It's a pleasure to work with you. Excited to expand to more login cases and support login to more websites.
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).
For blast radius, it's also the risk of the bot doing something wrong because it's overprivileged for the task. But yes, getting banned is a problem too.
I see what you're saying here, this is a "Plaid, for everything else on the web" move. Interesting!
Does this solve Captcha? Or is this only for people who are trying to maintain browser sessions in very niche use cases. Pen Testing is cool but I feel like the main use case is by allowing agents to work across the web on any website.
This is a great question. We are broadly interested in the agent access problem (which in some cases may involve solving Captchas).
Right now, we're focused on building connectors for our customers, which has not yet involved Captcha solving.
Hi Rene from Casco here. I think the post just referenced us as a customer because we use it for pentesting. For us, Prism solves the "browser agents can reliably auth into any website" problem.
How did the OTP case work? Where was the OTP received and how did the browser know?
Or did it bypass it entirely with corporation from the website?
We setup an agent mailbox with Agentmail (https://agentmail.to/). Whoever owns the account (likely the developer) sets up a forwarding rule to this account.
When our agent signs in, we input the forwarded otp code to get access.
Interesting problem you're tackling. Would love to connect to chat more.
Feel free to reach out. I'm rajit [at] prismai [dot] sh.
I think this could be useful for us, let me DM
How does this handle bot detection?
We enable stealth mode on Kernel (onkernel.com), which is a great piece of infrastructure.