What is agent auth?

By Nolan Sullivan, Founding Growth Engineer

·Published August 25, 2026·Updated September 9, 2026

Agent identity and agent auth split one question in two. Identity names the principal a session binds to: a person for delegated-user authority, or a dedicated identity with a named human owner for service or workload authority. This dimension is separate from the agent’s working arrangement. Agent auth is Agent auth is the protocol by which the agent proves that binding to a resource and receives its grant. When an agent selects a tool at runtime, the resource still needs a verified principal and an authorization decision before it handles the call. OAuth 2.1 is the current path, while AAuth proposes signed requests for the same layer.

What is agent auth?

Agent authentication and authorization arrive together on every agent request. Authentication proves which principal the agent acts for, and authorization determines what that principal may do. When an employee connects an agent to a Model Context Protocol (MCP) server, both operations commonly run over OAuth 2.1 against the enterprise identity provider in production deployments today.

Three protocols occupy the layer at different stages of maturity.

• OAuth 2.1 is the shipping baseline. The MCP core specification defines an optional authorization model built on it, with PKCE, dynamic client registration, and resource indicators.
• Enterprise-Managed Authorization (EMA), with Cross App Access (XAA) on the identity provider side, keeps OAuth but moves the grant decision from per-server consent screens to the IdP. Both are covered in depth in MCP SSO.
• AAuth is an IETF Internet-Draft that changes the token model itself, replacing bearer tokens with signed requests from a per-agent keypair.

The principal being proven is the subject of its own pages: what qualifies as an agent identity is in agent identity, why a shared service account is the wrong shape for it is in what is NHI, and how existing directory groups and permissions govern agent access is in extending IAM to agents.

What is AAuth for agent authentication?

AAuth is a proposed HTTP authorization protocol for agent-to-resource access, published as the IETF Internet-Draft draft-hardt-oauth-aauth-protocol by Dick Hardt, an author of OAuth 2.0. The current revision, draft-hardt-oauth-aauth-protocol-10, was published on 6 August 2026. The premise is that every HTTP client gets its own cryptographic identity. An agent identifier of the form aauth:local@domain is bound to a signing key published at a well-known URL, verifiable by any party with no pre-registration and no shared secret. Every request the agent makes is signed with HTTP Message Signatures, identity claims and authorization claims travel in the same token, and the protocol coexists with OAuth 2.0 and OpenID Connect rather than replacing them.

The draft defines four resource access modes, each adding parties as the deployment needs them.

• Identity-based. The resource verifies the agent’s signature and applies its own policy.
• Resource-managed (two-party). The resource runs its own authorization flow.
• PS-asserted (three-party). A person server the user chooses asserts identity and consent.
• Federated (four-party). The person server federates with an access server guarding the resource.

Agent governance is an orthogonal layer that any agent with a person server can add. It includes:

• Missions.
• Per-action permission.
• Audit.
• Interaction relay through the person server.

Three token types carry the protocol, agent_token, resource_token, and auth_token, all JWTs verified against a jwks_uri discovered through well-known metadata.

How does AAuth differ from OAuth for agent authorization?

The draft names three main differences from OAuth.

• Signed requests instead of bearer tokens. An OAuth bearer token grants access to any caller that presents it. AAuth binds every request to the agent’s signing key with HTTP Message Signatures, so possession of a token without the private key proves nothing.
• A per-agent keypair instead of a registered client secret. An OAuth client_id is issued by each authorization server, so an identifier registered at one service means nothing at another, and confidential clients carry a shared secret. An AAuth agent identifier travels with the agent, and its public key is published at a well-known URL, so a resource the agent has never contacted can verify it on the first call.
• Agent-originated calls instead of browser-originated grants. OAuth grants begin with a browser redirect before the client may call. An AAuth exchange begins with the agent’s signed request, and when consent is required the server answers 202 Accepted with an interaction requirement, treating a pending decision as a normal protocol state while a person approves mid-task.

The governance layer also adds objects that OAuth scopes do not express.

• A mission scopes a multi-resource task.
• A justification explains why the agent needs access.
• A clarification channel lets the person question the agent before consenting.

How does AAuth relate to MCP, EMA, and XAA?

AAuth is not part of MCP. The MCP core specification (2026-07-28) defines an optional authorization model on OAuth 2.1, and EMA is the stable extension that moves the grant decision to the enterprise IdP through the ID-JAG exchange, with XAA as the Okta and Auth0 implementation of the IdP side. EMA and XAA extend OAuth and keep its token model. AAuth replaces the token model, so conflating it with XAA misreads both. XAA is OAuth with an IdP-issued grant, and AAuth is signed requests with no bearer token at all.

Hardt’s stated motivation runs through MCP. After implementing authorization for an MCP server, he concluded that OAuth is not a good fit for MCP and started the work that became AAuth. That is his framing, not a position the MCP project has adopted, and the specification’s authorization model remains OAuth 2.1. The EMA and XAA mechanics are walked through in MCP SSO, and what the MCP specification does and does not cover on the security side is mapped in MCP security.

Is AAuth a standard?

No. AAuth is an active Internet-Draft, an individual submission with an intended status of Standards Track, and it has not been adopted by an IETF working group. The current revision expires on 7 February 2027 unless a newer one replaces it. Every Internet-Draft is a proposal under discussion, so the document is not a ratified specification.

The work is further along than a paper design. Reference SDKs exist for Node.js, Go, and .NET, a Python demo covers the multi-agent flow, and the GitHub repository hosts the specification family, including companion drafts for bootstrapping and rich resource requests. It is exploratory, and the sensible posture for a security team is to evaluate it, follow working group adoption, and keep production agent traffic on the OAuth path the ecosystem actually ships.

How does Speakeasy do agent auth?

The Speakeasy AI Control Plane runs the shipping path. Sessions authenticate through the identity provider the organization already operates, whether Okta, Microsoft Entra ID, Auth0, WorkOS, Google Workspace, Ping Identity, or any SAML or OIDC provider, using OAuth 2.1 with PKCE and dynamic client registration. The platform’s MCP gateway presents that one OAuth surface to every client, including for upstream servers that have no OAuth of their own, binds each session to a directory principal, and authorizes every tool call against that principal’s grants. Credentials follow the shape task-scoped credentials describes short-lived, identity-bound credentials that expire when the task completes.

Speakeasy does not implement AAuth signed-request auth, and it does not implement the EMA ID-JAG exchange. The platform binds every agent session to a principal from the directory and puts an authorization decision on every tool call. This control applies regardless of the protocol the layer settles on. The identity model behind that binding is the commercial page at agent identity. To see a session authenticate against your own IdP, talk to us.