AAuth: A New Authentication Standard Built for the Age of AI Agents

The person who arguably understands OAuth’s limitations better than anyone is the person who created it. Dick Hardt—the author of the OAuth 2.0 specification, founder of ActiveState, and a pioneering voice in digital identity since his influential “Identity 2.0” keynote at OSCON 2005—has published an exploratory specification for a new protocol called Agent Auth (AAuth). It’s designed from the ground up for a world where AI agents, not just humans, are the primary consumers of APIs and protected resources.

This isn’t a minor extension to OAuth. It’s a rethinking of how authentication and authorization should work when autonomous software acts on behalf of users, organizations, and itself—across trust boundaries that OAuth was never designed to handle.

Why a new protocol?

OAuth 2.0 was created to solve a specific problem: letting users authorize applications to access their data without sharing passwords. It succeeded spectacularly. But the internet has evolved in ways that expose fundamental assumptions baked into OAuth’s design.

Start with token security. OAuth’s default model treats tokens like keys—whoever holds them can use them. Token exfiltration has become a common attack vector, and while extensions like DPoP and mTLS add proof-of-possession, they’re optional and inconsistently deployed. Most production OAuth deployments still rely on bearer tokens.

Then consider registration. OAuth requires applications to register with each authorization server before they can request access. That worked when a handful of apps connected to a handful of APIs. In an MCP ecosystem where an agent might dynamically discover and connect to any tool server, pre-registration becomes a bottleneck that blocks the dynamic discovery agents need.

There’s also a trust asymmetry that OAuth never addressed. Agents authenticate to resources, but resources don’t authenticate to agents. There’s no cryptographic way for an agent to verify that the API it’s calling is the legitimate resource and not a man-in-the-middle. This opens the door to confused deputy attacks where an attacker redirects authorization flows to malicious endpoints.

Beyond these technical gaps, the protocol itself is fragmented. OAuth provides authorization. OpenID Connect provides authentication. Applications that need both—which is most of them—must implement two protocols, navigate their interactions, and avoid common mistakes like using ID tokens for API access. And OAuth’s client model assumes a single application with a registered client_id and client_secret, while an AI agent might be one of millions of distributed instances, each needing unique identity without sharing long-lived secrets.

How AAuth works

AAuth redefines the relationship between three participants:

• Agents — the applications and autonomous processes (replacing OAuth’s “clients”)
• Resources — the protected APIs and data endpoints (equivalent to OAuth’s resource servers, but with their own cryptographic identity)
• Auth Servers — the systems that authenticate users and issue authorization (combining OAuth AS and OIDC IdP roles)

Every request is signed

The most fundamental change: AAuth eliminates bearer tokens entirely. Every request an agent makes is cryptographically signed using HTTP Message Signatures (RFC 9421). The signature covers the HTTP method, URL, and key material—providing proof that the request came from the entity that holds the private key and hasn’t been tampered with in transit.

This isn’t optional or a security profile that implementors can choose to skip. It’s the baseline requirement for every AAuth interaction.

Three progressive authentication levels

Rather than OAuth’s binary model (you have a token or you don’t), AAuth supports progressive authentication that resources can request dynamically.

At the lowest level, an agent signs requests with an ephemeral key but remains pseudonymous—the resource can’t identify who it is, but can rate-limit by key and detect request tampering. This is useful for public endpoints that want abuse prevention without requiring identity.

One step up, the agent proves its identity using published JWKS (for agent servers) or a signed agent token (for agent delegates). Now the resource can verify exactly which agent is making the request and apply identity-based policies: allowlisting, preferential rate limits, audit logging.

At the highest level, the agent presents an auth token issued by an auth server, proving it has been authorized to access the specific resource with specific permissions—optionally on behalf of a specific user. This is the closest equivalent to OAuth’s access token, but with mandatory proof-of-possession.

Resources use an Agent-Auth response header to dynamically challenge for the level they need:

HTTP/1.1 429 Too Many Requests
Agent-Auth: httpsig; identity=?1

This tells the agent: “you’ve exceeded rate limits for anonymous access—prove your identity to get higher limits.” The agent can upgrade without starting a new flow from scratch.

Agent identity without pre-registration

In AAuth, agents are identified by HTTPS URLs rather than pre-registered client IDs. An agent publishes metadata and a JSON Web Key Set (JWKS) at a well-known URL. Any resource or auth server can discover the agent’s identity by fetching this metadata—no registration step required.

For distributed applications (mobile apps, CLI tools, cloud workloads), AAuth introduces agent delegation. An agent server issues short-lived agent tokens to agent delegates, binding each delegate’s ephemeral signing key to the server’s authoritative identity. Each delegate gets a persistent sub identifier that survives key rotations—so refresh tokens remain valid even when a mobile app generates a new key pair after restart.

Resources have cryptographic identity too

This is perhaps AAuth’s most novel contribution. In OAuth, resources are implicit—they’re just URLs that accept tokens. In AAuth, resources have their own JWKS and issue signed resource tokens that cryptographically bind an access request to a specific agent and a specific resource.

When an agent requests access, the resource issues a resource token containing:

• The resource’s identity (signed with its key)
• The agent’s identity and current key thumbprint
• The requested scopes

The agent presents this resource token to the auth server. The auth server can now verify that the request is legitimate—the resource itself has confirmed it wants this specific agent to have this specific access. This eliminates confused deputy attacks where an attacker substitutes a malicious resource identifier in the authorization flow.

Multi-hop access and token exchange

Modern architectures frequently require resources to call downstream resources to fulfill requests. AAuth handles this natively through token exchange: a resource acts as an agent, presents the upstream auth token to a downstream auth server, and receives a new auth token with an act claim showing the full delegation chain.

When downstream access requires user consent the resource doesn’t have, AAuth provides a user_interaction mechanism that bubbles the consent request back up through the chain to the user.

AAuth vs. OAuth 2.1: What actually changes

What AAuth provides

The headline improvement is eliminating bearer tokens entirely. Because every request is cryptographically signed, token exfiltration stops being an attack vector—there are no tokens to steal that would be useful without the corresponding private key.

AAuth also unlocks dynamic ecosystems that OAuth’s registration model prevents. Agents and resources can interact without pre-established relationships because discovery happens through published metadata, not manual registration workflows. This matters enormously for MCP-style architectures where agents connect to tool servers they’ve never seen before.

The confused deputy problem—one of the more subtle but dangerous vulnerabilities in OAuth flows—gets a structural fix through resource tokens that bind access requests to verified identities on both sides of the interaction. And by collapsing authentication and authorization into a single protocol with a single token type, AAuth eliminates the OAuth/OIDC split that has confused implementors for years.

What AAuth doesn’t provide (yet)

It’s important to be clear about where AAuth stands today. The spec is explicitly described as “an exploration and explainer, not a ready-to-adopt draft.” There are no production implementations, no conformance test suites, and no interoperability testing. This is a design document, not a shipping standard.

AAuth is also not backward compatible with OAuth. It’s a new protocol, not a profile or extension. Adoption requires new implementations, not configuration changes to existing OAuth servers—though AAuth is designed so that auth servers can add AAuth endpoints alongside their existing OAuth ones, enabling a gradual transition rather than a hard cutover.

The spec leaves several areas for future work. Rich delegation policies—purpose limitations, time restrictions, data minimization constraints on what agent delegates can do—are mentioned but not yet specified. And the most significant gap is ecosystem adoption. OAuth’s strength was never just its protocol design; it’s the thousands of libraries, the major platform support, the developer familiarity. AAuth has none of that yet, and building an ecosystem from zero is a fundamentally different challenge from protocol design.

Enterprise implications

For enterprises evaluating agent authentication strategies, AAuth represents a significant signal even in its exploratory state. The problems it addresses are real—every enterprise deploying AI agents faces the identity challenges AAuth describes: agents that don’t fit the OAuth client model, dynamic tool discovery that breaks pre-registration, bearer tokens that create exfiltration risk, and multi-hop access patterns that require workarounds.

Whether AAuth itself gets adopted or its ideas flow back into the OAuth ecosystem is an open question. The OAuth community is already exploring concepts AAuth pioneers—the draft Client ID Metadata Document spec proposes HTTPS URLs as client identifiers, for example. The direction of travel is clear even if the vehicle isn’t decided.

What enterprises can act on now: design your architecture to support signed requests and proof-of-possession tokens, because the move away from bearer tokens for agent traffic is inevitable regardless of which protocol prevails. And pay attention to how MCP’s auth story evolves. MCP currently specifies OAuth 2.1, but AAuth was designed with MCP’s dynamic ecosystem explicitly in mind. If MCP adopts AAuth concepts—or AAuth itself—that will significantly reshape what enterprise agent platforms need to support.

About the author

Dick Hardt’s work on AAuth carries particular weight because of his history. He authored the OAuth 2.0 specification (RFC 6749), which became the foundation for authorization across the modern web. Before that, he founded ActiveState (acquired by Sophos in 2003), created the SXIP identity protocol, and co-authored the OpenID 2.0 specification. His “Identity 2.0” keynote at OSCON 2005 helped shape the industry’s thinking about user-centric identity.

AAuth represents Hardt asking: if we were designing authorization today—knowing what we know about agent architectures, distributed applications, and modern security requirements—what would we build? The answer isn’t just an academic exercise. It’s a preview of where agent authentication is heading, from the person who defined where it started.