The internet runs on OAuth 2.0. Since 2012, it has handled how applications request access to user data, how APIs delegate permissions, and how login buttons across billions of apps connect to identity providers. It has worked well enough that most developers stopped questioning it.

Then agents arrived, and OAuth started showing its seams.

When a human logs into Salesforce via Google, the flow is synchronous: redirect, consent screen, token issued, done. The user was there. The user said yes. When an AI agent books a flight, queries a ledger, and triggers a payment while you sleep, there is no consent screen moment. The agent makes decisions mid-task, calls services it discovered at runtime, and may hand off to sub-agents that hand off further down the chain. OAuth was not designed to track any of that.

The spec Dick Hardt wrote in 2012 was designed for clients known at build time. In OAuth and OIDC, a client has no independent identity: a client_id at Google is meaningless at GitHub. Agents pick their tool chain at runtime, one call at a time, choosing the next tool as the task unfolds, and the chain shifts with every task. A scope like mail.read looks identical whether the agent is summarizing your inbox or exfiltrating it. The protocol cannot tell them apart.

This is the problem the industry is currently trying to solve.

What MCP and A2A changed

Anthropic's Model Context Protocol, published in 2024, gave agents a standard interface to tools and data sources. Early MCP servers had minimal authentication, typically API keys in environment variables. That worked for local stdio transport but not for remote servers where tokens could be intercepted.

MCP's March 2025 specification standardized authorization using OAuth 2.1, requiring PKCE from all clients and adding metadata discovery and dynamic client registration. Remote MCP servers running over Streamable HTTP now have a recommended authentication path that developers can implement consistently. The spec is clear: authorization is optional but strongly recommended for any server that lets agents take action.

One gap in that flow is discovery. An agent hitting a remote MCP server for the first time needs to know where the authorization server lives before it can start any OAuth exchange. RFC 9728 (OAuth Protected Resource Metadata) addresses this by letting the server publish its auth endpoint at /.well-known/oauth-protected-resource. Cloudflare added native support for this discovery flow in Cloudflare Access in April 2026, showing how established infrastructure is adapting to support it.

The gap MCP did not address was agent-to-agent communication. If your orchestrator agent needs to delegate to a specialized research agent or a payment processor, MCP provides no protocol for that handoff. Each agent authenticates independently, with no standard way to pass context, reduce permissions, or prove the delegation chain.

Google published A2A on April 9, 2025, with backing from more than 50 launch partners including Salesforce, SAP, and others across enterprise software and services. A2A is built on existing web infrastructure standards, making it compatible with systems businesses already run. It was designed to support enterprise-grade authentication and authorization, with parity to OpenAPI's authentication schemes.

Where MCP handles the connection between an agent and its tools, A2A handles the connection between agents themselves. The protocol enables AI agents to discover each other's capabilities, negotiate task delegation, and coordinate complex workflows across different systems and vendors. An inventory agent built by your team can communicate with a supplier agent built by a third party, using Agent Cards to publish capabilities and OAuth 2.0 flows to handle authentication.

Google donated A2A to the Linux Foundation in June 2025. IBM's ACP (Agent Communication Protocol) merged into it voluntarily in August 2025. By April 2026, A2A had grown to 150+ organizations with production deployments in place across major enterprise software vendors.

The deeper problem: bearer tokens don't work in multi-hop chains

Both MCP's OAuth 2.1 and A2A's authentication schemes still rely fundamentally on bearer tokens. If you hold the token, you can use it. In a multi-agent pipeline, that creates a structural problem.

Multi-agent delegation chains require a constraint that standard token formats cannot enforce: each hop should only be able to reduce permissions, never expand them. With bearer tokens, there is no mechanism to prevent a sub-agent from reusing a delegated credential at full scope.

This is where AAuth enters. Dick Hardt, who co-authored OAuth 2.0, has been developing a specification at aauth.dev that treats agents as first-class identities. AAuth brings together authentication, authorization, and a set of OAuth RFCs, combined with message signing and discovery, to provide a foundation for agent identity and access management. In AAuth, agents require signed HTTP messages, unify identity and authorization into one protocol, and make delegation explicit and verifiable.

The core shift is cryptographic. AAuth proposes that every HTTP request be signed by the agent's key pair. Bearer tokens become irrelevant because a stolen token without the corresponding private key cannot be replayed. Delegation chains become explicit, visible, and auditable rather than reconstructed after the fact from logs.

AAuth is currently an exploratory specification, not a ratified standard. The playground at playground.aauth.dev lets you call whoami.aauth.dev to see agent identity claims in practice. It is worth tracking because it works from first principles rather than extending a protocol designed for browsers: what would authentication look like if agents were the starting point?

Token formats like Biscuits and Macaroons approach the scope attenuation problem differently. These allow the agent receiving a token to cryptographically restrict it before passing it downstream, and those restrictions cannot be removed by any party that does not hold the original minting key. No round-trip to an authorization server is needed to narrow permissions. The restriction is embedded in the token itself.

WIMSE and the IETF's framework

The IETF has been developing workload identity standards under the WIMSE (Workload Identity in Multi-System Environments) working group. In March 2026, draft-klrc-aiagent-auth-00 was published, composing WIMSE, SPIFFE, and OAuth 2.0 into a 26-page framework called AIMS (Agent Identity Management System).

The draft adopts the WIMSE identifier as the primary agent identifier, a URI that uniquely identifies a workload within a trust domain. All authorization decisions, delegation, and audit logs pivot on this ID, which must remain stable for the lifetime of the workload identity. SPIFFE (Secure Production Identity Framework for Everyone) is the operationally mature implementation, achieving automatic credential rotation transparently to the agent and binding ephemeral key material with each credential.

The draft is solid on authentication. The WIMSE identifiers bind agent identity to the execution environment through hardware-rooted attestation. The authorization layer, however, stops at the token boundary. The Security Considerations section of the -00 revision contains two words: "TODO Security." Authentication is getting formalized. Authorization across trust domains is still a product and engineering problem.

NIST launched two initiatives in February 2026, the NCCoE concept paper on AI agent identity and authorization, and the AI Agent Standards Initiative covering security controls and testing. Both center on WIMSE and SPIFFE combined with OAuth. The Colorado AI Act establishes a "reasonable care" standard for high-risk AI systems effective June 30, 2026, and widely adopted identity standards will likely qualify as evidence of that care in court.

What practitioners are shipping today

Auth0 (part of Okta) reached general availability of Auth0 for AI Agents in November 2025. Using Client-Initiated Backchannel Authentication (CIBA), agents can pause execution, request user approval via email or Auth0 Guardian, and resume automatically once the user approves. The SDK detects when a tool call needs authentication, stores the token securely, and resumes without further developer intervention. Auth0 is also collaborating with Google Cloud on A2A authentication, which signals how incumbent identity vendors see this space.

The auth discussion so far has covered how agents prove their identity to services. The inverse problem also needs a standard answer: how does a service verify that the agent connecting to it is who it claims to be? The Web Bot Auth IETF draft tackles this from the server side. It lets bots sign their HTTP requests with a private key and publish their corresponding public keys at /.well-known/http-message-signatures-directory, allowing receiving sites to cryptographically verify inbound bot traffic rather than relying on user-agent strings that any client can spoof. It is the server-side complement to what AAuth proposes on the client side: a matched pair of signing and verification standards that, taken together, give both ends of an agent interaction a way to establish cryptographic trust.

The hardcoded credential problem has not improved. GitGuardian's State of Secrets Sprawl 2026 report found 28.65 million hardcoded secrets added to public GitHub in 2025 alone, a 34% year-over-year increase and the largest single-year jump on record. Agents generate logs, produce configuration files, and replicate workflows automatically. The exposure surface is larger than with traditional integrations.

The Apideck Unified MCP server offers a concrete example of how this plays out in production. The server at mcp.apideck.dev/mcp exposes 229 tools across Accounting, HRIS, CRM, and more. Auth against the MCP server itself happens via three request headers: x-apideck-api-key, x-apideck-app-id, and x-apideck-consumer-id. The consumer ID is what connects an agent to a specific user's pre-authorized integrations. Before the agent ever runs, the end user has authorized their connectors (QuickBooks, Xero, BambooHR) through Vault, Apideck's credential management layer. When the agent calls a tool, Vault looks up the correct credentials in the background and injects the right token before making the downstream API call. The agent never holds OAuth tokens for third-party services directly.

This architecture solves several problems at once. The human consent step happens once, at connection setup, not mid-task. The agent's credential surface is three static headers rather than a collection of OAuth tokens for every connected service. Vault handles token refresh and rotation automatically. The MCP server also annotates tools with permission levels (read, write, destructive), so a read-only agent cannot even discover delete operations in the tool list. That is the same principle AAuth formalizes at the protocol level: permissions should be bounded at each hop, not left to the agent to self-limit.

A production-grade auth architecture today looks like: OAuth 2.1 with PKCE for MCP tool access, A2A with Agent Cards for cross-agent delegation, SPIFFE-issued short-lived credentials for workload authentication, and either token attenuation (Biscuits or Macaroons) or AAuth-style signed requests for multi-hop chains where scope reduction matters. None of this is a single product. It is an architecture you compose from pieces that are still being standardized.

Where this leaves builders

The authentication layer is converging. MCP has OAuth 2.1. A2A has enterprise-grade security parity. The IETF has a formal framework draft. Auth0 and comparable providers are shipping agent-specific SDKs.

The authorization layer is where teams will differentiate. Knowing that an agent is who it claims to be is one problem. Knowing what it is actually allowed to do during a specific task, and producing proof of that afterward, is harder. The OWASP MCP Top 10, A2A's signed Agent Cards, and the WIMSE architecture address pieces of it. No single specification covers the full chain from identity through intent to audit trail.

The infrastructure gap extends beyond the auth layer itself. Cloudflare scanned the 200,000 most visited domains in April 2026 and found that fewer than 4% of sites have declared AI usage preferences in their robots.txt, and emerging standards like MCP Server Cards and API Catalogs appeared on fewer than 15 sites in the entire dataset. Most of the internet is not yet set up to receive authenticated agent traffic, let alone verify it. isitagentready.com scores any site across discoverability, content, bot access control, and protocol capabilities, including whether OAuth server discovery is published correctly, and generates per-check prompts you can hand to an agent to fix what is missing.

For anyone building integrations that agents will traverse, this matters in concrete terms. The question is no longer whether your API supports OAuth. The question is whether your auth layer can handle delegated credentials, reduce scope at each hop, and produce a trail that tells you exactly which agent did what and on whose behalf. Most existing OAuth implementations were not designed to answer those questions. The work to make them do so is happening now, across several overlapping standards bodies, and the teams that understand the full stack will have a clear advantage.