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.
| 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.
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:
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.
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:
It cannot answer:
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.
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:
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.
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:
It does not prove:
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.
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:
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. A valid identity becomes an allowlist bypass. Signing tells you who holds a key. It does not make every request from that identity safe. Keep behavioral controls, rate limits, route policy, and response-level data authorization in place for verified agents.
The user and agent collapse into one subject. If a downstream service sees only the user, it cannot tell whether the user acted directly or an agent acted for them. If it sees only the agent, it cannot enforce user-specific consent. Carry both.
A bearer token gains power as it moves downstream. Don't forward the broad original token through every tool call. Exchange or downscope per audience and action.
Discovery metadata is trusted like an access decision. Catalog content can point an agent at an attacker-controlled endpoint. Verify publisher trust metadata, constrain redirects and egress, apply normal SSRF defenses.
Static secrets are cloned with the agent. If every replica shares one API key, you cannot distinguish instances or revoke one compromised runtime.
The audit trail loses authorization context. Logging only the final API call is not enough. Preserve agent identity, delegating principal, token audience and scope, policy version, decision, and result.
-03 updated July 2026, work in progress.
That mix is normal. You do not need to wait for every draft to finalize before removing static secrets, separating agent and user identity, enforcing narrow OAuth audiences, or building complete audit trails. Those are sound security properties regardless of which emerging profile wins adoption.
No one layer can safely stand in for the others. The 2026 standards work matters because it stops treating "AI agent" as one magical new principal and starts decomposing it into the identities, credentials, delegation, policy, and evidence that security systems already know how to manage.
If you're building agent-facing APIs right now — are you separating the agent identity from the delegating user, or is it all still one API key?
Originally published at webdecoy.com. Related reading: