ChangeGamer

← All resources

Agent Identity and Authentication

Guide · updated 2026-06-16 · Markdown variant

How autonomous agents prove who they are and get authorized to act: workload identity vs. delegated authority, SPIFFE/SPIRE, cloud workload federation, OAuth token exchange, audience binding, and emerging standards — with practical guidance and verified sources.

An autonomous agent faces a credential problem that neither classic human login nor static service accounts solve cleanly. The agent must prove two distinct things: (1) what it is — its own workload identity — and (2) that it has permission to act on behalf of a human or organization. Conflating these two layers is the root cause of most agent auth mistakes.

The two-layer model

Layer 1 — Workload / agent identity (what the agent is) The agent itself needs a machine identity it can cryptographically prove. This is analogous to a TLS server certificate — but issued dynamically to a running workload rather than a static host. Long-lived API keys shared across agent instances are dangerous: they cannot be tied to a specific running process, they do not rotate automatically, and a leaked key grants permanent access.

Layer 2 — Delegated authority (permission to act on behalf of a user) When an agent takes actions in systems a human owns — reading email, calling an API with the user's permissions, submitting forms — it needs an authorization grant from that human. Holding the user's own credentials is the wrong pattern: it grants unlimited access with no scope boundary and no audit trail separating human actions from agent actions.

Workload identity: short-lived credentials and SPIFFE/SPIRE

The right approach for workload identity is cryptographically attested, short-lived credentials issued to a specific running workload — not a human typing a password or a static token in an environment variable.

SPIFFE/SPIRE (Secure Production Identity Framework for Everyone / SPIFFE Runtime Environment) is the most widely adopted open standard for workload identity. SPIFFE and SPIRE graduated from CNCF incubation in September 2022. The framework issues each workload a SPIFFE Verifiable Identity Document (SVID) in one of two forms:

SVIDs are short-lived and automatically rotated by the SPIRE agent — no human intervention needed. The SPIRE server attests the identity of a workload at launch time using platform-level evidence (Kubernetes service account token, AWS instance identity document, GCP metadata service token, etc.) and only then issues an SVID. This is the key distinction from a static API key: the credential is tied to a provably running workload, not to a secret that can be copied and reused.

See /resources/agentic-security-checklist (section 5 — secrets and credential management) for why long-lived shared API keys are dangerous for agents.

Cloud workload identity federation — all three major cloud providers support OIDC-based workload identity federation: a workload running on one platform (e.g. AWS EC2, a GitHub Actions runner, or a Kubernetes pod) exchanges its platform-issued OIDC token for short-lived credentials in a target cloud (e.g. GCP IAM, Azure Entra ID, AWS IAM). No static cross-cloud secret is required; the exchange is mediated by a Security Token Service. GCP's Workload Identity Federation, AWS IAM Roles Anywhere, and Azure Managed Identities are the canonical implementations. See the GCP documentation at cloud.google.com/iam/docs/workload-identity-federation.

Delegated authority: OAuth and token exchange

OAuth 2.0 authorization code + scopes is the standard protocol for an agent to obtain a bounded grant from a user. The user authorizes specific scopes; the agent receives a token that can only perform those scoped operations. Least-privilege scoping is essential: request only the scopes the current task requires, not a broad grant for all possible future tasks.

The agent-holds-user-token anti-pattern — storing the user's own access token (or refresh token) in the agent is risky: the token may have broad scopes beyond what the task needs, the agent has no distinct audit identity, and token leakage grants attacker-level access to the user's account.

RFC 8693 — OAuth 2.0 Token Exchange (IETF, January 2020) defines a protocol for an agent to present a token it already holds and receive a different, narrower token in return. This is the canonical mechanism for an agent to obtain a downstream token scoped to a specific sub-task or service, without holding the user's original broad token. The grant type is urn:ietf:params:oauth:grant-type:token-exchange.

Confused-deputy and token-passthrough risk — an agent that receives a user token from an orchestrator and forwards it directly to a downstream service creates a confused-deputy vulnerability: the downstream service cannot distinguish a legitimate orchestrator request from a forged one, and the token audience is not validated. RFC 8693 token exchange, combined with RFC 8707 resource indicators (audience binding), closes this gap. See /resources/mcp-server-authentication for how MCP explicitly forbids token passthrough.

RFC 8707 — Resource Indicators for OAuth 2.0 (IETF, February 2020) adds a resource parameter to OAuth requests so the client declares which resource server the token is for. The authorization server then issues a token whose audience (aud claim) is bound to that specific resource, preventing a token issued for Service A from being replayed against Service B.

Emerging agent-auth standards (as of June 2026)

Active standardization work addresses the agent-specific gaps in existing protocols:

IETF WIMSE — the Workload Identity in Multi-System Environments working group was chartered in March 2024 at IETF 119. It is producing architecture documents and token-exchange profiles for workloads that need to authenticate and exchange credentials across heterogeneous platforms. WIMSE explicitly addresses the case where an agent receives a workload identity token and must present it to a downstream system that uses a different identity scheme.

OpenID Foundation — Identity Management for Agentic AI — the OpenID Foundation's AI Identity Management Community Group published a whitepaper in October 2025 identifying two authentication layers that must work in tandem: the agent software itself authenticated as a trusted client, and the human delegating specific permissions. The Foundation has also attracted individual Internet-Drafts (e.g. draft-sharif-openid-agent-identity-00, March 2026) proposing agent-specific claims for OpenID Connect ID tokens — ownership, trust posture, and authorised capabilities. These are individual drafts with no formal IETF working-group standing as of June 2026, but they signal the direction the identity community is moving.

Practical guidance

Cross-links

Verified sources

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

Category: Guide