Credential approaches to agent identity compared side by side.

Agent identity: approaches compared

There is no single “agent identity standard”. What exists is a set of approaches, each with a different trust anchor, a different story for revocation and delegation, and a different level of maturity. This page compares them neutrally so you can choose consciously rather than by vendor default.

Read it alongside How to verify an agent and the standards & regulation tracker. Use What is KYA? for the underlying framework: identity, principal, authority, evidence, lifecycle.

What “agent identity” has to deliver

Any approach worth adopting should answer five questions for a given agent, per the KYA framework:

  1. Identity — a verifiable identifier that cannot be trivially spoofed.
  2. Principal binding — which human or organisation is accountable.
  3. Delegation — on whose authority it acts, and how sub-delegation narrows.
  4. Revocation — how authority is withdrawn, and how fast.
  5. Evidence — what a relying party can check, and whether a record survives.

Different approaches answer these to different depths. A trust anchor is only as good as its weakest operational detail: a strong cryptography layer with a slow revocation path can be worse in practice than a modest one that fails fast.

The comparison

ApproachTrust anchorRevocationDelegationMaturityBest for
OAuth 2.1 / OAuth 2.0 + Token ExchangeThe authorization server (an IdP you or a partner trust)Short-lived tokens; RFC 7009 revocation; RFC 7662 introspectionNative: “on behalf of” roles; RFC 8693 token exchange distinguishes delegation vs impersonation; RFC 9396 rich authorization requestsVery mature (RFC 6749, 8693, 9396; OAuth 2.1 consolidating)Agents acting for a user or service inside an existing OAuth/IdP estate
SPIFFE / SPIRETrust domain root of trust; attested workload identityShort-lived SVIDs, rotated automatically (revocation largely by expiry)Via issued identity; delegation modelled by trust domains and selectorsMature, CNCF project; used in productionService-to-service and agent identity inside a trust domain
IETF WIMSEWorkload identity across systems; being standardisedIntended: short-lived credentials and defined lifecycle (work in progress)First-class: agents framed as delegated workloads; delegation chains in scopeEmerging (working-group drafts; one adopted 2026)Organisations that want a standards-track, cross-system workload/agent identity model
mTLS (mutual TLS)Certificate authorityCRL / OCSP, or short-lived certsImplicit in what the client cert represents; no native delegation semanticsVery matureStrong channel identity between services; a basis for certificate-bound tokens
X.509 certificatesCertificate authority / PKI hierarchyCRL / OCSP; short-lived certsProfile-dependent; agent-specific extensions are draft, not standardVery mature as PKI; agent profiles emerging (IETF drafts)Environments already built on PKI; offline verification of an agent profile
Verifiable credentials / SD-JWT VCIssuer of the credential, verified against published keys (W3C VC 2.0)Status lists / revocation registries; short expiryCredentials can encode delegation and scope; selective disclosure via SD-JWTMaturing (W3C VC 2.0 is a Recommendation, 2025; SD-JWT VC in IETF)Portable, cross-organisation agent credentials and mandate-style proofs
DIDs (Decentralised Identifiers)The DID method (often a distributed ledger) and its resolversMethod-dependent; some methods have weak or inconsistent revocationEncode relationships and delegation in the documentVariable by method; several methods stable, many experimentalDecentralised settings where no single issuer is trusted; niche for enterprise agents
MCP authorizationThe MCP server’s OAuth 2.1 authorization serverInherits OAuth: short-lived access tokens, refresh handlingMCP server acts as resource server, client as OAuth client acting for a resource ownerMaturing (2026-07-28 spec is the current revision)Tool-using agents calling protected MCP servers
Web Bot AuthSigning key plus a key directory; HTTP Message Signatures (RFC 9421)Key rotation / directory update; signatures are short-livedNarrow: identifies the automated client, not a full delegation chainEmerging (working-group draft; early deployments)Telling legitimate agents from hostile bots on the open web
Commercial agent platformsThe vendor’s IdP/control planeVendor-managed token/lifecycle controlsVendor-defined; often OAuth-based under the hoodShipping now (Google Cloud Agent Identity, Microsoft Entra Agent ID, Okta, and others)Teams that want turnkey agent identity and governance inside one provider

Reading the table

A few patterns are worth stating plainly, because the choice usually comes down to them.

OAuth carries delegation; it does not by itself carry intent. OAuth 2.1 and token exchange are the mature, ubiquitous answer to “this client acts on behalf of that resource owner”. The IETF has standardised the difference between delegation and impersonation (RFC 8693), and rich authorization requests (RFC 9396) can express fine-grained scope. What OAuth alone does not give you is cryptographic proof that the principal specifically intended this action — which is precisely what payment mandates and verifiable credentials add.

SPIFFE answers “which workload is this” with short-lived, attested keys. A SPIFFE Verifiable Identity Document is designed to be “proven as authentic” and “proven to belong to the presenter”, with private keys that are “short lived, rotated frequently and automatically”. That makes revocation mostly a matter of expiry — elegant inside a trust domain, but it does not, on its own, name an external principal or a business mandate.

WIMSE is where the IETF is drawing the standards-track line. The working group’s adopted document, AI Identity Management System (`draft-ietf-wimse-aims`), proposes best practices for authenticating and authorising AI-agent interactions, and the architecture draft treats AI intermediaries as “a special case of delegated workloads”. Adoption is not ratification, but it is the most concrete sign of where the IETF expects agent identity to sit: on top of workload identity, not apart from it.

X.509 and mTLS are the boring, reliable foundation. They are decades mature and already deployed everywhere, including in certificate-bound OAuth tokens (RFC 8705). Their weakness for agents is that a certificate proves a key, not a mandate; agent-specific certificate profiles are drafts, not standards. Use them as the identity layer, and put delegation and intent above them.

Verifiable credentials are the natural container for intent and portability. The W3C Verifiable Credentials Data Model 2.0 (a Recommendation, 15 May 2025) defines issuer/holder/verifier roles and a tamper-evident data model; IETF SD-JWT VC adds selective disclosure. This is why payment mandates (AP2’s Verifiable Digital Credentials, Mastercard’s Verifiable Intent) are credential-shaped: they need to be portable across organisations, verifiable by a party that does not share your IdP, and capable of proving a bounded, specific authorisation.

DIDs are the most decentralised and the least uniform. Where there is a trusted issuer, a credential from that issuer is simpler. DIDs matter where the whole point is to avoid a central issuer — a real but narrower requirement for most enterprise agent deployments, with maturity that varies by method.

MCP authorization is the tool-calling control point. The current Model Context Protocol specification (2026-07-28) hardens authorisation around OAuth 2.1: a protected MCP server “acts as an OAuth 2.1 resource server”, an MCP client “acts as an OAuth 2.1 client, making protected resource requests on behalf of a resource owner”, and clients must use Resource Indicators (RFC 8707) to bind tokens to the intended server. For agents that act through tools, this is where least-privilege scope is practically enforced.

Web Bot Auth is narrow but useful. It answers “is this automated client the one it claims to be?” using HTTP Message Signatures (RFC 9421), without a full delegation model. It is the right tool for the front door — separating legitimate agents from hostile bots — and the wrong tool for expressing who authorised a purchase.

Commercial platforms bundle the pieces. Microsoft Entra Agent ID, Google Cloud Agent Identity and similar products give agents “purpose-built identity constructs” and lifecycle controls, and typically build on OAuth and SPIFFE underneath. The trade-off is concentration: the vendor becomes your trust anchor, so portability and cross-provider verification need to be checked explicitly.

How to choose

A few heuristics keep this tractable:

  • Start from the delegation. Ask what the agent is permitted to do for whom. That points to OAuth/token-exchange and to credentials/mandates; identity primitives follow from it.
  • Layer, don’t pick one. Most real systems combine a channel identity (mTLS/X.509 or SPIFFE), an authorisation model (OAuth 2.1), and a proof-of-intent credential (VC/mandate) for high-value actions. The layers are complements.
  • Decide the trust anchor deliberately. “Who can revoke this, and how fast?” is the question that usually decides between approaches.
  • Make revocation a first-class test. A revocation path you have never exercised is an assumption, not a control.
  • Prefer standards-track over proprietary where the lifecycle matters. Emerging standards (WIMSE, SD-JWT VC, Web Bot Auth) are not finished, but they are the ones your partners can converge on without adopting a single vendor.

FAQ

Which single approach should we adopt? None, in isolation. Mature deployments combine a strong channel identity, OAuth 2.1 for delegation, and verifiable credentials or mandates where intent must be provable. Choose a primary trust anchor and treat the rest as layers.

Is SPIFFE an agent identity standard? No. SPIFFE is a workload identity standard that several agent-identity products build on. It gives a strong, short-lived identity for a running process; it does not, by itself, name an external principal or a business mandate. Google Cloud’s Agent Identity, for example, is described as built on SPIFFE.

Are verifiable credentials and AP2 mandates the same thing? Related, not identical. AP2’s Verifiable Digital Credentials are credential-shaped mandates specific to payments (Checkout and Payment Mandates). The W3C VC data model is the general container many such credentials build on.

Do DIDs solve agent identity? They solve a different problem — decentralised identifiers without a central issuer — and their revocation and maturity vary by method. Useful in some contexts, not a general answer.

Is any of this a legal requirement yet? Not as agent identity. The EU AI Act imposes transparency (Art. 50) and record-keeping (Art. 12) duties, but not identity verification of agents. See the standards & regulation tracker for what is actually in force.

Is this legal advice? No. It is an explanation for practitioners. Take professional advice for compliance decisions.

Primary sources

Know Your Agent (KYA) explains agent identity, verification and accountability. This is an explainer, not legal or compliance advice — see our Sources & methodology. New to KYA? Start with What is Know Your Agent? and the glossary.