AI Agent Authentication in 2026: Web Bot Auth, ARD & OAuth

AI agent authentication is not one protocol. It is a stack. An agent may need to discover a tool, prove which workload is running, authenticate an HTTP request, show that a user delegated authority, and leave enough evidence to reconstruct the action later. ARD, workload identity, Web Bot Auth, and OAuth solve different parts of that sequence. Treating any one of them as the whole answer creates an identity gap. That distinction got sharper in 2026. Google announced the open Agentic Resource Discovery specification for finding and verifying agentic capabilities, and a separate IETF Internet-Draft on AI agent authentication proposed an architecture for agent credentials, delegated user authority, workload identity, authorization, and audit trails. Neither replaces OAuth. Neither makes a signed bot trustworthy. Together they show what a serious agent identity architecture has to look like. Four layers, four questions | Layer | The question it answers | Typical mechanism | What it does not prove | |---|---|---|---| | Discovery | Where is the capability, and who published its metadata? | ARD catalogs, registries, trust metadata | That the caller is allowed to invoke it | | Workload identity | Which running software workload is this? | WIMSE credentials, SPIFFE IDs and SVIDs, mTLS | Which user delegated authority | | Request authentication | Did this HTTP request come from the claimed automated client? | Web Bot Auth, HTTP Message Signatures, mTLS | That the requested action is permitted | | Delegated authorization | What may the agent do, for which audience, on whose behalf? | OAuth access tokens, token exchange, transaction tokens | That the agent will behave safely | There is a fifth layer underneath all four: observability. If an operator cannot connect the discovery result, workload credential, user delegation, authorization decision, tool call, and final side effect, the system is not meaningfully auditable. Why API keys and user-agent strings aren't enough Traditional web automation has two identity mechanisms: a User-Agent header that names the bot, and an API key that grants access. The first is a claim anyone can copy. The second is usually both an identity credential and a bearer permission compressed into one long-lived secret. If that key leaks from a log, environment variable, container image, or agent transcript, whoever holds it inherits its authority. AI agents make this worse, because one action involves several distinct principals: - The agent operator - owns or deploys the software. - The running agent workload - needs its own stable identity and credentials. - The delegating user or system - whose authority the agent may be exercising. - The resource owner - decides what that combination may do. Collapsing those into one API key destroys the information an authorization engine needs. It also produces an audit record that says only "the key did it" - not which workload ran, who authorized it, what constraints applied, or where authority changed hands. The July 2026 IETF draft starts from a useful premise: agents are workloads. They should receive cryptographic credentials at runtime, authenticate as themselves, carry delegated authority separately, and preserve both identities through the call chain. Layer 1: ARD discovers capabilities before invocation Agentic Resource Discovery addresses a problem that appears before authentication: how does an agent find the right tool, API, MCP server, A2A agent, or nested catalog without relying on a closed directory or hard-coded endpoint? ARD uses domain-hosted catalogs and federated discovery. A publisher describes resources and attaches trust metadata; a consumer discovers a candidate, verifies the published information, then connects through the resource's native protocol. The boundary matters. ARD is deliberately pre-invocation infrastructure. It can answer: - Which domain claims this capability? - Where is its endpoint and protocol description? - What trust material did the publisher provide? It cannot answer: - Is this calling process the agent it claims to be? - Did a user authorize this transaction? - Is the requested action within policy? Put differently: verified discovery metadata is not a runtime access token. It establishes a trusted starting point; the resource must still authenticate and authorize the caller. ARD is still evolving - the spec repository described v0.91 as an evolving specification. Version your catalogs and don't treat today's fields as permanently fixed. Layer 2: workload identity proves which agent is running After discovery, the caller needs a real identity. The strongest model is not "read a secret from an environment variable." It is "attest this runtime and issue a short-lived credential to the workload that passed attestation." The agent has a stable identifier; its credentials are temporary and rotated. Issuance can be bound to the cluster, namespace, service account, image, execution environment, or deployment policy. SPIFFE is the mature example: a workload receives a SPIFFE ID and a short-lived SVID (X.509 or JWT) through the Workload API, then uses that identity for mTLS or application-level auth without shipping a long-lived secret beside the code. The architectural requirements that matter: - Give the agent a stable workload identifier. - Provision primary credentials at runtime. - Prefer short-lived, automatically rotated credentials. - Keep credentials out of source code, images, prompts, and static config. - Authenticate the agent independently from the user it represents. This is useful even when no human is involved. A scheduled research agent or autonomous monitoring service still needs its own identity so policy can distinguish it from every other workload. Layer 3: Web Bot Auth proves an automated HTTP caller Workload identity fits naturally inside an organization. The open web has a different problem: a site receives an HTTP request from a crawler it does not operate. The request claims a name; the origin needs evidence the claim belongs to the operator. Web Bot Auth profiles RFC 9421 HTTP Message Signatures so automated clients sign request components and servers verify using public keys associated with the operator. A valid signature proves: - The request was signed by the holder of the corresponding private key. - Protected components were not changed after signing. - The signature was created within its validity window. - The identity claim ties to an operator-controlled key. It does not prove: - The agent is benevolent. - The operator has a business relationship with the site. - A user consented to the requested action. - The request should bypass rate limits or bot controls. - The signer is entitled to read, purchase, modify, or delete anything. That last distinction is the most important one in this whole article: authentication is evidence for an authorization decision, not the decision itself. A practical note on deployment: most automated traffic is still unsigned. Web Bot Auth upgrades a spoofable user-agent claim into verifiable request identity where it's present, but if you build a policy that assumes signatures, you will be building for a tiny slice of your actual traffic. Design for graceful fallback - operator-published IP ranges and forward-confirmed reverse DNS where available, and treat a bare user-agent string as unproven, not as identity. Layer 4: OAuth carries authority, including user delegation Once an agent is authenticated, a resource still needs to know what it may do. Two materially different cases: The agent acts on its own authority. It obtains a narrowly scoped access token through a machine-to-machine grant, authenticating to the authorization server with its workload credential - not a static, long-lived client secret. The resulting token should be short lived, audience-restricted, minimally scoped, bound to the authenticated client where supported, and revocable without rebuilding the agent. The agent acts for a user. Now the system must preserve two identities: the agent as the OAuth client, and the delegating principal as the subject. The user grants authority through an interactive flow; the agent separately authenticates with its workload credential. The resource should be able to answer both: - Which agent exercised the authority? - Which user or system delegated it? That separation limits the confused-deputy problem, and it prevents an audit record from falsely attributing an automated action directly to a human. For multi-service workflows, OAuth 2.0 Token Exchange (RFC 8693) lets a security token service swap one token for another with a different audience or reduced authority. Every hop should narrow or preserve authority; no downstream tool should silently gain a broader token than the initiating agent received. Current OAuth security guidance is consolidated in RFC 9700 - follow it rather than reviving weaker historical patterns because the client happens to be autonomous. An end-to-end flow - Discover. Query an ARD catalog; receive a candidate capability, endpoint, protocol description, trust metadata. - Verify discovery. Validate the publisher before connecting. Discovery results are untrusted input until verified. - Attest the workload. The runtime proves where and how the agent is running; the identity system issues a short-lived credential bound to its stable identifier. - Authenticate the connection or request. mTLS or a WIMSE proof inside a trust domain; Web Bot Auth at a public website boundary. Bind the credential to the actual request or channel. - Obtain authority. An OAuth token for the agent's own authority, or for explicitly delegated user authority - with the two kept distinguishable. - Authorize at the resource. Evaluate agent, subject, audience, scope, action, tenant, risk, and policy. A valid credential is necessary evidence, not an automatic allow. - Downscope each hop. Token exchange gives downstream tools only what they need. - Record