Standards and drafts tracker

96 entries

• OAuth 2.1

  draft-ietf-oauth-v2-1
  WG draftIETFCore OAuth

  Consolidates OAuth 2.0, bearer tokens, PKCE and the security best current practice into one framework. No implicit grant, no password grant, PKCE everywhere, exact redirect matching.

  For agentsThe baseline MCP profiles. Worth knowing that the normative base of most agent authorization is still, formally, a draft.

  StatusRevision -17, October 2026. OAuth working group document; submission to the IESG is targeted for December 2026. Recent revisions removed the PKCE “plain” method and require authorization servers to send the iss response parameter.

• OAuth 2.0 Authorization Framework

  RFC 6749
  RFCIETFCore OAuth

  Defines the roles (client, authorization server, resource server) and the core grants: authorization code, client credentials, refresh.

  For agentsThe foundation under MCP authorization and nearly every agent delegation scheme.

  StatusOctober 2012. Still the current standard until OAuth 2.1 is published.

• Bearer Token Usage

  RFC 6750
  RFCIETFCore OAuth

  The Authorization: Bearer header and the WWW-Authenticate error vocabulary, including insufficient_scope.

  For agentsThe default way agents present tokens, and the thing proof-of-possession schemes are trying to replace.

  StatusOctober 2012.

• PKCE

  RFC 7636
  RFCIETFCore OAuth

  Proof Key for Code Exchange. Binds an authorization code to the client instance that requested it.

  For agentsMandatory for MCP clients, which must also refuse to proceed if a server does not advertise support.

  StatusSeptember 2015.

• OAuth for Native Apps

  RFC 8252
  RFCIETFCore OAuth

  How desktop and mobile apps should run OAuth: the system browser and loopback or app-claimed redirect URIs.

  For agentsGoverns desktop agents, IDE extensions and CLIs, which are native public clients.

  StatusOctober 2017. BCP 212.

• OAuth for Browser-Based Applications

  RFC 10017
  RFCIETFCore OAuth

  Threats and architecture patterns for apps that run in a browser: backend-for-frontend, token-mediating backend, and browser-only.

  For agentsApplies to agents and copilots embedded in web pages. New in 2026.

  StatusAugust 2026. BCP 212.

• OAuth 2.0 Security Best Current Practice

  RFC 9700
  RFCIETFCore OAuthGuidance

  The consolidated list of OAuth attacks and required defenses. Deprecates the implicit and password grants.

  For agentsThe minimum bar for any agent acting as an OAuth client.

  StatusJanuary 2025. BCP 240. An update draft is in progress.

• Resource Indicators

  RFC 8707
  RFCIETFCore OAuthDelegation

  The resource request parameter, which tells the authorization server which API a token is for so it can restrict the audience.

  For agentsRequired by MCP. An agent talks to many servers; this is what stops a token for one being replayed at another.

  StatusFebruary 2020.

• Authorization Server Issuer Identification

  RFC 9207
  RFCIETFCore OAuth

  Adds an iss parameter to the authorization response so a client can tell which server answered.

  For agentsThe defense against mix-up attacks for clients that use many authorization servers. Clients must validate it under MCP 2026-07-28.

  StatusMarch 2022.

• JSON Web Token (JWT)

  RFC 7519
  RFCIETFCore OAuth

  A compact way to carry claims between two parties, signed or encrypted, with seven registered claims: iss, sub, aud, exp, nbf, iat and jti. A recipient not named in aud must reject the token, and no one may accept it at or after exp.

  For agentsThe format under most tokens on this site: JWT access tokens, ID tokens, Kubernetes service account tokens and workload identity tokens.

  StatusMay 2015.

• JWT Profile for Access Tokens

  RFC 9068
  RFCIETFCore OAuth

  A standard set of claims for JWT-formatted access tokens (at+jwt).

  For agentsThe usual carrier for act and other agent-related claims.

  StatusOctober 2021.

• Token Introspection

  RFC 7662
  RFCIETFCore OAuth

  An endpoint where a resource server asks the authorization server whether a token is active and what it stands for. Only active is required in the answer; sub, client_id and scope are optional.

  For agentsHow an API that cannot read a token, or wants its current state, learns who and what the token is for.

  StatusOctober 2015.

• Token Revocation

  RFC 7009
  RFCIETFCore OAuth

  An endpoint where a client asks the authorization server to revoke a token. Servers must support revoking refresh tokens and should support revoking access tokens.

  For agentsRevocation happens at the authorization server. An API that validates self-contained tokens on its own needs something more to learn of it; the RFC names short token lifetimes and communication between the two servers as options.

  StatusAugust 2013.

• Pushed Authorization Requests

  RFC 9126
  RFCIETFCore OAuth

  The client sends its authorization request directly to the server first and gets back a reference to use in the browser.

  For agentsKeeps detailed, transaction-specific requests out of URLs and safe from tampering.

  StatusSeptember 2021. Updated by RFC 10070.

• JWT-Secured Authorization Request

  RFC 9101
  RFCIETFCore OAuth

  Authorization request parameters packaged as a signed, optionally encrypted JWT.

  For agentsIntegrity for rich authorization requests an agent makes on a user’s behalf.

  StatusAugust 2021.

• GNAP

  RFC 9635
  RFCIETFCore OAuthDelegation

  Grant Negotiation and Authorization Protocol: a ground-up redesign with key-bound clients, negotiated interaction and continuation.

  For agentsLittle deployment, but several newer agent proposals borrow its ideas.

  StatusOctober 2024. Resource server companion is RFC 9767.

• Protected Resource Metadata

  RFC 9728
  RFCIETFDiscovery

  A well-known document where a resource server names the authorization servers that protect it, plus a resource_metadata pointer in WWW-Authenticate.

  For agentsHow an agent that has only a server URL finds out where to get a token. MCP servers must implement it.

  StatusApril 2025.

• Authorization Server Metadata

  RFC 8414
  RFCIETFDiscovery

  A well-known document listing an authorization server’s endpoints and capabilities.

  For agentsZero-configuration discovery. MCP clients must support this and OpenID Connect discovery.

  StatusJune 2018.

• OpenID Connect Discovery

  OpenID Connect Discovery 1.0
  Final specOpenID FoundationDiscovery

  The /.well-known/openid-configuration document and its JWKS pointer.

  For agentsAn MCP authorization server publishes this or RFC 8414 metadata, and an MCP client must support both. It is also the format Kubernetes clusters and CI systems use to publish workload-identity signing keys.

  StatusFinal specification, incorporating errata set 2, December 15, 2023.

• Client ID Metadata Documents

  draft-ietf-oauth-client-id-metadata-document
  WG draftIETFClient identityDiscovery

  The client_id is an HTTPS URL. The authorization server fetches client metadata from it, so no prior registration is needed.

  For agentsThe preferred way for an MCP client to identify itself to a server it has never met.

  StatusRevision -03, November 2026. OAuth working group document. The latest revision requires URL normalization and defines error handling. MCP 2026-07-28 cites -00; the MCP draft revision moves to -03.

• Dynamic Client Registration

  RFC 7591
  RFCIETFClient identity

  A client posts its metadata to a registration endpoint and receives a client ID.

  For agentsThe original answer for MCP. It left authorization servers with unbounded anonymous registrations, which is why MCP moved away from it.

  StatusJuly 2015. Deprecated within MCP as of 2026-07-28, with removal possible from July 2027.

• Attestation-Based Client Authentication

  draft-ietf-oauth-attestation-based-client-auth
  WG draftIETFClient identityProof of possession

  A client instance presents an attestation from its platform or backend, plus proof of possession of a key, to authenticate.

  For agentsA way for a platform to vouch for an individual agent instance. Proposals for agent-instance claims build on it.

  StatusRevision -12, October 2026, following a working group last call in September. That revision changed the header syntax in a wire-breaking way.

• SPIFFE Client Authentication

  draft-ietf-oauth-spiffe-client-auth
  WG draftIETFClient identityWorkload identity

  A workload authenticates to an authorization server with its SPIFFE credential in place of a client secret.

  For agentsSecretless OAuth client authentication for agents that already have a workload identity.

  StatusRevision -03, November 2026. OAuth working group document, reported as waiting on a WIMSE dependency.

• JWT Client Authentication and Grants

  RFC 7523
  RFCIETFCore OAuthClient identityDelegation

  Two uses of a signed JWT at the token endpoint: authenticating a client (private_key_jwt) and as an authorization grant (jwt-bearer).

  For agentsSecretless client authentication, and the second leg of ID-JAG and identity chaining.

  StatusMay 2015. Updated by RFC 10070.

• Updates to JWT Client Authentication

  RFC 10070
  RFCIETFCore OAuthClient identity

  Fixes an audience-confusion weakness in client assertions: the audience must be the authorization server’s issuer identifier.

  For agentsAny agent using private_key_jwt or JWT bearer grants should follow it. Published this month.

  StatusNovember 2026. Updates RFCs 7521, 7522, 7523 and 9126.

• Token Exchange

  RFC 8693
  RFCIETFDelegation

  A token endpoint grant that trades one token for another, and the act and may_act claims for expressing delegation.

  For agentsThe primitive under on-behalf-of flows, ID-JAG, identity chaining and transaction tokens.

  StatusJanuary 2020. No revision is in progress; all work on richer actor chains is in individual drafts.

• Identity Assertion Authorization Grant (ID-JAG)

  draft-ietf-oauth-identity-assertion-authz-grant
  WG draftIETFDelegation

  An enterprise identity provider issues a short-lived grant that another application’s authorization server exchanges for an access token, with no user redirect. Also called Cross-App Access.

  For agentsLets a company’s identity provider decide which agent may reach which application for which employee.

  StatusRevision -06, October 2026. OAuth working group document. Revisions -05 and -06 tightened audience rules and added key binding. The MCP extension pins -04.

• Identity and Authorization Chaining Across Domains

  draft-ietf-oauth-identity-chaining
  WG draftIETFDelegation

  Token exchange in one domain yields a JWT grant that is redeemed at another domain’s authorization server.

  For agentsThe general mechanism for carrying identity across a trust boundary. ID-JAG is a profile of it.

  StatusRevision -17, July 2026. Reported approved and in the RFC Editor queue since June 2026; no RFC number yet.

• Transaction Tokens

  draft-ietf-oauth-transaction-tokens
  WG draftIETFDelegationWorkload identity

  A short-lived, signed token that carries user identity and immutable request context through a call chain inside one trust domain.

  For agentsStops access tokens being passed between an agent’s internal tools and services while keeping the user’s intent attached.

  StatusRevision -11, July 2026. Reported to have completed a third working group last call and to be awaiting write-up.

• Transaction Tokens for Agents

  draft-araut-oauth-transaction-tokens-for-agents
  Individual draftIETFDelegation

  Extends transaction tokens with agent context, re-issued at each agent hop.

  For agentsOne of several attempts to record which agents handled a request.

  StatusRevision -03, October 2026. Individual draft, renamed during 2026; its claim design changed to an agentic_ctx claim.

• OAuth Actor Profile and Actor Chain

  draft-mcguinness-oauth-actor-profile · draft-mw-oauth-actor-chain
  Individual draftIETFDelegation

  Two proposals to make the act claim interoperable: one classifies actor types, the other defines a cryptographically verifiable ordered chain.

  For agentsRFC 8693 treats nested actors as history only. These try to make a multi-agent chain something a resource can rely on.

  StatusIndividual drafts, both revised in fall 2026. Neither is adopted.

• Delegate SD-JWT

  draft-ietf-oauth-delegate-sd-jwt
  WG draftIETFDelegationVerifiable credentials

  Lets the holder of an SD-JWT credential delegate it to another holder by making the key-binding JWT itself an SD-JWT.

  For agentsThe one adopted OAuth working group document whose abstract names agentic systems.

  StatusRevision -00, October 2026. Newly adopted by the OAuth working group.

• Mission-Bound Authorization

  draft-mcguinness-oauth-mission
  Individual draftIETFDelegationHuman in the loopFine-grained authz

  The client submits a description of a task. The server derives detailed permissions from it, binds them to an approver’s consent, and ties tokens to the task’s lifecycle.

  For agentsThe most active current thread on authorizing a bounded piece of agent work, as opposed to granting standing scopes.

  StatusRevision -02, November 2026. Individual draft; the subject of an OAuth interim meeting in October 2026.

• Device Authorization Grant

  RFC 8628
  RFCIETFHuman in the loopCore OAuth

  The user approves on a second device by entering a short code while the client polls.

  For agentsThe default for headless and command-line agents. Read alongside RFC 10027.

  StatusAugust 2019.

• Security of Cross-Device Flows

  RFC 10027
  RFCIETFHuman in the loopGuidance

  Threats and mitigations for flows where approval happens on a different device from the one being authorized.

  For agentsCovers the consent-phishing risks of device codes and backchannel prompts, which is how agents usually reach humans. New in 2026.

  StatusAugust 2026. BCP 247.

• CIBA

  OpenID Connect CIBA Core 1.0
  Final specOpenID FoundationHuman in the loop

  Client-Initiated Backchannel Authentication. The client asks the server to obtain a named user’s approval on their own device, then polls or is called back.

  For agentsThe established way for a background agent to ask a person for approval. The IETF agent architecture draft recommends it, while noting it fits approval before a task better than in the middle of one.

  StatusFinal since September 2021.

• Step-Up Authentication Challenge

  RFC 9470
  RFCIETFHuman in the loop

  A resource server signals that the user must authenticate more strongly or more recently, with acr_values and max_age.

  For agentsLets an API pull a human back in for sensitive operations instead of trusting a long-lived grant.

  StatusSeptember 2023.

• Rich Authorization Requests

  RFC 9396
  RFCIETFHuman in the loopFine-grained authz

  authorization_details: a structured JSON description of exactly what is being authorized, in place of coarse scope strings.

  For agentsConsent for one payment or one file, not “payments” or “files.” The base of several agent proposals.

  StatusMay 2023. A companion draft on metadata and error remediation is reported to be headed for working group adoption.

• Deferred Token Response

  draft-ietf-oauth-deferred-token-response
  WG draftIETFHuman in the loop

  The token endpoint for any grant may answer “not yet” with a deferral code. The client polls or receives a callback once a decision is made.

  For agentsThe OAuth working group’s mechanism for asynchronous and human-in-the-loop approval. Unlike CIBA, the server decides to defer and the client need not name the user.

  StatusRevision -01, October 2026. Adopted by the OAuth working group in 2026.

• AAuth: Agentic Authorization Grant

  draft-rosenberg-oauth-aauth
  Individual draftIETFHuman in the loop

  A new OAuth 2.1 grant by which an agent obtains a token at the moment of access through a human-in-the-loop approval.

  For agentsOne of two unrelated proposals called AAuth. This one extends OAuth.

  StatusRevision -02, November 2026. Individual draft.

• AAuth Protocol

  draft-hardt-oauth-aauth-protocol
  Individual draftIETFProof of possessionDelegationAgent protocols

  Not an OAuth extension. Every agent has its own key and signs every request with HTTP Message Signatures; there are no bearer tokens and no pre-registration.

  For agentsA clean-slate design for agent identity and authorization. The other AAuth.

  StatusRevision -11, September 2026. Individual draft with several companions. Its author reports the work is moving to a new OpenID Foundation working group.

• DPoP

  RFC 9449
  RFCIETFProof of possession

  Demonstrating Proof of Possession. Tokens are bound to a client key, and each request carries a signed proof.

  For agentsMakes a token copied from a log, a trace or a model’s context useless without the key.

  StatusSeptember 2023.

• Mutual TLS and Certificate-Bound Tokens

  RFC 8705
  RFCIETFProof of possessionWorkload identity

  Client authentication with a TLS certificate, and access tokens bound to that certificate.

  For agentsSender-constraining for agents that already have workload certificates.

  StatusFebruary 2020.

• HTTP Message Signatures

  RFC 9421
  RFCIETFProof of possession

  A general way to sign selected parts of an HTTP request or response.

  For agentsThe building block under Web Bot Auth, the WIMSE HTTP signature profile, AAuth, and the card networks’ agent protocols.

  StatusFebruary 2024.

• JWK Thumbprint

  RFC 7638
  RFCIETFProof of possession

  A canonical hash of a JSON Web Key.

  For agentsHow DPoP and related schemes refer to the key a token is bound to.

  StatusSeptember 2015.

• HTTP Signature Keys

  draft-hardt-httpbis-signature-key
  Individual draftIETFProof of possession

  A header for conveying or referencing the public key that verifies an HTTP message signature.

  For agentsWould give signed-request schemes a common way to find the signer’s key.

  StatusRevision -09, September 2026. Individual draft; a call for adoption in the HTTP working group was issued, outcome not confirmed.

• SPIFFE

  SPIFFE specifications
  Final specCNCFWorkload identity

  Secure Production Identity Framework for Everyone: a URI naming scheme for workloads, short-lived identity documents, and a local API for obtaining them without a bootstrap secret.

  For agentsThe de facto workload identifier reused by the IETF agent architecture draft, cloud agent-identity products and agent gateways.

  StatusCNCF graduated project. X.509-SVID and JWT-SVID are stable. In 2026 the project added a third document type, the WIT-SVID (incubating), plus a Broker API and a filesystem delivery specification.

• SPIRE

  SPIRE 1.16
  Project / platformCNCFWorkload identityKubernetes

  The reference implementation of SPIFFE: a server and per-node agents that attest workloads and issue identities.

  For agentsThe usual way to run SPIFFE yourself, on Kubernetes or elsewhere.

  StatusVersion 1.16.0, November 2026, adds experimental WIT-SVID support.

• WIMSE Architecture

  draft-ietf-wimse-arch
  WG draftIETFWorkload identity

  Architecture and terminology for workload identity and for propagating security context between workloads.

  For agentsIncludes a section on agents: each hop in an agent chain must explicitly scope and re-bind the security context.

  StatusRevision -08, July 2026. WIMSE working group document. No WIMSE document is an RFC yet.

• AI Identity Management System (AIMS)

  draft-ietf-wimse-aims
  WG draftIETFWorkload identityDelegationGuidance

  Defines no new protocol. Describes how existing ones compose for agents: workload identity for the agent, OAuth for authorization, transaction tokens inside a domain, identity chaining across domains.

  For agentsThe closest thing to an IETF reference architecture for agent authentication and authorization. Its opening position: agents are workloads.

  StatusRevision -01, November 2026. Informational. Adopted by WIMSE in September 2026; previously the individual draft draft-klrc-aiagent-auth.

• WIMSE Workload Credentials

  draft-ietf-wimse-workload-creds
  WG draftIETFWorkload identityProof of possession

  Defines the Workload Identity Token (a key-bound JWT) and the Workload Identity Certificate.

  For agentsA workload identity that can pass through proxies without becoming a bearer token.

  StatusRevision -03, October 2026. One of four documents that replaced the earlier service-to-service protocol draft.

• Workload Proof Token

  draft-ietf-wimse-wpt
  WG draftIETFWorkload identityProof of possession

  A short-lived signed JWT that proves possession of the key in a Workload Identity Token and binds to one request.

  For agentsThe workload equivalent of a DPoP proof.

  StatusRevision -02, August 2026.

• WIMSE HTTP Signatures

  draft-ietf-wimse-http-signature
  WG draftIETFWorkload identityProof of possession

  Workload-to-workload authentication using HTTP Message Signatures with the Workload Identity Token key. Responses can be signed too.

  For agentsEnd-to-end caller authentication through TLS-terminating gateways.

  StatusRevision -08, October 2026. Reported as submitted to the IESG for publication.

• Workload Identity Practices

  draft-ietf-wimse-workload-identity-practices
  WG draftIETFWorkload identityGuidanceKubernetes

  A survey of how credentials reach workloads today without long-lived secrets: Kubernetes projected tokens, cloud metadata services, SPIFFE, CI/CD OIDC.

  For agentsA vendor-neutral description of the patterns on the deployments pages of this site.

  StatusRevision -08, October 2026. Informational. Reported to be in IETF Last Call in November 2026, which would make it the first WIMSE RFC.

• Bound ServiceAccount Tokens

  Kubernetes TokenRequest API
  Final specKubernetesKubernetesWorkload identity

  Short-lived, audience-scoped JWTs bound to a specific pod and delivered by the kubelet through a projected volume. The cluster publishes OIDC discovery metadata so outsiders can verify them.

  For agentsEvery pod already has a signed identity document. Workload identity federation turns it into access elsewhere, with no long-lived secret to provision for the pod.

  StatusTokenRequest and projected tokens: GA since v1.20. Token ID and pod/node claims: GA in v1.32. OIDC issuer discovery: GA since v1.21. External token signing: GA in v1.36.

• Pod Certificates

  Kubernetes KEP-4317
  Final specKubernetesKubernetesWorkload identityProof of possession

  The kubelet generates a key, requests a certificate for the pod from a named signer, writes it into a projected volume and rotates it.

  For agentsNative X.509 identity for every pod with no sidecar or node agent: the building block for mutual TLS between agents and tools.

  StatusGA in v1.37 (August 2026) in certificates.k8s.io/v1. No signer ships with Kubernetes; you install one.

• ClusterTrustBundle

  Kubernetes KEP-3257
  Final specKubernetesKubernetesWorkload identity

  A cluster-scoped object holding X.509 trust anchors, mountable into pods through a projected volume.

  For agentsThe trust-distribution half of Pod Certificates.

  StatusGA in v1.37 (August 2026).

• Structured Authentication Configuration

  Kubernetes KEP-3331
  Final specKubernetesKubernetes

  A configuration file for the API server that accepts multiple JWT issuers with CEL-based claim validation and mapping.

  For agentsHow tokens from an external identity provider, including an agent platform’s, can authenticate to the Kubernetes API without a webhook.

  StatusGA in v1.34. Structured authorization configuration (KEP-3221) has been GA since v1.32.

• Agent Sandbox

  kubernetes-sigs/agent-sandbox
  Project / platformKubernetesKubernetes

  A SIG Apps project: a Sandbox resource for isolated, stateful, single-pod agent runtimes, with templates, claims and warm pools.

  For agentsTemplates turn off service account token mounting by default and generate a network policy that blocks cluster-internal and metadata addresses.

  StatusProject version 1.0 since August 2026; the API is still v1beta1 in the agents.x-k8s.io group. No built-in credential broker.

• Kube Agentic Networking

  kubernetes-sigs/kube-agentic-networking
  Project / platformKubernetesKubernetesFine-grained authz

  APIs for agent-to-tool and agent-to-agent traffic policy, with a reference implementation supporting tool-level MCP authorization and SPIFFE-based agent identity.

  For agentsWhere per-tool policy for agents is being worked out at the Kubernetes API level.

  StatusEarly releases (v0.x) during 2026. A SIG Network subproject.

• agentgateway

  agentgateway 1.x
  Project / platformLinux FoundationKubernetesFine-grained authzAgent protocols

  An open-source proxy for model, MCP and A2A traffic. It can act as an MCP resource server, call an external policy engine per tool call, perform token exchange and ID-JAG, and run as an egress proxy.

  For agentsA concrete place to enforce much of what this site describes without changing agent code.

  StatusVersion 1.7 in October 2026. A Linux Foundation project, reported to have joined the Agentic AI Foundation in June 2026.

• AWS IAM Roles

  IAM User Guide
  Project / platformAWSWorkload identity

  An AWS identity with permissions and no long-term credentials of its own. Whoever assumes a role receives temporary security credentials for that session. Compute services such as Lambda and EC2 assume a role attached to the function or instance and supply its credentials to the code.

  For agentsNative workload identity on AWS: an agent running there calls AWS APIs without an access key being provisioned for it. Using a role inside AWS is not federation.

  StatusPlatform documentation. Each compute service documents how it delivers a role’s credentials to code.

• AWS OIDC Federation

  IAM OIDC identity providers
  Project / platformAWSWorkload identity

  An IAM OIDC identity provider registers an outside issuer with an AWS account. A workload holding a JWT from that issuer exchanges it for temporary security credentials that map to an IAM role.

  For agentsThe way into AWS for CI jobs, Kubernetes pods and workloads on other clouds. The conditions the trust policy puts on audience and subject are the security boundary.

  StatusPlatform documentation. The role’s trust policy decides which tokens from the issuer are accepted.

• AWS Web Identity Exchange

  STS AssumeRoleWithWebIdentity
  Project / platformAWSWorkload identity

  The Security Token Service operation that takes a web identity token and a role, and returns an access key ID, a secret access key and a session token. The call itself is not signed with AWS credentials.

  For agentsWhat comes back signs AWS API requests. It is not an OAuth bearer access token, which matters to any agent framework that expects one.

  StatusAPI reference. Sessions last one hour by default, and from 15 minutes up to the maximum set on the role.

• AWS Outbound Identity Federation

  STS GetWebIdentityToken
  Project / platformAWSWorkload identity

  AWS as the identity provider. A workload that already has AWS credentials calls GetWebIdentityToken for a short-lived signed JWT naming its IAM principal, for an audience it specifies. Outside services verify the token against keys published under an issuer URL specific to the account.

  For agentsLets an agent on AWS prove its identity to a service outside AWS, where the token is exchanged for that service’s own credential.

  StatusHas to be enabled for the account before a token can be requested. Not available on the STS global endpoint.

• Google Cloud Workload Identity Federation

  Google Cloud IAM
  Project / platformGoogle CloudWorkload identity

  Workloads outside Google Cloud present a credential from their own identity provider to Google’s Security Token Service, which returns a federated access token. A workload identity pool provider holds the trust in the outside issuer and the conditions on its attributes.

  For agentsThe way into Google Cloud without a service account key, from AWS, Azure, GitHub, GitLab, Kubernetes clusters, or any OIDC or SAML 2.0 identity provider.

  StatusPlatform documentation. The token exchange follows RFC 8693.

• Google Cloud Federation with X.509 Certificates

  Google Cloud IAM
  Project / platformGoogle CloudWorkload identity

  Workload Identity Federation with a client certificate in place of a token. An administrator registers certificate authorities as trust anchors, and a workload holding a certificate that chains to one obtains short-lived Google Cloud credentials over a mutual TLS connection.

  For agentsFederation without a JWT or OIDC discovery. Trust rests on a certificate chain, and the workload has to hold the private key, not only a copy of the certificate.

  StatusPlatform documentation. The workload authenticates over mutual TLS with a certificate that chains to a registered trust anchor.

• Authentication on Google Cloud

  Google Cloud authentication
  Project / platformGoogle CloudWorkload identity

  How code gets credentials on Google Cloud. A service account attached to the resource is the workload’s identity, and client libraries find its credentials through Application Default Credentials, which asks the metadata server.

  For agentsNative workload identity on Google Cloud. Google recommends it for code running there, and Workload Identity Federation for code running on-premises or on another cloud.

  StatusPlatform documentation.

• Microsoft Entra Workload Identity Federation

  Microsoft Entra Workload ID
  Project / platformMicrosoftWorkload identity

  An app registration or a user-assigned managed identity is configured, through a federated identity credential, to trust tokens from an outside issuer. The workload sends that token as the client assertion on a client credentials request and receives a Microsoft Entra access token.

  For agentsThe way into Microsoft Entra without a client secret or certificate, from Kubernetes, GitHub Actions, Google Cloud, AWS or SPIFFE.

  StatusPlatform documentation. The issuer, subject and audience of the incoming token must match the configured values exactly; wildcards are not supported.

• Azure Managed Identities

  Managed identities for Azure resources
  Project / platformMicrosoftWorkload identity

  An identity in Microsoft Entra that Azure creates for a resource, or that you create and assign to one. Code on the resource asks a local endpoint for Microsoft Entra tokens. Azure manages the underlying credentials, which you never handle.

  For agentsNative workload identity on Azure. A user-assigned managed identity can also be what federation from outside maps onto.

  StatusPlatform documentation.

• OpenID Connect in GitHub Actions

  GitHub Actions OIDC
  Project / platformGitHubWorkload identity

  GitHub’s OIDC provider issues a job a signed JWT whose claims name the repository, the branch or environment, and the workflow. A cloud or other service that trusts the issuer exchanges it for short-lived access.

  For agentsThe identity of an agent that runs in a CI job. One issuer serves every repository on GitHub.com, so the receiving trust rule has to name the repository.

  StatusPlatform documentation. A job needs the id-token: write permission to request its token.

• MCP Authorization

  MCP specification 2026-07-28
  Final specMCPAgent protocolsDiscoveryCore OAuth

  A profile of OAuth 2.1 for HTTP transports. The MCP server is a resource server, discovered through protected resource metadata; clients identify themselves with Client ID Metadata Documents; tokens are bound to one server.

  For agentsThe most widely implemented authorization profile written specifically for agents and tools.

  StatusCurrent revision 2026-07-28. It requires OAuth 2.1, citing draft -13, and recommends Client ID Metadata Documents, citing draft -00. Earlier revisions: 2025-03-26, 2025-06-18, 2025-11-25. The next release is planned for March 2027. MCP is a Linux Foundation project hosted by the Agentic AI Foundation.

• MCP Enterprise-Managed Authorization

  io.modelcontextprotocol/enterprise-managed-authorization
  Final specMCPAgent protocolsDelegation

  An MCP client exchanges the user’s single sign-on token at the enterprise identity provider for an ID-JAG, then redeems it at the MCP server’s authorization server.

  For agentsCentral, administrator-controlled access for workforce agents, with no per-server consent prompts.

  StatusOfficial extension, stable at revision 2026-07-28. An application of ID-JAG.

• MCP OAuth Client Credentials

  io.modelcontextprotocol/oauth-client-credentials
  Final specMCPAgent protocolsWorkload identity

  Machine-to-machine access to MCP servers with pre-registered clients. A signed JWT assertion is the recommended way to authenticate.

  For agentsThe sanctioned path for agents with no human present.

  StatusOfficial extension, stable at revision 2026-07-28.

• MCP URL-Mode Elicitation

  MCP specification 2026-07-28, Elicitation
  Final specMCPAgent protocolsHuman in the loop

  A server asks the client to send the user to a URL for an interaction that must not pass through the client: third-party sign-in, entering a secret, a payment.

  For agentsKeeps downstream credentials out of the agent and the model.

  StatusIntroduced in 2025-11-25 and reworked in 2026-07-28. Still marked as subject to change.

• Agent2Agent (A2A) Protocol

  A2A 1.0
  Final specLinux FoundationAgent protocolsDiscovery

  Agents publish an Agent Card declaring their skills and security schemes (API key, HTTP, OAuth 2.0, OpenID Connect, mutual TLS). Cards can be signed. A task state signals that further authorization is needed.

  For agentsDefines how requirements are declared between agents, and leaves obtaining credentials to OAuth and its relatives.

  StatusVersion 1.0.0 released March 2026; 1.0.1 in May 2026. A Linux Foundation project, reported to have joined the Agentic AI Foundation in August 2026.

• Web Bot Auth

  draft-ietf-webbotauth-httpsig-protocol
  WG draftIETFAgent protocolsProof of possession

  Automated clients sign requests with HTTP Message Signatures and point to a published key directory with a Signature-Agent header.

  For agentsThe one IETF mechanism for an agent to prove to an arbitrary website which operator it belongs to. Identification only.

  StatusRevision -01, October 2026. The working group’s only adopted document; it merges the earlier architecture and key directory drafts.

• SCIM Agent Resource

  draft-wzdk-scim-agent-resource
  Individual draftIETFAgent protocolsGuidance

  A SCIM resource type for agents, so identity systems can create, update and remove agent identities across applications.

  For agentsThe lifecycle half that OAuth does not cover: provisioning an agent and, more importantly, deprovisioning it.

  StatusRevision -00, June 2026. Individual draft that consolidates two earlier vendor proposals. Not adopted.

• AGNTCY Identity

  AGNTCY Identity
  Project / platformLinux FoundationAgent protocolsVerifiable credentials

  Identities for agents and MCP servers backed by verifiable credentials, with a resolver for verification.

  For agentsOne of several attempts at portable agent identity outside a single identity provider.

  StatusLinux Foundation project; APIs are alpha.

• AuthZEN Authorization API

  OpenID AuthZEN Authorization API 1.0
  Final specOpenID FoundationFine-grained authz

  A standard interface between a policy enforcement point and a policy decision point: subject, action, resource, context in; decision out.

  For agentsLets a gateway or MCP server ask any policy engine “may this agent call this tool with these arguments for this user?”

  StatusFinal specification, approved January 2026.

• COAZ Binding for MCP

  OpenID AuthZEN COAZ-MCP
  WG draftOpenID FoundationFine-grained authzAgent protocols

  Maps MCP requests to AuthZEN authorization requests for parameter-level decisions, with mappings declared per tool.

  For agentsAddresses the gap MCP itself leaves open: there is no per-tool permission model in the core specification.

  StatusDraft 1, announced June 2026 with the protocol-neutral COAZ framework. Supersedes the earlier “AuthZEN profile for MCP.”

• Shared Signals Framework, CAEP, RISC

  OpenID SSF 1.0 · CAEP 1.0 · RISC 1.0
  Final specOpenID FoundationSignals & revocation

  A framework for pushing security events between systems: session revoked, credential changed, device non-compliant.

  For agentsThe mechanism for telling everything an agent has touched that its access just ended, without waiting for tokens to expire.

  StatusAll three reported final in September 2025.

• SD-JWT

  RFC 9901
  RFCIETFVerifiable credentials

  Selective Disclosure for JWTs: a signed credential whose holder can reveal only chosen claims, with key binding.

  For agentsThe format behind payment mandates and delegated credentials in agent commerce.

  StatusNovember 2025. The companion SD-JWT VC draft is reported to be in IESG evaluation.

• OpenID for Verifiable Presentations

  OpenID4VP 1.0
  Final specOpenID FoundationVerifiable credentials

  A protocol for requesting and presenting verifiable credentials.

  For agentsHow an agent, or a user on its behalf, presents a signed mandate to a verifier.

  StatusReported final in July 2025. The issuance counterpart, OpenID4VCI 1.0, followed in September 2025.

• Verifiable Credentials Data Model

  W3C VC Data Model 2.0
  Final specW3CVerifiable credentials

  A data model for cryptographically verifiable claims made by an issuer about a subject.

  For agentsUnderlies agent identity proposals that do not assume a shared identity provider.

  StatusW3C Recommendation, May 2025. Decentralized Identifiers 1.1 is at Candidate Recommendation.

• Agent Payments Protocol (AP2)

  AP2 v0.2
  Individual draftFIDO AllianceCommerceVerifiable credentials

  Signed mandates express what a user has authorized an agent to buy. Checkout and payment mandates, each open (constraints for autonomous use) or closed (one purchase), as SD-JWTs.

  For agentsThe most detailed open attempt at verifiable user intent for agent purchases.

  StatusVersion 0.2.0, April 2026. Created by Google and donated to the FIDO Alliance the same month; no FIDO-published draft yet.

• Verifiable Intent

  Verifiable Intent draft v0.1
  Individual draftFIDO AllianceCommerceVerifiable credentials

  A layered SD-JWT delegation chain from credential provider to user to agent, with constraints on amount, payee and items.

  For agentsA card network’s take on the same problem AP2 addresses.

  StatusDraft 0.1, maintained by Mastercard and contributed to the FIDO Alliance alongside AP2.

• Agentic Commerce Protocol

  ACP 2026-04-17
  Individual draftVendor-ledCommerce

  A checkout protocol between agents and merchants. A delegated payment token lets the merchant’s processor charge within explicit allowance limits.

  For agentsPayment delegation by scoped token instead of signed mandate.

  StatusBeta, date-versioned; latest stable 2026-04-17. Maintained by OpenAI and Stripe.

• Trusted Agent Protocol

  Visa Trusted Agent Protocol
  Individual draftVendor-ledCommerceProof of possession

  Agents sign each request with HTTP Message Signatures, bound to the merchant and to whether they are browsing or paying.

  For agentsWeb Bot Auth extended with commerce context.

  StatusPublished by Visa with a sample implementation. Not under a standards body.

• x402

  x402 protocol version 2
  Project / platformLinux FoundationCommerce

  Revives HTTP status 402: a server states its price, and the client retries with a signed payment.

  For agentsPayment as the credential. No identity layer; suited to pay-per-call access by autonomous agents.

  StatusProtocol version 2. Moved to an x402 Foundation under the Linux Foundation in 2026.

• FAPI 2.0 Security Profile

  OpenID FAPI 2.0
  Final specOpenID FoundationGuidanceCore OAuth

  A high-security OAuth profile: pushed authorization requests, sender-constrained tokens, strong client authentication.

  For agentsA ready-made answer to “what should a high-stakes agent integration require?”

  StatusReported final in February 2025.

• Identity Management for Agentic AI

  OpenID Foundation whitepaper
  GuidanceOpenID FoundationGuidance

  A survey of how current identity standards apply to agents and where they fall short.

  For agentsA good map of the problem space from the people who maintain the standards.

  StatusOctober 2025, from the AI Identity Management Community Group.

• Software and AI Agent Identity and Authorization

  NIST NCCoE concept paper
  GuidanceNISTGuidance

  Proposes a demonstration project applying existing identity standards to enterprise agents.

  For agentsSignals which standards a US government reference architecture is likely to draw on: MCP, OAuth, OpenID Connect, SPIFFE, SCIM.

  StatusDraft concept paper, February 2026. NIST also launched an AI Agent Standards Initiative the same month.

• OWASP Top 10 for Agentic Applications

  OWASP Agentic Top 10 (2026)
  GuidanceOWASPGuidance

  The ten most significant risks in agentic systems. Identity and privilege abuse is one of them.

  For agentsA threat checklist to review any design on this site against.

  StatusReleased December 2025. An OWASP MCP Top 10 is in beta.

• OWASP Non-Human Identities Top 10

  OWASP NHI Top 10 (2025)
  GuidanceOWASPGuidanceWorkload identity

  The common failures with service accounts, keys and tokens: long-lived secrets, over-privilege, improper offboarding, reuse.

  For agentsEvery agent is a non-human identity. Most real incidents are on this list.

  Status2025.

• Agentic Identity and Access Management

  CoSAI workstream 4 paper
  GuidanceOASISGuidance

  Treats agents as a distinct identity class and recommends zero standing privilege and delegation tokens with explicit actor and subject.

  For agentsIndustry consensus guidance that lines up closely with the IETF agent architecture draft.

  StatusVersion 1.0, spring 2026, from the Coalition for Secure AI.

Nothing matches those filters. Clear them.