Everything we've built for auth on the web assumes two kinds of actors: a human user and a static application, with predefined scopes and known execution paths.
Agents fit neither role. They act on behalf of a user or entirely on their own, call external services, discover tools at runtime, need one capability now and a different one later, and often run long after the human who started them has moved on.
Agent Auth makes the runtime agent a first-class principal. Each agent is registered with its own identity, granted specific capabilities, and governed by a lifecycle the server controls. The server sees exactly which agent is acting, what it is authorized to do, and can terminate one without affecting anything else.
All agents share one token. The server sees the user, not the agent.
Each agent has its own identity with scoped capabilities and constraints. Every request traces back to a specific agent.
The protocol is designed to solve three problems:
Delegated agents — when an agent acts on behalf of a user, it gets its own identity, fine-grained capabilities with constraints, and an independent lifecycle the server can audit and control.
Autonomous agents — when there's no user in the loop, lets an agent register and operate directly with its own identity — without being forced to pretend to be human by opening a browser, solving a CAPTCHA, or clicking through forms built for people. A user can link to the agent later, claiming its activity history and taking over governance.
Discovery — standardizes a well-known endpoint and a directory so agents can find and connect to services automatically — by URL or by describing what they need in natural language. This avoids the need for pre-configuring services.
Approach
Comprehensive: This protocol is intentionally broad. It covers identity, registration, capabilities, discovery, and lifecycle — everything an agent needs to operate as a first-class principal.
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.
Easy to adopt: It's designed for existing infrastructure. The official implementations ship with adapters that turn your existing OpenAPI / MCP tools into an Agent Auth server.
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.