# Agent Identity and Authentication

> 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.

Category: Guide · Updated: 2026-06-16 · Tags: identity, authentication, oauth, spiffe, workload-identity, security, agents, delegation
Canonical: https://changegamer.ai/resources/agent-identity-authentication

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:

- **X.509-SVID** — an X.509 certificate embedding the workload's SPIFFE ID in the Subject Alternative Name field as a URI (`spiffe://trust-domain/path`). This certificate is used directly for mutual TLS (mTLS), enabling two workloads to authenticate each other cryptographically before any application data flows.
- **JWT-SVID** — a signed JWT carrying the SPIFFE ID, suitable for HTTP/REST contexts where a bearer token in an Authorization header is needed.

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

- **Give each agent instance its own identity.** No shared keys, no shared OAuth client IDs across agent instances. Per-agent registration means a compromised credential affects one agent, not all of them.
- **Issue short-lived, scoped tokens.** Tokens should expire in minutes to hours, not days. Use refresh tokens or re-attest via SPIRE to get fresh credentials when needed.
- **Audience-bind every token (RFC 8707).** Include the `resource` parameter in OAuth requests so tokens cannot be replayed against unintended services.
- **Use token exchange (RFC 8693) rather than passing tokens through.** When an agent delegates to a downstream service, exchange for a narrower token scoped to that service.
- **Rotate and revoke.** Build revocation into your agent lifecycle: when a task ends, revoke the tokens; when an agent is decommissioned, rotate secrets and expire credentials.
- **Full audit log of which identity did what.** Every action taken by an agent should be attributed to that agent's unique identity in an append-only audit log. See /resources/agent-observability for the broader tracing and logging pattern.
- **Require human approval for high-privilege grants.** Agents should not be able to self-elevate privilege. Any grant of admin-level or broad-scope access should require an explicit human approval step. See /resources/agent-guardrails.

## Cross-links

- OAuth for MCP servers specifically: /resources/mcp-server-authentication
- Secrets and credential management in agent pipelines: /resources/agentic-security-checklist
- Audit logging and tracing of agent actions: /resources/agent-observability
- Human approval gates for high-stakes actions: /resources/agent-guardrails

## Verified sources

- SPIFFE/SPIRE CNCF graduation announcement (September 2022): https://www.cncf.io/announcements/2022/09/20/spiffe-and-spire-projects-graduate-from-cloud-native-computing-foundation-incubator/
- SPIFFE overview and SVID specification: https://spiffe.io/docs/latest/spiffe-about/overview/
- RFC 8693 — OAuth 2.0 Token Exchange (IETF, January 2020): https://datatracker.ietf.org/doc/html/rfc8693
- RFC 8707 — Resource Indicators for OAuth 2.0 (IETF, February 2020): https://datatracker.ietf.org/doc/html/rfc8707
- IETF WIMSE working group (chartered March 2024): https://datatracker.ietf.org/group/wimse/history/
- WIMSE architecture draft: https://www.ietf.org/archive/id/draft-ietf-wimse-arch-01.html
- OpenID Foundation — Identity Management for Agentic AI whitepaper (October 2025): https://openid.net/wp-content/uploads/2025/10/Identity-Management-for-Agentic-AI.pdf
- OpenID Foundation — new whitepaper on AI agent identity challenges: https://openid.net/new-whitepaper-tackles-ai-agent-identity-challenges/
- GCP Workload Identity Federation documentation: https://cloud.google.com/iam/docs/workload-identity-federation