What two things does an AI agent need to prove before it can act?

An AI agent needs to prove two distinct things before it acts: a cryptographic workload identity establishing what the running agent itself is, independent of any user, and a separate delegated-authority grant establishing that a specific human or organization has authorized it to act on their behalf — conflating these two layers is the root cause of most agent-authentication mistakes.

Why is a static API key a poor way to identify an AI agent workload?

A static API key shared across agent instances cannot be pinned to one specific running process, does not rotate automatically, and grants an attacker indefinite access the moment it leaks, which is why short-lived, cryptographically attested credentials such as SPIFFE/SPIRE's SVIDs — issued only after platform-level launch evidence is checked — are the workload-identity mechanism built to replace it.

Why is it risky for an agent to hold and forward a user's own access token?

Forwarding a user's own access token is risky because that token usually carries broader scopes than the agent's current task needs, gives the agent no distinct audit identity separate from the human it acted for, and creates a confused-deputy vulnerability where a downstream service cannot tell a legitimate forwarded request from a forged one — RFC 8693 token exchange exists specifically to let an agent trade that token for a narrower one instead.

What does RFC 8707 audience binding actually stop an attacker from doing?

RFC 8707 resource-indicator audience binding adds a resource parameter to an OAuth request so the issued token's audience claim is tied to one specific resource server, which stops a token issued for one service from being replayed against a different service it was never meant to reach — closing the specific reuse path that plain token forwarding leaves open.

Is SPIFFE/SPIRE a finished, universally adopted standard for agent identity as of 2026?

SPIFFE and SPIRE are a mature, widely adopted CNCF-graduated standard (graduated September 2022) for workload identity generally, but the newer WIT-SVID profile that binds a SPIFFE credential to the workload's own key pair sits at "Incubating" stability as of mid-2026, below the framework's "Stable" tier, so treat that specific extension as still settling rather than as finished.

← All guides · Agent security operations

How AI Agents Prove Identity and Delegated Authority

Part 10 of Agent security operations · 1,688 words · ~8 min read · published 2026-09-18 · updated 2026-10-02 · Markdown variant

The two-layer model an autonomous agent needs to pass before any credential-custody or permission question even applies: a cryptographic workload identity proving what it is (SPIFFE/SPIRE, cloud workload identity federation) and a separate delegated-authority grant proving it may act on a human's or org's behalf (OAuth scopes, RFC 8693 token exchange, RFC 8707 audience binding).

In short

An autonomous agent has to establish two separate things before any custody or permission question applies: a cryptographic workload identity proving what it is, and a distinct delegated-authority grant proving it may act on a human's or organization's behalf.
SPIFFE and SPIRE, which graduated from CNCF incubation in September 2022, issue each running workload a short-lived SVID that the SPIRE server only mints after checking platform-level launch evidence, replacing a static key nobody can tie to one running process.
An agent that simply holds and forwards a user's own OAuth token creates a confused-deputy vulnerability, because the downstream service receiving that token cannot tell a legitimate agent request from a forged one.
RFC 8693 token exchange lets an agent trade a token it already holds for a narrower one scoped to a specific sub-task, and RFC 8707 resource-indicator audience binding stops that narrower token from being replayed against a service it was never issued for.
The IETF WIMSE working group, chartered at IETF 119 in March 2024, and the OpenID Foundation's October 2025 agentic-AI identity whitepaper are both active standardization efforts rather than settled specifications as of June 2026, so treat agent-specific identity claims in OIDC tokens as an emerging direction, not an adopted standard.

Part of the How to Secure AI Agents in Production guide.

What does an AI agent actually have to prove before it acts?

An AI agent has to prove two separate things before any downstream credential-custody or permission question even applies: what it is, as a running piece of software with its own cryptographic identity, and separately, that it holds delegated authority to act on behalf of a specific human or organization. The agent identity and authentication reference (updated 17 July 2026) frames this directly as a two-layer model, and calls conflating the two layers the root cause of most agent-auth mistakes — a system that only checks one of the two is checking half the question. This sub sits inside the agent security operations pillar's eight-discipline stack as the identity layer underneath its credential-hygiene discipline.

This is deliberately upstream of two other questions this cluster answers elsewhere. Managing secrets for AI agents covers who holds a credential once one already exists, across a chain of tool servers and MCP connectors — custody. Enforcing permission boundaries at runtime covers what an already-authenticated caller is allowed to do on any given call, checked at eight runtime checkpoints — enforcement. Neither question has an answer until identity and delegated authority are established first: a policy engine cannot enforce a boundary for a caller it cannot identify, and a credential inventory means nothing if the thing holding the credential was never proven to be what it claims.

How does an agent prove what it is?

An agent proves what it is through a cryptographically attested, short-lived credential issued to the specific running workload — the software analogue of a TLS server certificate, minted dynamically rather than baked in as a static secret. A shared key copied across every instance of an agent fleet cannot answer "which process is this" at all: it does not rotate on its own, it cannot be pinned to one running workload, and a single leak hands out access with no expiry.

SPIFFE/SPIRE (Secure Production Identity Framework for Everyone) is the most widely adopted open standard for this layer, having graduated from CNCF incubation in September 2022. SPIRE issues each workload a SPIFFE Verifiable Identity Document, or SVID, only after its server checks platform-level launch evidence — a Kubernetes service account token, an AWS instance identity document, a GCP metadata service token — so the credential is tied to a workload SPIRE has actually watched come up, not to a string anyone could copy. Three SVID forms exist:

X.509-SVID — a certificate carrying the workload's SPIFFE ID as a URI in its Subject Alternative Name field, used directly for mutual TLS between two workloads.
JWT-SVID — a signed JWT carrying the same SPIFFE ID, presented as a bearer token in an Authorization header for HTTP/REST contexts.
WIT-SVID — a newer SPIFFE profile of the IETF WIMSE working group's Workload Identity Token format, added at "Incubating" stability as of mid-2026; unlike JWT-SVID it binds the token to the workload's own key pair via a cnf claim, so possession alone isn't enough to use it.

SVIDs rotate automatically through the SPIRE agent, with no human re-issuing anything on a schedule. The same short-lived-credential logic extends across cloud boundaries through workload identity federation: a workload trades the OIDC token its home platform already issued it for temporary credentials in a different cloud, via a security token service, with no static cross-cloud secret ever shared. GCP Workload Identity Federation, AWS IAM Roles Anywhere, and Azure Managed Identities are the three major implementations of that pattern.

How does an agent prove it has permission to act for a human or org?

An agent proves delegated authority through a scoped authorization grant — separate from its own workload identity — that a human or organization issued for a bounded purpose, not by holding that human's own credentials. OAuth 2.0 authorization code flow with scopes is the standard mechanism: a user authorizes a specific set of scopes, and the agent receives a token limited to exactly those operations, ideally requested narrowly for the task at hand rather than broadly for every task the agent might ever run.

The failure mode the resource names explicitly is an agent that simply stores and forwards the user's own access or refresh token instead. That token typically carries scopes far wider than the current task, gives the agent no audit identity distinct from the human it is acting for, and — if it leaks — grants an attacker everything the user themselves could do. Worse, an agent that receives a user's token from an orchestrator and passes it straight through to a downstream service creates a confused-deputy vulnerability: the receiving service has no way to distinguish a legitimate request routed through the agent from a forged one, because the token's audience was never validated against who is actually presenting it.

What closes the confused-deputy gap between two agents or services?

Two IETF mechanisms close it together, and neither one alone is sufficient. RFC 8693 (OAuth 2.0 Token Exchange, January 2020) defines a grant type — urn:ietf:params:oauth:grant-type:token-exchange — for an agent to present a token it already holds and receive a different, narrower one scoped to a specific downstream sub-task, instead of forwarding its original broad token further down the chain. RFC 8707 (Resource Indicators for OAuth 2.0, February 2020) adds a resource parameter to the request so the authorization server binds the issued token's audience claim to one named resource server, which is what actually stops a token minted for Service A from being replayed against Service B. How those two mechanisms compose across several agent-to-agent hops, including the act and may_act claims, is covered in agent delegation chains.

Used together, the two form the general-purpose fix for the token-passthrough anti-pattern above: exchange, rather than forward, and bind the exchanged token's audience to exactly the service it is headed for. MCP's own authorization spec applies this same logic at the protocol level by forbidding token passthrough outright — the wire-level mechanics of that specific flow, including PKCE and MCP's own audience-binding requirements, belong to implementing OAuth 2.1 for an MCP server rather than this general identity layer.

What standards are still emerging for agent-specific identity?

As of June 2026, two efforts are actively closing agent-specific gaps that existing identity and OAuth standards weren't written to cover, and neither is a finished, adopted standard yet. IETF WIMSE (Workload Identity in Multi-System Environments), chartered at IETF 119 in March 2024, is producing architecture documents and token-exchange profiles for a workload that must authenticate across heterogeneous platforms and hand off a credential to a downstream system using a different identity scheme than its own. The OpenID Foundation's AI Identity Management Community Group published a whitepaper in October 2025 identifying the same two-layer split this article covers — the agent software authenticated as a trusted client, and the human delegating specific permissions — as two layers that must work in tandem rather than get collapsed into one. Individual Internet-Drafts have followed, such as draft-sharif-openid-agent-identity-00 (March 2026), proposing agent-specific claims for OpenID Connect ID tokens covering ownership, trust posture, and authorized capabilities; these carry no formal IETF working-group standing as of June 2026 and should be read as a direction the identity community is exploring, not a mechanism to build production auth on top of today.

Where does this identity layer stop, and custody or enforcement begin?

Identity and delegated-authority verification end the moment a caller has been proven to be a specific workload and shown to hold a valid grant — everything past that point is a different question this cluster answers elsewhere. A tool server, MCP connector, or plugin that sits between an already-identified agent and the resource it is calling raises a custody question next: which system actually holds the resulting credential, and does that intermediary have its own separate, longer-lived token an attacker could target instead? That custody question, and the audit steps for answering it across a multi-hop chain, is managing secrets for AI agents's territory, not this one.

A per-call authorization question follows after that: given that an agent has already been identified and its delegated-authority grant established, what is it allowed to do on this specific call? A policy dispatcher answers that by checking a live snapshot against a manifest at each step of an agent's execution loop — covered in enforcing permission boundaries for AI agents at runtime. None of that enforcement logic can run meaningfully against a caller whose identity and authority were never established in the first place, which is exactly why this layer has to come first.

An identity and delegated-authority checklist

A deployment has covered this layer once each item below is true, independent of the credential-custody and runtime-enforcement checklists this cluster covers separately:

Every running agent instance carries its own cryptographically attested workload credential — an SVID or equivalent — rather than a static key it shares with the rest of its fleet
Cross-cloud calls trade a home-platform OIDC token for short-lived target-cloud credentials through a security token service, with no static secret shared between the two environments
Delegated-authority grants are scoped OAuth tokens requested for the task at hand, never the user's own raw access or refresh token stored inside the agent
A downstream hop exchanges its incoming token for a narrower one via RFC 8693 rather than forwarding the original token further down the chain
Every issued token carries an RFC 8707 audience binding naming the one resource server it is valid for, so a captured token can't be replayed elsewhere
WIMSE and OpenID Foundation agent-identity proposals are tracked as an emerging direction worth monitoring, not treated as settled enough to build a production identity layer on alone

Get this layer right and the two questions built on top of it — who holds a credential across a chain, and what an already-authenticated caller may do on a given call — finally have a stable caller identity to attach their own answers to. Skip it, and a credential inventory or a runtime policy engine is enforcing rules against a caller nobody actually verified.

Frequently asked questions

What two things does an AI agent need to prove before it can act?: An AI agent needs to prove two distinct things before it acts: a cryptographic workload identity establishing what the running agent itself is, independent of any user, and a separate delegated-authority grant establishing that a specific human or organization has authorized it to act on their behalf — conflating these two layers is the root cause of most agent-authentication mistakes.
Why is a static API key a poor way to identify an AI agent workload?: A static API key shared across agent instances cannot be pinned to one specific running process, does not rotate automatically, and grants an attacker indefinite access the moment it leaks, which is why short-lived, cryptographically attested credentials such as SPIFFE/SPIRE's SVIDs — issued only after platform-level launch evidence is checked — are the workload-identity mechanism built to replace it.
Why is it risky for an agent to hold and forward a user's own access token?: Forwarding a user's own access token is risky because that token usually carries broader scopes than the agent's current task needs, gives the agent no distinct audit identity separate from the human it acted for, and creates a confused-deputy vulnerability where a downstream service cannot tell a legitimate forwarded request from a forged one — RFC 8693 token exchange exists specifically to let an agent trade that token for a narrower one instead.
What does RFC 8707 audience binding actually stop an attacker from doing?: RFC 8707 resource-indicator audience binding adds a resource parameter to an OAuth request so the issued token's audience claim is tied to one specific resource server, which stops a token issued for one service from being replayed against a different service it was never meant to reach — closing the specific reuse path that plain token forwarding leaves open.
Is SPIFFE/SPIRE a finished, universally adopted standard for agent identity as of 2026?: SPIFFE and SPIRE are a mature, widely adopted CNCF-graduated standard (graduated September 2022) for workload identity generally, but the newer WIT-SVID profile that binds a SPIFFE credential to the workload's own key pair sits at "Incubating" stability as of mid-2026, below the framework's "Stable" tier, so treat that specific extension as still settling rather than as finished.

#agents #security #identity #authentication #oauth #spiffe #workload-identity #delegation

Put this corpus inside your own agents

This guide is free and stays free. The reference corpus behind it — machine-readable contracts, verified primary sources, continuously refreshed — is the paid product: a €5 starter key unlocks every premium reference for one agent via API; a €25 corpus license delivers the full corpus as RAG / fine-tuning data with an explicit AI-use grant; the €150 enterprise license adds commercial redistribution rights.

Agents: this page as Markdown · JSON · offers at /api/pricing.json · payment methods at /api/payment.json · single-resource access via HTTP 402 (how that works)