Show HN: Prism – Let browser agents access any app(prismai.sh)
prismai.sh
Show HN: Prism – Let browser agents access any app
https://prismai.sh
16 comments
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?
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).
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!
I see what you're saying here, this is a "Plaid, for everything else on the web" move. Interesting!
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?
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.
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.
How does this handle bot detection?
We enable stealth mode on Kernel (onkernel.com), which is a great piece of infrastructure.
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.
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.
I think this could be useful for us, let me DM
[deleted]
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.
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.
We spoke to browser agent developers and saw people copying and pasting credentials and even credit card numbers directly into model system prompts. We were surprised that there wasn’t a better way to give agents access to websites on a human’s behalf. Moreover, we noticed that every company had to build infrastructure to manage OTP, TOTP, and MFA and that auth remained a significant hurdle in agent reliability. We wondered if this was a boring part of the problem of building web automations that someone could automate away.
We started working with Casco, an autonomous security testing company, to enable their agent to access customer sites. Before a pentest, Casco makes a request to Prism’s API specifying test user credentials, a domain, and a login method. For example, give me an authenticated session for the account [email protected] for OpenAI via OTP code over email. Our agent logs in on their behalf (without exposing credentials to a model), and we download the cookies and send them back in the response.
To maintain speed and reliability, we use playwright in most cases to login (which gives us speed), and we fallback to AI on failure (which gives us reliability). We have a number of websites we support out of the box and add new scripts as the number of websites we need to support grows. We are working on a way for the agent to update the existing playwright script on failure, so our scripts always stay up to date.
To try our api, you can use our API playground docs.prismai.sh/api-reference/endpoint/login to sign into x.com with the following API key: pk_54abb1cd0a637eb973ed690416e71a953e98f2ea839cf16529bbfa41a41bc016 .
We’d love to learn more about how other developers give agents access to their accounts. We look forward to everyone’s feedback and comments.