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

With Model Context Protocol (MCP) gaining adoption as a way to standardize the way that AI agents integrate & share data with 3rd-party systems and APIs, we reached out to Reed McGinley-Stempel, co-founder & CEO of Stytch ($90M Series B at $1B valuation, Coatue) to talk about how the proliferation of agents is changing the way that developers have to think about authentication.

Key points from our conversation via Sacra AI:

What is Stytch in short and what inspired you to build it from your time at Plaid?

Stytch is the developer-first identity platform that unifies authentication and fraud controls for both humans and AI agents. It plays a key role in keeping consumer and B2B enterprise apps secure, especially now that AI is creating new kinds of threats that older identity systems weren’t built for.

We handle all the complexity of customers logging in and using your product. Stytch doesn’t do workforce identity, where employees need access to internal systems. If you think about the customer side of things, it can be a consumer, a B2B enterprise logging into a dashboard, or increasingly, an agent acting on behalf of a human or delegated by an enterprise. We focus on customer identity, but we span the machine and agent elements related to that.

The origin story goes back about five and a half years when my co-founder and I worked on the auth and fraud prevention team at Plaid. Many people reading this have used Plaid to connect their bank account to Venmo, Coinbase, or Robinhood. Every time you do that, you're effectively negotiating a handshake with the bank to facilitate that connection through Plaid's UI.

We ran into an interesting issue in 2019 that sparked the ideas around Stytch. As Plaid was growing quickly, we realized the biggest throttle or bottleneck to our growth wasn't the number of apps or consumers we served—it was actually the conversion rate of people linking their bank account.

For us at Plaid, we made roughly 50 cents to a dollar, depending on the rate we were charging, every time somebody connected a bank account. We found that roughly 45% of users were dropping out of the funnel because they forgot their password to their bank account.

If you think about it, maybe you'll go reset your password if you're applying for a mortgage. But if you're just opening a budgeting app or crypto account or brokerage account, there are many times you're just going to say, "not worth it. I downloaded this app, but I'm not going through with it." That represented a nine-figure opportunity for us to solve.

We set out to solve this by recognizing returning users across the platform. If we've already authenticated you, how could we use that established connection? How could we also use alternative auth methods that might convert better?

This was when the WebAuthn standard was emerging alongside maturity of on-device biometrics. Now, instead of passwords you could authenticate with cryptographic keys stored on the person’s device and unlocked with biometrics—obviously, passkeys have been the way it's evolved more recently.

At the same time, email magic links (still fairly novel then), SMS verification, and other approaches were gaining traction, so we began experimenting with these methods side-by-side to see which converted best.

As we went down that path of trying to A/B test these different methods, we were shocked at how hard it was both to do internally and in-house. When we tried to use Auth0, AWS Cognito, and Google Firebase—the three big incumbents—we ran into problems with their architecture assuming you're starting from a password basis. Their architecture also presumed you don't want to own the UX or UI, but Plaid cared deeply about that.

We did POCs with the major incumbents and ended up staying in-house because we couldn't get what we wanted on several elements. We were not happy to stay in-house but we felt the market didn’t offer a better option, and that was the first seed for Stytch.

The other piece that pushed us fully down this road was realizing there was significant room for innovation in the customer identity and access management space. We saw a chance to tackle bots and fraudulent accounts way more effectively than security tools out there at the time, drawing on our unique background in fraud prevention at Plaid.

The way Plaid worked in its first five to seven years was actually reverse engineering mobile banking APIs. We didn't have official agreements with many banks—we were sending large bot traffic to the banks while doing clever things to disguise that traffic. These were good bots, all delegated and permissioned by end users, but they were bots nonetheless because banks didn't want customers sharing their financial data and loosening their hold on user accounts.

This gave us extensive experience on how to effectively evade anti-bot and anti-fraud controls. As we started defending our own surface area at Plaid—when users or bots came in from Robinhood or Coinbase—we used our offensive knowledge to create defensive anti-fraud controls for Plaid's UI module.

Looking at the POCs we'd done with Auth0 and others, you could only get fairly superficial anti-fraud tools out of the box—you'd have to buy another vendor for most use cases. We realized there was enough frustration in the auth space, plus an ability to unify this with our anti-fraud and anti-bot expertise into something that would both innovate where developer experience was lacking in identity and provide a much stronger identity concept built with an integrated anti-fraud layer.

Give us your history of identity platforms in the 2010s and 2020s. What did the founding of companies like Gigya (2006), Okta (2009) and Auth0 (2013) and the acquisition of Auth0 by Okta create in terms of the opportunity to found Stytch?

The competitive market historically divided into two camps: on one side, platform players oriented around the role of the person using the identity platform; on the other, it was niche players focused on solving narrow authentication problems.”

Auth0 exemplifies the former. They realized it was very painful for developers to build authentication into new web or mobile apps because you were either using something like Ping Identity—which wasn't developer friendly—or rolling your own. The majority were rolling their own at that point because the market was pretty immature. Auth0 went after improving the persona experience from a broad level for developers.

Gigya represents the latter approach, innovating on more narrow authentication technology. They focused on social logins as a service. While there was a developer experience component, they weren't trying to own the entire platform of identity management—they were solving a point-in-time problem they thought would be huge.

Auth0's approach proved more long-lived. If you're someone like Gigya, you start to realize that when somebody like Auth0 comes around, appeals to the broad persona, and offers everything through the platform—not just social login—you usually get consumed in sales cycles where people choose the thing that checks a few of their boxes plus everything else they might need, versus someone saying "I just need the singular, focused solution for social login."

Auth0 benefited tremendously from the explosion of mobile apps in those early years. You had a completely new interface people were building for: "I have a web app, and now I need a mobile app. I can use the same agnostic identity provider across both."

When we got started at Stytch, we had to believe there was some paradigm shift that made it reasonable to spend a decade+ of our lives on this problem versus accepting that even though people don't love Auth0, it's good enough—you don't get fired for buying IBM.

Our big thesis centered on passwordless authentication and anti-fraud. Bot and fraud traffic was increasing, and in surveys, companies were saying they'd go passwordless in the next three to five years.

For passwordless, many customers in our first two years came explicitly for the passwordless improvements—better conversion, better security. They liked parts of the developer experience where we made it more modular so they could own more of the UX and UI.

But two years into our enterprise sales, we learned something crucial. You'd get a head of product and other executives excited about the passwordless vision. Then you'd bring in engineering stakeholders or a head of support who'd say, "This seems like a headache to deprecate every password we have."

The first time we tried selling into a big bank, they said, "Most of our users aren’t very tech savvy, and now I have to explain what passwordless is." I remember trying to explain to my parents what it meant when I said I started a passwordless company. They asked, "How can that be secure with no passwords?" I said, "Think about password reset—it's just email verification and the password gets churned." They said, "I don't understand it, but that's fine."

Even though passwordless is way easier for a large demographic, it's not universally easier. We got enough feedback and pipeline tied to "I need a bridge to get there" that we actually launched passwords about two years into the journey, despite all our early passwordless marketing and hoping we'd never have to build it.

Looking back at our metrics now, something like 50% of our customers use both passwords and passwordless—hybrid is actually a very common pattern. But if you look at their user bases, 90% of end users select the passwordless option.

Passwords are dying, but they're not dead. They still serve a purpose with certain demographics, and it will be a pretty long decay on the long tail. But the vast majority of users choose the passwordless option because they're more familiar with Sign in with Google, SMS, or email magic links. You have to have both.

That shift in the market—passwordless as a big boon—was true, but it wasn't everything. It wasn't the silver bullet. That led us to double down on anti-fraud tools. The fact that we're unifying passwords and passwordless makes us a broad-based platform the same way Auth0 started as a broad-based, password-based platform that’s evolved with the times.

And while this shift to passwordless and fraud prevention was the catalyst for launching Stytch and a huge influx of VC funding across the industry at the time, it’s going to pale in comparison to agent identity.

What's been interesting over the last year is that every company now has to think not just about logging in Reed, but logging in Reed and Reed's agent and determining what Reed's agent can do. That's the next big wave we anticipate and are already seeing play out with MCP servers as a pretty discernible example.

How do you map out the market including Stytch, WorkOS, Clerk, Auth0 and others and how do you position Stytch?

On the enterprise contract pipeline side, Auth0 appears 70 to 80% of the time, with the remaining 20% being startup competitors like Clerk, WorkOS, or occasionally Descope. Maybe they're looking at an open source solution like Keycloak. Auth0 remains the big gorilla on the enterprise side—they're the "you don't get fired for IBM" option. They're always at least a stalking horse in deals where somebody gets a price quote from them.

For startups deciding what to use for auth, it's quite different. The competitive landscape is more equally distributed between Auth0, WorkOS, Clerk, and maybe Supabase if you're already using Supabase for your database—though it would be unlikely to use them just for auth.

Each vendor has a distinct origin story and evolution:

Clerk started as auth for Jamstack, particularly focused on Next.js. They've done well in the Next.js community and went deep on UI components, trying to abstract as much as possible for developers. This makes it really easy for getting started on certain projects, but doesn't scale well in many cases. We see them very rarely in enterprise deals—I can count on one hand the number of times we've encountered them in enterprise. We do see them quite a bit in startup self-serve competitive situations.

WorkOS started very enterprise-heavy. They began as a company doing standalone single sign-on and SCIM add-ons. If you already have an auth system or use Auth0 and get a customer request for enterprise single sign-on—"We just signed Stripe, and they want to log in with Okta or Azure Active Directory"—WorkOS had an API to add that to your application.

This approach had benefits and drawbacks. The benefit: it's an easy thing to tack on without convincing someone to migrate. The drawback: over the last year or two, WorkOS has tried moving into the full customer identity management market. I don't think there's a venture-backable outcome in just SSO and SCIM, and they realized that.

We see both depending on where customers are coming from. If somebody's from the Next.js community, they're more likely to encounter Clerk. If they already have a system and just want to add SSO, they're more likely to encounter WorkOS.

We think of ourselves as broadly aligned with the Auth0 competitive angle—we're a broader full-stack identity and risk layer. If you need a beautiful drop-in UI, we can provide that. If you need enterprise SSO and SCIM, we can provide that. If you need device and agent controls, we can provide that. But we don't over-index on any single element.

This has pros and cons. The pro: it helps with enterprise sales. The con: if I'm a small startup needing just one thing, I can see why you'd go to Clerk for Jamstack or WorkOS for just SSO. We can serve all those use cases with just as complete of a product, but other vendors have gone harder into marketing and customer onboarding for specific use cases.

MCP has been hyped on the thought leadership side, but what have you seen on the adoption side? What is your stance towards MCP—all-in, wait and see, something else? What's Stytch's role as an enabling technology for MCP (model context protocol)?

I'm still figuring out the right mutually exclusive, completely exhaustive bucketing of use cases, but I can share what I'm seeing. One way to think about it is read versus write heavy MCP servers in terms of the tools people are exposing.

The first wave of MCP adoption involved people exposing tools primarily for read actions. Companies have specialized content they charge customers for and want to provide access via Claude, ChatGPT, or Cursor, but need authentication over the remote MCP server connection to serve that content.

One of our first MCP customers was a biotech company that released BioMCP. They charge for content similar to academic or scientific articles behind paywalls. They wanted to ensure users were on a paid tier that could access this data from MCP clients (e.g. AI chat interfaces).

This makes sense because Claude has been much better about integrating MCP tooling as something you can connect to. ChatGPT's first version was focused on deep research, fetch, and reading—not as good at taking other actions. If I want to use the Linear MCP, I'm doing it via Claude today, not ChatGPT yet, though they've just released some interesting capabilities.

The read functionality—bespoke custom data exposed to paid tiers—was the first wave. Sacra's approach seems similar.

Then I started seeing more write actions. People want to expose tools for actually doing things—Linear's MCP is great for creating feature requests and adding comments through Claude. People had to get comfortable accessing information before they became comfortable updating state on their accounts.

The big thing I'm seeing now—and it's moving fast in terms of what companies are saying, but slower in rollout than I'd like—involves Fortune 500 companies we're talking with. For the first time in a while, there's an authentic push around authentication coming from executive-level directives. Usually it's "we have to stop fraud," and an engineer finds device fingerprinting or 2FA. This isn't board-level driven.

But there are interesting large companies in POC right now who've been historically reliant on SEO for people to access their site, information, and learn their product. They're seeing what happened to Stack Overflow over the last couple years—usage going off a cliff as people shifted from visiting the direct site to using ChatGPT or Claude.

At some of these companies, the CEO actually cares—which is unusual as they typically haven’t had to think much about their identity team historically. They now care how quickly they launch an MCP server to avoid getting left behind versus competitors becoming accessible within Claude or ChatGPT.

This has turned a corner over the last few months—it's executive level, high executive level at large companies.

What's maybe not surprising is they're still very slow at rolling it out. The term I've heard from a couple places is: "We want to bet the farm on this"—because they see it as scary if they don't—"but not give the farm away." I see them in tension where they get very close to rolling out fully to production, then worry whether they're going too far, diminishing too much around their UI.

This is more stakeholder management than technical challenges. The tech is there, they have the POC. The question is: are you ready to share this with millions of users, or are you scared about what Wall Street will say depending on how well you protect your margin?

What does the future look like where both humans and agents are using SaaS apps and eventually where the usage is happening primarily via agents? What opportunity does that create for Stytch and how is Stytch positioning towards that?

Two things are really interesting here. First, only a small share of applications had to run as full-blown OAuth 2.0 identity providers until now—most apps simply needed to authenticate their own users, not delegate identities to other services to log in with on behalf of those users..

Taking a step back, what is an OAuth 2.0 compliant identity server and why should you care about this? Your Google account is one. When I use Calendly to manage my Google calendar, I delegate access to Calendly—effectively an agent, though not an AI agent, but a machine. I delegate to another agent to access my account, reading and writing to my Google Calendar data.

When I use Superhuman as my email client, I delegate all my read and write access that my Gmail service provides to Superhuman (and I go through a whole consent flow to enable this). If you’ve gone through one of those consent flows to delegate access of your Gmail account to another service, you’ve benefited from Google being an OAuth 2.0 compliant identity server and the interoperability that that enables on the web.

We've gotten used to authorizing our Gmail and calendar data, apps like QuickBooks, and different BI tools. We're accustomed to certain applications where I can authorize other agents or services to access data and take action on my behalf as a distinct scoped entity.

What changes with AI agents is that many applications that never had to worry about this—because they thought all interaction would happen in their actual dashboard or app—now have to figure out how to build the same infrastructure that powers Google's identity brokering capabilities for Gmail and calendar. They need to make it really secure and fine-grained for giving certain scopes and access, with the ability to revoke when needed and audit everything. How do they do that quickly to avoid becoming an old-school application where you have to use their actual app or website instead of other clients?

Many apps have never had to think about becoming OAuth 2 compliant identity servers. But if you’re building a remote MCP server, you’re likely going to want OAuth to power the user authentication flow because 95% of consumers won’t want to figure out how to use API keys. With our Connected Apps product, we make it easy for customers to become their own secure identity provider by installing a component from Stytch. This gives them full identity delegation abilities, user consent UIs, and auditability.

People are realizing when they start to spec this out in-house, it's both uninteresting work for their engineering teams—who are working on more interesting AI tools and product tools—and really hard because it requires a lot of OAuth experience and technical know-how around implementing this specific type of OAuth correctly.

And for MCP in particular, the spec is changing constantly. The MCP spec changes every few months, going from dynamic client registration to Client ID Metadata Documents. All these things are changing underneath you. We abstract all these changes for customers, so they don’t have to worry about the spec.

We see a really interesting opportunity because tons of applications need to do this. The in-house market is way more interesting than it's ever been for authentication. We can help people migrate to us, or at least migrate to this part of our stack, because we allow people to become an identity provider in an hour without migrating any other parts of their auth to us. Then you can expose yourself to different AI agents.

That's the first major opportunity as agents start using SaaS—all the work and infrastructure for converting a SaaS product into an identity server.

The second component relates to how we sell to teams building consumer and B2B apps. B2B typically has fewer users but higher charges because they have more valuable customers and we do more for them.

For a consumer app, we help users log in and stay logged in. For a B2B app, we help users log in and stay logged in, but we also manage all the authorization: Is Jan an admin, support role, or developer? What parts of the application should he access? How do you phone home and do that with low latency? We manage all that role-based access control and permissioning.

The same way apps once had to evolve into identity servers, nearly every consumer app now has to support more granular role-based access control, because Reed and Reed’s agent shouldn’t have the exact same roles and scopes.

Instead, they're saying: "This agent can take all these read actions, some of these write actions, and certain write actions it either can't take or requires human-in-the-loop confirmation where we send a push notification or email magic link to Reed to confirm he wanted to do that."

Agents really expand the scope of identity. Apps now have to manage not just who a user is, but also what their delegated actors are allowed to do. This is really exciting for us because everything becomes more complex in terms of the types of identities you're managing and what they can do within applications. Consumer apps didn't have to care about roles and permissions 99.9% of the time prior to agents.

In the near term, agents can be antagonistic. Stytch has some features that enable developers to ban scraping and other agentic behavior. What is Stytch's philosophy and approach here? What do you make of Web Bot Auth and Signed Agents from Cloudflare and Browserbase?

We have two different products for agent detection, identification, and management that fit different use cases.

Our Agent SDK (isagent.dev) is a lightweight solution for good agents. It's a really low-latency way for agents to self-identify: "Hey, I'm an agent. I am the Browserbase agent, or I am OpenAI's agent." In these cases, you can render markdown, adjust the end user flow, and make it slimmer to save costs if you're high volume. This tool is designed for good agents we trust to self-identify.

Then there are bad agents that won't self-identify or specifically try to evade detection. We have device fingerprinting for this, where you have to do a server-side lookup because you can't trust just the front end—it's manipulatable. The server-side call lets us adjudicate on the user and spot agents that are lying.

That's where our Plaid learning around reverse engineering APIs helps us detect evasion. We do proprietary things under the hood based on how we would have blocked and detected ourselves at scale when doing headless browser automation and running device farms.

Regarding newer standards like Web Bot Auth: we actually launched IsAgent and that SDK prior to Web Bot Auth coming to light and Cloudflare putting their weight behind it. It's been controversial, but we actually like it.

People over-index on Cloudflare being the first mover, saying "Cloudflare is trying to control the Internet." Maybe they are in some ways, but it's an open standard—Akamai could adopt it tomorrow, Google could adopt it. We're adopting it and launching integration both into our device fingerprinting tool and IsAgent SDK.

What we like about it: for our first version of IsAgent, we had to fingerprint all the major known agents like Browserbase agents, OpenAI's agent, Anthropic's agent. That approach couldn’t provide self-validation and occasionally produced false positives that took a little time to resolve. Now, if you're registered as an agent through your cryptographic signature and the Web Bot Auth process, it will be self-updated and managed, meaning isAgent can provide even more reliable identification.

Generally, our view is you need tools for both detecting good agents and giving them better experiences, but also expect that if you have valuable resources on your site that others could extract value from, there will likely be evasion techniques attempted. You should have something like device fingerprinting—our anti-evasion product—which is better suited for solving antagonistic attempts.

Pricing feels hard with products like Stytch, particularly covering the divide between B2B apps and consumer apps (where B2B apps have fewer users but higher ARPU vs consumer apps). What is your philosophy on pricing and what is the opportunity to differentiate on pricing? How does per-seat pricing evolve for the era of agents?

On the consumer side, we primarily bill on monthly active users because that's the closest element to value that somebody gets from Stytch—enabling them to interact with someone's app means they can monetize them. It's usually just a few pennies, not very expensive on the MAU side, because consumer apps can have customers with 25 million users who need to control their margins.

On the B2B side, there are so many fewer users that if we only priced on monthly active users, we'd have to make it an exorbitant MAU price, which becomes confusing. Instead, we bill on enterprise connections—meaning a B2B customer uses Stytch to support enterprise single sign-on (Okta, Azure) or directory sync (SCIM).

We do this because it's the clearest indicator that they actually have a large paying customer on the other end. We charge rack rates around $100 for each of those, with large volume discounts available.

Your pricing on the consumer side scales with the number of users you're serving, with discounts as you scale. On the B2B side, it's typically the number of enterprises you're serving where they require you to use SSO as part of their contracting process.

For the agent side and how that fits in, we debated this extensively. What we've found in deals we've done is it makes sense to treat the agent as a user. In our monthly active user metrics, we now reflect agents for customers in their invoices.

If Reed is a monthly active user but Reed himself didn't log in or use my app within the last month, but his agent was using it from Claude or ChatGPT, it counts the same as a monthly active user.

We introduced this definition for both consumer and B2B because enterprise connections don't matter as much for this use case. We do have more enterprise audit controls on the B2B side for agents. We've considered whether that should be the next toggle—maybe it's less about users and more about whether you want allow lists, wait lists, block lists, and similar controls.

It's definitely still early days. We're using "user" as the proxy and treating it as a monthly active agent. We'll see if that's where we are a year from now as we get more feedback.

What role does Stytch have to play to support vibe coding tools like Replit, Lovable, Vercel v0, Bolt.new and others? What have you seen in terms of why certain tools slot in better with vibe coded apps and what is Stytch's opportunity here?

We have a few partnerships in the works there. The first thing we optimized for when vibe coding and AI coding took off a few quarters ago was working really well in Claude Code and Cursor—this micro agent architecture where it understands how to use the Stytch docs.

We prioritized this because it's closer aligned with where we see revenue today. Someone using Claude Code or Cursor is closer to our ICP and persona of an enterprise contracted customer or somebody who could become an enterprise customer.

The next level was everyone at the 0 to 0.1 or 0.5 phase on Lovable, Replit, or Bolt.

What’s exciting about those tools is they make it incredibly easy for anyone to get an idea off the ground, and that’s exactly where Stytch can add value. If you can go from zero to something usable in minutes, you also want auth to feel that seamless, not a speed bump that slows down your flow.

That’s why we’ve been focused on making Stytch drop right into those environments with as little setup as possible. We have a few things shipping next quarter that will make it easier to use Stytch within all those tools.

And the bigger opportunity is what happens next. A lot of these vibe-coded apps don’t stay “toy projects” for long—they evolve into something real that needs more security, more granular roles, and more scalable infrastructure.

That’s where Stytch is uniquely positioned: you don’t have to rip out what you started with and rebuild your identity layer from scratch. You can start with Stytch on day one, and it will carry you all the way through as your app matures.

This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.