Everything we've built for auth on the web assumes two kinds of actors: a human user and a closed loop application, with predefined scopes and known execution paths.
Agents are dynamic, non-deterministic, and vary their tasks over time — sometimes acting on behalf of a user, sometimes entirely on their own, calling external services, discovering tools at runtime, needing one capability now and a different one later, often running long after the human who started them has moved on.
These problems share a single root cause: existing auth — OAuth, API keys, sessions — has no concept of an "agent", a distinct runtime actor. The server sees a credential, and credentials identify resources, not the specific actor using them. Without per-agent identity, the server cannot tell which agent made a request, cannot scope one differently from another, and cannot revoke one without affecting every other. There is no lifecycle, no state transitions, no way to expire an agent that should have stopped running hours ago.
Agent Auth solves this by making the runtime agent a first-class principal:
- Identity — each agent is registered with its own identity, scoped to a specific task or session. The server knows exactly which agent is acting.
- Capabilities — instead of coarse-grained scopes, agents are granted specific capabilities that can be escalated or revoked at runtime.
- Lifecycle — every agent is governed by session TTL, max lifetime, and revocation. The server can expire or terminate one agent without affecting any other.
All agents share one token. The server sees the user, not the agent.
Each agent has its own identity. Every request traces back to a specific agent.
Beyond solving the identity problem for delegated agents — agents acting on behalf of a user — Agent Auth addresses two other structural gaps:
Autonomous agents. When there's no user in the loop at all, agents today are forced to pretend to be human — opening a browser, solving a CAPTCHA, clicking through a signup flow. Agent Auth lets an agent register directly with its own identity. When a user later claims the agent, its activity history is attributed to them and capabilities are re-granted under user context.
Discovery. There's no standard way for a service to advertise that it supports agents or how an agent should begin authenticating. Agent Auth standardizes a well-known endpoint and a registry so agents can discover services automatically — by URL or by intent.
Approach
Comprehensive: This protocol is intentionally broad. It covers everything from intent-based service lookup to constrained capabilities to action execution. It's designed to work with existing infrastructure without requiring a lot of assumptions or changes.
Implementation-oriented: This protocol ships with official implementations. We expect most use cases to be served through them. The specification exists to enable additional implementations and custom use cases.
Open source: This project is developed in the open. The spec and reference implementations are open source, and we welcome contributions, feedback, and implementations from the community.
FAQ
Why not use MCP auth?
MCP uses OAuth 2.1 for authentication. OAuth was designed for users authorizing 3rd party applications instead of sharing credentials — it has no concept of per-agent identity, capability-based authorization, or agent lifecycle. When three agents use the same MCP server through OAuth, the server sees one client, not three agents. Agent Auth can sit alongside MCP — services can expose capabilities through MCP tools while using Agent Auth for the identity and authorization layer.
Is this an OAuth replacement?
No. Agent Auth is not meant to compete with or replace OAuth in the general sense. OAuth solves a different problem: letting a user grant a third-party application access to their resources. Agent Auth is a single protocol purpose-built for agent identity, registration, capabilities, and discovery. If you purely support Agent Auth, you don't need an OAuth server, but a server may still support OAuth for users to authorize applications.
Is this tied to Better Auth?
No. This specification and its implementations are created and maintained by the Better Auth team, but they are not tied to Better Auth. You don't need Better Auth to implement or use Agent Auth. The protocol is designed to be adopted independently by any platform or provider.