The 2026 agent identity stack: ARD, workload identity, Web Bot Auth and OAuth explained

An identity stack, not a single protocol

A dev.to article published in September 2026 maps out how authentication for AI agents is evolving into a multi-layer stack, and warns that collapsing those layers into one mechanism — usually a long-lived API key — destroys the information an authorization engine needs.

The author points to two developments that shaped the year: Google's open Agentic Resource Discovery (ARD) specification for finding and verifying agentic capabilities, and an IETF Internet-Draft, dated July 2026, that proposes an architecture covering agent credentials, delegated user authority, workload identity, authorization and audit trails. Neither replaces OAuth, the article stresses, and neither makes a signed bot trustworthy on its own.

Why API keys are the wrong shape

Traditional web automation relies on a User-Agent header that names a bot and an API key that grants access. The first is trivially forgeable, according to the article; the second compresses identity and permission into a single long-lived secret, so anyone who extracts it from a log, environment variable, container image or agent transcript inherits its full authority.

Agents make this worse because a single action can involve four distinct principals: the operator who deploys the software, the running workload itself, the user or system whose authority the agent exercises, and the resource owner who decides what that combination may do. An audit trail built on keys, the author notes, can record only that the key acted — not which workload ran, who authorized it, or what constraints applied.

Four layers, four questions

The article organizes the problem into four layers. Discovery, via ARD catalogs, registries and trust metadata, answers where a capability lives and who published its metadata, but not whether the caller may invoke it. Workload identity, using WIMSE credentials, SPIFFE IDs and SVIDs, or mTLS, identifies which running software is calling, but not which user delegated authority. Request authentication, via Web Bot Auth and HTTP Message Signatures, proves an HTTP request came from the claimed automated client, but not that the requested action is permitted. Delegated authorization, via OAuth access tokens, token exchange and transaction tokens, defines what the agent may do, for which audience and on whose behalf — but not that the agent will behave safely.

A fifth layer sits underneath all four: observability. If an operator cannot connect discovery results, workload credentials, user delegation, authorization decisions, tool calls and final side effects, the system is not meaningfully auditable.

What each layer actually proves

ARD handles what happens before invocation. It uses domain-hosted catalogs and federated discovery so an agent can locate a tool, API, MCP server, A2A agent or nested catalog without hard-coded endpoints or a closed directory. The article cautions that verified discovery metadata is not a runtime access token: the resource must still authenticate and authorize the caller. It also notes the specification repository described v0.91 as an evolving draft, so catalogs should be versioned rather than treated as fixed.

Workload identity issues short-lived cryptographic credentials to the runtime after attestation, bound to attributes like cluster, namespace, service account, image or deployment policy. SPIFFE is cited as the mature example: a workload receives a SPIFFE ID and a rotating SVID (X.509 or JWT) through the Workload API instead of shipping a static secret beside the code.

Web Bot Auth profiles RFC 9421 HTTP Message Signatures so automated clients sign request components and servers verify them against operator-controlled public keys. A valid signature proves key possession, integrity of the protected components and freshness — not good intentions, consent, or entitlement to bypass rate limits. The article calls the split between authentication and authorization the most important distinction in the piece, and adds a deployment caveat: most automated traffic is still unsigned, so policies should degrade gracefully to operator-published IP ranges and forward-confirmed reverse DNS, with a bare user-agent string treated as an unproven claim rather than identity.

OAuth then carries authority. When an agent acts on its own authority, the article recommends a narrowly scoped, short-lived, audience-restricted access token obtained through a machine-to-machine grant, with the agent authenticating to the authorization server using its workload credential rather than a static client secret. The piece distinguishes this from the separate case of agents exercising delegated user authority, though its treatment of that case continues beyond the published excerpt.

Why it matters

As agents move from demos into production APIs, identity becomes the boundary between useful automation and unaccountable traffic. The dev.to overview gives engineering teams a shared vocabulary for a problem they currently compress into a single key: who published the tool, which workload is calling, who authorized the action and what it is allowed to do. Building those distinctions in early — rather than retrofitting audit trails after an incident — is what makes agentic traffic governable at all, and the article's layer-by-layer breakdown is a practical checklist for anyone designing that architecture in 2026.