The way teams pick an authentication provider has not changed much in a decade. Someone opens a browser, reads through two or three documentation sites, runs a small test, and makes a call. It is a human process, shaped by human preferences.
That process is shifting. When a developer starts a new project today and types a prompt into Claude Code, Cursor, or Codex, the agent scaffolds the project. That includes the framework, the database, the billing setup, and the auth layer. The selection happens before a human reviews it.
This is a practical description of where the decision now lives, and what that means for anyone building or evaluating auth infrastructure.
How the choice used to be made
For years, picking an authentication provider was a developer experience competition. The question was: whose SDK is cleanest, whose docs are clearest, whose prebuilt components save the most time?
Clerk won a lot of those evaluations on developer experience. The components worked out of the box, the documentation was clear, and a developer could wire up sign-in in an afternoon. It became a common choice for new SaaS products on that basis.
Auth0 competed on enterprise depth. NextAuth was the open-source route for developers who did not want to depend on a vendor. Supabase Auth bundled auth with the database layer. Each of these products won its share of projects through the same channel: a developer read the docs, tried the SDK, and made a judgment call.
That judgment call is now being delegated.
What changed in the workflow
Research published in February 2026 by Amplifying pointed Claude Code at real repos 2,430 times across three models, four project types, and twenty tool categories, with no tool names in any prompt. The finding was not that agents pick vendors. It was the reverse.
Claude Code builds rather than buys. Custom/DIY was the most common single label extracted, showing up in twelve of twenty categories. Asked to add auth to a Python project, it wrote JWT and bcrypt from scratch 100% of the time. Across all languages, authentication came back Custom/DIY in 48% of responses. When it did name a tool in the JavaScript ecosystem, the default was NextAuth.js.
Read that as a commercial auth vendor and the picture is stark. The agent's first instinct is to hand-roll. Its second is the free open-source option. A paid provider is the third thing it considers, if it gets there at all. Compare that to categories where the agent picks decisively: GitHub Actions at 94%, Stripe at 91%, shadcn/ui at 90%. Auth has no equivalent default.
Most developers assume these preferences sit in a hidden system prompt. They mostly do not. The preferences come from a layered system that blends what the model absorbed during training, what the environment provides, what vendors have made available, and what the user has configured. The agent reaches for whatever is most accessible at the moment of the decision.
That last point is the one worth sitting with. If a provider's documentation is machine-readable, if there is an installable skill, if there is an MCP server the agent can query live, that provider is more accessible. Availability at machine scale is a new kind of distribution, and right now the category leader in that distribution is nobody.
What an agent reads when picking a library
A human developer browsing documentation sees a navigation menu, a getting-started guide, and a copy button next to code examples. A coding agent does not experience any of that.
Agents read flat text. They work best with Markdown. They benefit from structured instruction files that tell them how to work inside a specific codebase. When a session starts, many agents automatically read any AGENTS.md file they find in the repository root. This is an open convention that gives agents instructions about project structure, conventions, and guardrails. Think of it as a README written for the agent rather than the human.
Supastarter, a production SaaS starter kit, ships AGENTS.md guidelines tuned specifically for Cursor and Claude Code. That is a boilerplate project making the agent's decision easier before the developer even types a prompt. The pattern is spreading beyond auth into any library that wants to be the agent's default reach.
Beyond AGENTS.md, agents benefit from a few other surfaces: a plain-text file at the root of a documentation site that summarises what the docs cover and where things live; a Markdown mirror of documentation pages so agents can fetch clean content without parsing HTML; a query endpoint that lets the agent ask for specific information rather than reading everything at once.
The providers who have built these surfaces are the ones a coding agent can actually work with.
The new selection surface
Clerk was early here. It publishes an installable skill collection: npx skills add clerk/skills gives Claude Code, Cursor, Windsurf, GitHub Copilot, Codex, Gemini CLI, and other agents on the same installer specialised knowledge about implementing Clerk auth. There are more than twenty skills covering setup, custom UI, organizations, billing, webhooks, and per-framework patterns, plus a router skill that sends the agent to the right one. The agent uses that knowledge through the entire session without needing the developer to re-explain the integration pattern.
Auth0 has moved in a related but distinct direction. Its Token Vault, introduced in 2025, is designed for agents acting on behalf of users, securely accessing third-party APIs with the user's actual identity rather than a generic API key. It has kept moving: organization-scoped tokens for multi-tenant B2B reached general availability, and a privileged worker mode is in early access for agents that run on a schedule or in CI with nobody signed in.
At MCP Dev Summit North America in April 2026, six sessions were dedicated specifically to authentication, with OAuth 2.1 spec author Aaron Parecki and Anthropic's Paul Carleton addressing a fragmented auth landscape. Security was the summit's largest track at 23 sessions. The infrastructure layer is taking agent identity seriously. Auth0's work there is largely about the agent-as-actor problem: how does a running agent authenticate when it needs to call an external service?
Clerk is working the agent-as-installer problem: how does a coding agent set up auth for a new project without human direction? It is not exclusively an installer play, since Clerk also ships an MCP server in beta, but the skill collection is where the depth is.
Both problems matter. But right now, the installer problem is the one that determines which provider ends up in a new codebase.
A smaller example worth noting: tiun, a developer tools product focused on auth and integration, publishes a read-only MCP server that Claude Code and Cursor connect to natively, with other agents using mcp-remote as a local proxy. The server surfaces snippet IDs, providers, and product lists live. tiun also maintains an llms.txt file, a Markdown mirror of every documentation page, and a query endpoint for dynamic retrieval. For a product whose core subject is integration cost, lightweight auth complexity is an asset rather than a limitation.
What the gap actually looks like
There is no public benchmark yet that measures time to a working auth flow with and without an agent-native surface installed. What the available data does establish is the shape of the problem.
Left to its own defaults, the agent does not reach for a paid auth provider. It writes the auth itself, or it reaches for the free option. That is not a marketing failure by any particular vendor. It is what happens when a category has no machine-legible default and the model falls back on whatever was most common in its training data.
The mechanism by which a skill or an MCP server changes that is not mysterious. A skill puts provider-specific implementation knowledge into the session before the agent starts guessing. An MCP server lets the agent query for current integration details instead of reconstructing them from memory. Both reduce the number of follow-up prompts a developer has to write to unstick a half-finished integration.
The honest caveat on MCP is context budget. A live lookup only helps when there is room in the context window to make it and use the result. Where there is not, the agent falls back on training data regardless of what is connected. Skills, being loaded up front and scoped, are less exposed to that failure mode than a mid-session query.
If you want a number for your own stack, the test is cheap to run: a fresh repo, an identical prompt, and a stopwatch, once with nothing installed and once with the provider's skill in place. Run it on the agents your team actually uses, because the defaults differ by agent and by model version.
What it means for vendors
If your documentation is not machine-readable, you are not in the running when a coding agent scaffolds a project. That follows the same logic as being absent from search in 2005: you exist, but you are not findable at the moment the decision is made.
The auth category makes this sharper than most. When the measured default is Custom/DIY or the free open-source option, a paid provider is not losing to a competitor. It is losing to the agent deciding the problem was small enough to solve itself.
The shift changes where developer tool companies need to invest. An installable skill, an MCP server, a plain-text documentation index, a Markdown mirror, and AGENTS.md support for common repo patterns: these are distribution assets now. Not marketing assets. Distribution assets.
Auth0's Token Vault work and MCP integration shows a large incumbent moving in this direction. Clerk's skill collection shows a developer-experience-first company doubling down on what made it win, now extended to cover the agent rather than the human.
The vendors who move slowly on this will not disappear. But they will stop being the default. Defaults compound. A project that starts with one auth provider is unlikely to switch mid-build.
What it means for the team choosing
If you are evaluating auth infrastructure today, the criteria have expanded.
Component quality and SDK cleanliness still matter. They are table stakes. The newer questions are: can an agent install this without human direction at every step? Does the provider have an MCP server the agent can query? Is the documentation in a format an agent can actually read? What does time to first working flow look like when the agent does it unassisted?
There is a second question that matters more than speed. An agent left to its defaults will often write your auth rather than install one, and hand-rolled auth is where security bugs live. Session handling, token refresh, password storage, and account recovery are all easy to get subtly wrong and hard to notice. The value of an agent-native provider is not only that it is faster. It is that the agent produces a reviewed integration path instead of an unreviewed implementation.
If your team ships with coding agents as part of the workflow, that difference shows up on every greenfield project, every new service, every time someone starts fresh.
The agent is making the selection. The question is whether the documentation and tooling you are pointing it at gives it anything useful to work from.
Frequently asked questions
Does the agent always pick the same auth provider?
Not always, and that is part of what makes this worth paying attention to. Without any agent-native surface in place, the choice depends on what the model has seen most in training data, and that varies by model and by version. The Amplifying research found the picture shifting between model generations in several categories, with newer models favouring newer tools. In auth specifically it found no stable vendor default at all: the most common outcome was the agent writing the auth itself. A skill or MCP server changes the inputs available at the moment of the decision, which is why installing one is the most direct way to make agent behaviour predictable across a team.
Can a developer override what the agent picks?
Yes, and it is straightforward. If you name a provider in your prompt, the agent will generally follow it. The issue is that most developers do not specify. They say something like 'add authentication' and the agent fills in the gap. The selection only becomes invisible when you are not explicit. If you have a provider preference, state it in the prompt or put it in AGENTS.md at the repo root, which many agents read at session start and carry through the session. Treat it as a strong default rather than a guarantee: agents drift on long sessions, so it is worth checking what actually got wired in.
What is an MCP server and why does it matter for auth?
MCP stands for Model Context Protocol, an open standard introduced by Anthropic in late 2024. It lets a coding agent query an external service during a session rather than relying solely on what it already knows. For auth, it means the agent can ask a provider for live snippet information, current integration patterns, or a list of supported providers without the developer having to paste anything in manually. The agent gets the information it needs, uses it, and moves forward. Providers that have built an MCP server are available to the agent in a way that providers without one are not. The practical limit is context budget: a live lookup only helps when there is room in the window to make it and use the result.
Is this only relevant for new projects?
Mostly, yes, but not entirely. The agent-as-installer problem is most acute at project start, because that is when the auth layer gets wired in for the first time. Switching providers mid-build is expensive, so whatever the agent picks on day one tends to stay. The agent-as-actor problem that Auth0 is addressing with Token Vault is relevant throughout the life of a project, any time a running agent needs to call an external service on behalf of a user, including background agents that run with nobody signed in. So the greenfield decision matters most for the choice of provider, while the ongoing integration patterns matter for everything that happens after.