{
  "slug": "agent-identity-authentication",
  "title": "Agent Identity and Authentication",
  "description": "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",
  "tags": [
    "identity",
    "authentication",
    "oauth",
    "spiffe",
    "workload-identity",
    "security",
    "agents",
    "delegation"
  ],
  "updated": "2026-07-17",
  "premium": false,
  "canonical": "https://changegamer.ai/resources/agent-identity-authentication",
  "markdown": "https://changegamer.ai/resources/agent-identity-authentication.md",
  "outline": [
    {
      "depth": 2,
      "text": "Key facts",
      "anchor": "key-facts"
    },
    {
      "depth": 2,
      "text": "The two-layer model",
      "anchor": "the-two-layer-model"
    },
    {
      "depth": 2,
      "text": "Workload identity: short-lived credentials and SPIFFE/SPIRE",
      "anchor": "workload-identity-short-lived-credentials-and-spiffe-spire"
    },
    {
      "depth": 2,
      "text": "Delegated authority: OAuth and token exchange",
      "anchor": "delegated-authority-oauth-and-token-exchange"
    },
    {
      "depth": 2,
      "text": "Emerging agent-auth standards (as of June 2026)",
      "anchor": "emerging-agent-auth-standards-as-of-june-2026"
    },
    {
      "depth": 2,
      "text": "Practical guidance",
      "anchor": "practical-guidance"
    },
    {
      "depth": 2,
      "text": "Cross-links",
      "anchor": "cross-links"
    },
    {
      "depth": 2,
      "text": "Verified sources",
      "anchor": "verified-sources"
    }
  ],
  "related": [
    {
      "slug": "agent-delegation-chains",
      "title": "Agent Delegation Chains: Credential Propagation in Multi-Agent Systems",
      "description": "How credential authority flows when one agent spawns another — the multi-hop delegation problem, RFC 8693 token exchange, the act/may_act claims, audience binding across hops, and the IETF drafts standardizing verifiable actor chains in 2026.",
      "url": "https://changegamer.ai/resources/agent-delegation-chains"
    },
    {
      "slug": "mcp-enterprise-managed-authorization",
      "title": "MCP Enterprise-Managed Authorization: Zero-Touch SSO via ID-JAG (SEP-990)",
      "description": "What Enterprise-Managed Authorization is: the MCP extension (SEP-990) that lets an IdP grant MCP server access during SSO instead of a per-server OAuth consent screen — the ID-JAG mechanism, the RFCs it builds on, and how it layers on standard MCP OAuth 2.1.",
      "url": "https://changegamer.ai/resources/mcp-enterprise-managed-authorization"
    },
    {
      "slug": "mcp-server-authentication",
      "title": "MCP Server Authentication: OAuth 2.1 for Remote Servers",
      "description": "How OAuth 2.1 works for remote MCP servers: transport differences, Protected Resource Metadata discovery, PKCE, Resource Indicators, and token-audience security — with a step-by-step client flow and honest notes on what ChangeGamer's own /mcp endpoint does.",
      "url": "https://changegamer.ai/resources/mcp-server-authentication"
    },
    {
      "slug": "web-bot-auth",
      "title": "Web Bot Auth: Cryptographically Verifying AI Crawlers and Agents",
      "description": "How Web Bot Auth — Cloudflare's implementation of IETF HTTP Message Signatures (RFC 9421) — lets a crawler or agent cryptographically prove its identity to a website, replacing the spoofable User-Agent string and brittle IP allowlists.",
      "url": "https://changegamer.ai/resources/web-bot-auth"
    }
  ],
  "furtherReading": [
    {
      "slug": "mcp-enterprise-sso-id-jag",
      "title": "Zero-Touch Enterprise Authorization for MCP Servers: ID-JAG and SEP-990",
      "description": "How Enterprise-Managed Authorization (SEP-990) removes the per-server OAuth consent screen for MCP servers: the ID-JAG grant mechanism, its RFC 8693/7523 building blocks, named launch adopters as of August 2026, and how it layers on top of standard OAuth 2.1 rather than replacing it.",
      "url": "https://changegamer.ai/articles/mcp-enterprise-sso-id-jag"
    },
    {
      "slug": "fraud-and-abuse-from-agent-traffic",
      "title": "Fraud and Abuse from AI Agent Traffic: What a Seller Should Detect",
      "description": "How a seller of APIs, content, or tools to AI agents spots and mitigates abuse once access is already granted — key sharing, over-scope scraping, spend-ceiling circumvention, spoofed identity, and rate-limit evasion patterns specific to autonomous agents.",
      "url": "https://changegamer.ai/articles/fraud-and-abuse-from-agent-traffic"
    }
  ],
  "body": "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.\n\n## Key facts\n\n- Agents need to prove two separate things — a cryptographic identity for the running workload itself, and a distinct authorization grant to act on a human's or organization's behalf — and mixing up these two layers causes most agent-auth failures.\n- Static, long-lived keys shared across instances are a poor fit for workload identity because they can't be pinned to one running process, don't auto-rotate, and give indefinite access if leaked — the fix is short-lived, cryptographically attested credentials such as SPIFFE/SPIRE's SVIDs, issued only after the SPIRE server checks platform-level launch evidence.\n- The same idea extends across clouds: a workload can trade the OIDC token its home platform issued it for temporary credentials in a different cloud through a security token service, so no static secret ever has to be shared between the two.\n- For delegated authority, scoped OAuth grants are the standard, and letting an agent simply hold and forward the user's own token is an anti-pattern — it invites overbroad access, no distinct audit trail, and confused-deputy replay against services the token wasn't meant for.\n- Two IETF mechanisms close that gap: token exchange (RFC 8693) lets an agent swap a held token for a narrower one for a sub-task, and resource-indicator audience binding (RFC 8707) ties a token's audience claim to one specific resource server so it can't be replayed elsewhere.\n- Practical hardening layers per-agent unique credentials, short token lifetimes, mandatory audience binding and token exchange over passthrough, built-in rotation/revocation, full per-identity audit logging, and human sign-off before any privilege escalation.\n\n## The two-layer model\n\n**Layer 1 — Workload / agent identity (what the agent is)**\nThe 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.\n\n**Layer 2 — Delegated authority (permission to act on behalf of a user)**\nWhen 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.\n\n## Workload identity: short-lived credentials and SPIFFE/SPIRE\n\nThe 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.\n\n**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 established forms, plus an emerging third:\n\n- **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.\n- **JWT-SVID** — a signed JWT carrying the SPIFFE ID, presented as a plain bearer token in an Authorization header — suitable for HTTP/REST contexts.\n- **WIT-SVID** — a newer SPIFFE profile of the IETF WIMSE working group's own Workload Identity Token (WIT) format, added to the SPIFFE spec at \"Incubating\" stability (below \"Stable\") as of mid-2026. Unlike JWT-SVID, it binds the token to the workload's key-pair via a `cnf` (confirmation) claim, so it must be presented with proof of possession rather than as a bare bearer token — a complement to JWT-SVID, not a replacement, and the SPIFFE spec's own bridge to WIMSE-compatible workload identity.\n\nSVIDs 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.\n\nSee /resources/agentic-security-checklist (section 5 — secrets and credential management) for why long-lived shared API keys are dangerous for agents.\n\n**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.\n\n## Delegated authority: OAuth and token exchange\n\n**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.\n\n**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.\n\n**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`.\n\n**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.\n\n**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.\n\n## Emerging agent-auth standards (as of June 2026)\n\nActive standardization work addresses the agent-specific gaps in existing protocols:\n\n**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.\n\n**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.\n\n## Practical guidance\n\n- **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.\n- **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.\n- **Audience-bind every token (RFC 8707).** Include the `resource` parameter in OAuth requests so tokens cannot be replayed against unintended services.\n- **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.\n- **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.\n- **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.\n- **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.\n\n## Cross-links\n\n- OAuth for MCP servers specifically: /resources/mcp-server-authentication\n- Secrets and credential management in agent pipelines: /resources/agentic-security-checklist\n- Audit logging and tracing of agent actions: /resources/agent-observability\n- Human approval gates for high-stakes actions: /resources/agent-guardrails\n\n## Verified sources\n\n- 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/\n- SPIFFE overview and SVID specification: https://spiffe.io/docs/latest/spiffe-about/overview/\n- SPIFFE WIT-SVID specification (spiffe/spiffe repo, standards/WIT-SVID.md): https://github.com/spiffe/spiffe/blob/main/standards/WIT-SVID.md\n- RFC 8693 — OAuth 2.0 Token Exchange (IETF, January 2020): https://datatracker.ietf.org/doc/html/rfc8693\n- RFC 8707 — Resource Indicators for OAuth 2.0 (IETF, February 2020): https://datatracker.ietf.org/doc/html/rfc8707\n- IETF WIMSE working group (chartered March 2024): https://datatracker.ietf.org/group/wimse/history/\n- WIMSE architecture draft: https://www.ietf.org/archive/id/draft-ietf-wimse-arch-01.html\n- OpenID Foundation — Identity Management for Agentic AI whitepaper (October 2025): https://openid.net/wp-content/uploads/2025/10/Identity-Management-for-Agentic-AI.pdf\n- OpenID Foundation — new whitepaper on AI agent identity challenges: https://openid.net/new-whitepaper-tackles-ai-agent-identity-challenges/\n- GCP Workload Identity Federation documentation: https://cloud.google.com/iam/docs/workload-identity-federation",
  "sources": [
    "https://www.cncf.io/announcements/2022/09/20/spiffe-and-spire-projects-graduate-from-cloud-native-computing-foundation-incubator/",
    "https://spiffe.io/docs/latest/spiffe-about/overview/",
    "https://github.com/spiffe/spiffe/blob/main/standards/WIT-SVID.md",
    "https://datatracker.ietf.org/doc/html/rfc8693",
    "https://datatracker.ietf.org/doc/html/rfc8707",
    "https://datatracker.ietf.org/group/wimse/history/",
    "https://www.ietf.org/archive/id/draft-ietf-wimse-arch-01.html",
    "https://openid.net/wp-content/uploads/2025/10/Identity-Management-for-Agentic-AI.pdf",
    "https://openid.net/new-whitepaper-tackles-ai-agent-identity-challenges/",
    "https://cloud.google.com/iam/docs/workload-identity-federation"
  ]
}