Hey HN, We’re Alex, Land, and Rajit. We’re building Prism (prismai.sh), a tool that helps browser agents authenticate onto websites with user credentials. Developers pass in credentials, Prism logs into a website on their behalf, and hands them back the cookies so they have an authenticated session. Here’s an example of how developers can use Prism to complete username/password flows (https://youtu.be/SEtVUnWnxuE), and here’s an example of how developers can use Prism to complete login flows that require an OTP code (https://youtu.be/fe9w9PvrwH0).

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 rajit@prismai.sh 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.

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?

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.

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.

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?

Interesting problem you're tackling. Would love to connect to chat more.

I think this could be useful for us, let me DM

How does this handle bot detection?