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 became important in 2026. Google announced the open Agentic Resource Discovery specification for finding and verifying agentic capabilities. 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 document replaces OAuth. Neither makes a signed bot trustworthy. Together, however, they show what a serious agent identity architecture needs to look like.

The short version: four identity layers, four questions

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 are not enough

Traditional web automation often has two identity mechanisms:

1. A User-Agent header that names the bot.
2. An API key that grants access to a service.

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 possesses it inherits its authority.

AI agents make this weakness worse because one action can involve several distinct principals:

• The agent operator, which owns or deploys the software.
• The running agent workload, which needs its own stable identity and credentials.
• The delegating user or system, whose authority the agent may be exercising.
• The resource owner, which decides what that combination may do.

Collapsing those principals into one API key destroys the information an authorization engine needs. It also creates an audit record that says only “the key did it,” not which workload ran, who authorized it, what constraints applied, or where the 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. The draft calls the overall conceptual stack an Agent Identity Management System, or AIMS. It is an architecture, not a new product or wire protocol.

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, skill, or nested catalog without relying on a closed directory or hard-coded endpoint?

ARD uses domain-hosted catalogs and federated discovery services. A publisher can describe resources and attach trust metadata; a consumer can discover a candidate, verify the published information, and then connect through the resource’s native protocol. Google’s announcement describes support for MCP servers, A2A agents, OpenAPI tools, and nested catalogs.

The boundary matters. ARD is intentionally pre-invocation infrastructure. It does not execute the tool, authenticate every request, or make the authorization decision. Once discovery hands the consumer the endpoint, protocol, and trust information, the native protocol takes over.

That means ARD can help answer:

• Which domain claims this capability?
• Where is its endpoint and protocol description?
• What trust material did the publisher provide?
• Which registries or catalogs returned the result?

It cannot answer:

• Is this particular calling process the agent it claims to be?
• Did a user authorize this transaction?
• Is the requested action within policy?
• Should the resource allow the call right now?

Put differently: verified discovery metadata is not a runtime access token. It can establish a trusted starting point, but the resource must still authenticate and authorize the caller.

ARD itself was still evolving when this article was published. The open ARD specification repository described version 0.91 as an evolving specification. Teams can experiment with it, but should version their catalogs and avoid treating 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.”

This is the workload identity pattern. The agent has a stable identifier, while its credentials are temporary and rotated. A workload identity system can bind issuance to facts such as the cluster, namespace, service account, image, execution environment, or deployment policy.

SPIFFE is a mature example. A workload receives a SPIFFE ID and a short-lived SPIFFE Verifiable Identity Document, or SVID, through the Workload API. An SVID may be X.509 or JWT based. The workload can then use that identity for mTLS or application-level authentication without shipping a long-lived secret beside the code.

The IETF AI agent authentication draft is broader. It points to WIMSE identity and credential work and allows a SPIFFE ID as one concrete identifier. Its important requirements are architectural:

• 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 configuration.
• Authenticate the agent independently from the user it represents.

This identity is useful even when no human is involved. A scheduled research agent, inventory reconciler, or autonomous monitoring service still needs its own identity so policy can distinguish it from every other workload in the environment.

Layer 3: Web Bot Auth proves an automated HTTP caller

Workload identity is a natural fit inside an organization or trust domain. The open web has a different problem: a site receives an HTTP request from a crawler or browsing agent it does not operate. The request claims a name, but the origin needs evidence that the claim belongs to the operator.

Web Bot Auth addresses that boundary. It profiles RFC 9421 HTTP Message Signatures so automated clients can sign relevant request components and servers can verify the signature using public keys associated with the agent operator.

A valid signature can prove that:

• The request was signed by the holder of the corresponding private key.
• Protected request components were not changed after signing.
• The signature was created within its validity window.
• The caller’s identity claim can be tied to an operator-controlled key.

It does not prove that:

• 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: authentication is evidence for an authorization decision, not the decision itself.

Web Bot Auth is particularly useful for public-web traffic because it upgrades a spoofable user-agent claim into verifiable request identity. It also coexists with fallback verification. Most automated traffic is still unsigned, so sites may use operator-published IP ranges and forward-confirmed reverse DNS where available, then treat a bare user-agent string as unproven.

For a deeper protocol walkthrough, see Web Bot Auth and signed crawlers and our analysis of the signed-agent identity shift.

Layer 4: OAuth carries authority, including user delegation

Once an agent is authenticated, a resource still needs to know what it may do. That is OAuth’s job.

There are two materially different cases.

The agent acts on its own authority

A service agent may call an API as itself. It can obtain a narrowly scoped access token through an appropriate machine-to-machine grant and authenticate to the authorization server with its workload credential. The IETF draft explicitly argues against substituting a static, long-lived client secret for workload identity.

The resulting token should be:

• Short lived.
• Restricted to the intended audience.
• Limited to the minimum scopes or actions.
• Bound to the authenticated client where the deployment supports it.
• Revocable or replaceable without rebuilding the agent.

The agent acts for a user or another system

Here 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 such as the authorization code flow; the agent separately authenticates itself with its workload credential.

The resource should be able to answer both:

1. Which agent exercised the authority?
2. Which user or system delegated it?

That separation limits the confused-deputy problem. It also prevents an audit record from falsely attributing an automated action directly to the human.

For multi-service workflows, OAuth 2.0 Token Exchange lets a security token service exchange one token for another with a different audience or reduced authority. The IETF agent draft also discusses transaction tokens for downscoping authority across internal call chains. Every hop should narrow or preserve authority; no downstream tool should silently gain a broader token than the initiating agent received.

OAuth’s current security guidance is consolidated in RFC 9700. Agent systems should follow those protections rather than reviving weaker historical patterns simply because an autonomous client is involved.

An end-to-end AI agent authentication flow

A defensible architecture can now be described as one sequence:

1. Discover. The agent queries an ARD catalog or federated discovery service and receives a candidate capability, endpoint, protocol description, and trust metadata.
2. Verify discovery. The agent validates the publisher and trust information before connecting. Discovery results are treated as untrusted input until verified.
3. Attest the workload. The runtime proves where and how the agent is running. The workload identity system issues a short-lived credential bound to the agent’s stable identifier.
4. Authenticate the connection or request. Inside a trust domain, this may be mTLS or a WIMSE proof. At a public website boundary, it may be Web Bot Auth. The mechanism should bind the credential to the actual request or channel.
5. Obtain authority. The agent gets an OAuth token for its own workload authority or for explicitly delegated user authority. The agent identity and delegated subject remain distinguishable.
6. Authorize at the resource. The resource evaluates the agent, subject, audience, scope, action, tenant, risk, and current policy. A valid credential is necessary evidence, not an automatic allow.
7. Downscope each hop. Token exchange or transaction tokens give downstream tools only the authority they need.
8. Record and monitor. Logs connect the agent identifier, delegating subject, credential or token identifier, policy decision, tool call, and resulting side effect.
9. Revoke and remediate. Operators can revoke a workload, key, token, user grant, or discovered resource independently when behavior or posture changes.

The design is composable. A public browsing agent might use workload identity to authenticate to its own control plane, OAuth to carry a user’s delegated authority, and Web Bot Auth when making a signed request to an unrelated website. ARD may have helped it discover an API earlier, but ARD does not need to remain in the runtime request path.

Failure modes this architecture should stop

A valid identity becomes an allowlist bypass

Signing tells the site 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’s identity, 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

An agent should not forward its broad original token through every tool call. Exchange or downscope tokens for each audience and action. This limits blast radius and makes each authorization decision legible.

Discovery metadata is trusted like an access decision

Catalog content can point an agent toward an attacker-controlled endpoint or unexpected protocol. Verify publisher trust metadata, constrain redirects and egress, and apply normal SSRF defenses. Discovery says where a capability claims to be; authorization still decides whether to use it.

Static secrets are cloned with the agent

If every replica shares one API key, the system cannot distinguish instances or revoke one compromised runtime. Use workload attestation and short-lived credentials so a copied binary or container does not inherit durable identity.

The audit trail loses the authorization context

Logging only the final API call is not enough. Preserve the agent identity, delegating principal, token audience and scope, policy version, authorization decision, and action result. The IETF draft treats observability as a security control because incident response depends on reconstructing that chain.

Where WebDecoy fits

WebDecoy operates at the inbound web boundary, where site owners usually cannot see an agent’s internal workload identity or its OAuth relationship with a user. What the site can evaluate is the request that arrived and the public identity evidence attached to it.

The WebDecoy Agent Identity layer uses the strongest evidence available:

• Web Bot Auth signature verification when an operator signs its requests.
• Published IP ranges or forward-confirmed reverse DNS for supported crawlers that do not sign.
• A clearly weaker claimed state when only a user-agent string is present.
• Agent impersonation detection when a verifiable identity claim contradicts the evidence.

That is one layer in the larger architecture described here. WebDecoy does not turn ARD metadata into permission, replace an enterprise workload identity system, or issue a user’s OAuth grant. It gives the receiving website a defensible answer to a narrower and essential question: what identity evidence did this inbound agent request actually earn?

The answer can then feed site policy: allow, monitor, rate limit, challenge, or block. Read the Verified Agents documentation for the implementation model.

A practical implementation checklist

• Assign every agent workload a stable identifier.
• Issue credentials at runtime after workload attestation.
• Make credentials short lived and automatically rotated.
• Never bake API keys or OAuth client secrets into agent images, code, or prompts.
• Keep the agent’s identity separate from the user’s delegated identity.
• Use OAuth scopes, audience restrictions, and expiry as real policy boundaries.
• Downscope authority at each tool or service hop.
• Verify HTTP signatures over the components that matter and enforce replay bounds.
• Treat ARD and other discovery results as untrusted until their trust metadata is verified.
• Do not equate a valid signature with safe behavior or permission.
• Log the agent, delegating subject, authorization decision, tool call, and side effect together.
• Design independent revocation for workload credentials, signing keys, OAuth grants, and discovered resources.
• Support unsigned or partially identified traffic without silently upgrading a claim into verified identity.

What is stable and what is still emerging

The components are at different maturity levels.

• HTTP Message Signatures is standardized as RFC 9421.
• OAuth Token Exchange is standardized as RFC 8693, and OAuth security best practice is RFC 9700.
• SPIFFE is deployed workload identity infrastructure with published specifications and implementations.
• Web Bot Auth is an IETF Internet-Draft built on RFC 9421.
• The AI agent authentication architecture is an individual Internet-Draft, not an RFC or adopted IETF standard. The -03 version was updated in July 2026 and remains work in progress.
• ARD is an open, evolving specification. Its discovery model is useful, but implementers should expect iteration.

That mix is normal. Teams do not need to wait for every draft to become final 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 discovery or request-signing profile wins adoption.

The bottom line

The useful mental model is simple:

• ARD tells an agent what exists and where to find it.
• Workload identity proves which software instance is running.
• Web Bot Auth proves who signed an automated web request.
• OAuth says what that agent may do and on whose behalf.
• Observability proves what happened afterward.

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.

For websites, that architecture begins at the request boundary: stop trusting names that are free to copy, verify identity where proof exists, and keep authorization and behavior controls in the loop even after the signature checks out.

See how WebDecoy verifies agent identity →