Password-First Auth Hinders AI Agents

Diving deeper into

Reed McGinley-Stempel, CEO of Stytch, on authentication for AI agents

Interview
we ran into problems with their architecture assuming you're starting from a password basis.
Analyzed 5 sources

This exposed a real product gap in identity infrastructure, the big vendors were built for adding new login methods on top of a password account, not for treating passwordless login as the starting point. That matters because if a team wants to test email links, SMS codes, passkeys, and social login side by side, the auth system has to let developers swap flows, control every screen, and track conversion without dragging users through a hosted password reset style journey.

  • At Plaid, the business problem was concrete. The company made about 50 cents to $1 per bank connection, and about 45% of users dropped when asked for a bank password they had forgotten. That made alternative login methods not a nice to have, but a direct revenue lever.
  • The incumbents Reed names, Auth0, Cognito, and Firebase, were strong at centralizing auth across web and mobile, but their original design center was still the classic account model, user record first, password credential first, then extras like social login or magic links layered on later.
  • That opening split the market. Stytch went deeper on modular APIs so teams could own the signup and login UI. Clerk leaned into ready made components for fast setup. WorkOS started from enterprise SSO and SCIM. Each path reflects a different answer to how much of the auth stack developers want to control.

The next phase pushes this even further. As apps add passkeys, fraud controls, and agent permissions, identity systems that assume a fixed password account become even more awkward. The winners are likely to be platforms that let teams start with any credential, shape the full user flow themselves, and later add enterprise and agent controls without rebuilding the stack.