There is no single 'agent identity standard.' There are three layers — an identifier, credentials, and authorization — each already standardized separately. Portable agent identity is an assembly job, and the research has converged on what binds the top layer.
An agent is mid-task. It has found a second agent, run by another company, that can do the next step — settle a payment, pull a record, run an analysis — and it is about to hand that step over. Before it does, it needs an answer to one question, and the question has no single owner: who is this counterparty, and on what basis should anything it says be believed? The first agent cannot phone a human. It cannot fall back on a shared login system, because the two agents have no shared anything. It has to resolve identity itself, at runtime, from cryptographic material — and “identity,” at that moment, turns out not to be one fact but three.
That is the live problem agent identity has to solve, and a team that goes looking for “the agent identity standard” to solve it comes back holding four specifications, none of which is the one and none of which is wrong. The reason is not that the field is immature or disorganized. It is that the four specifications do four different things, at three different layers, and the job in front of the team was never to pick a winner. It was to assemble.
That is the actual state of agent identity in 2026, and it is a better state than “pick one” makes it sound. The layers an agent identity needs are each already standardized — separately, by different bodies, at different levels of maturity — and they are designed to compose. This essay is the assembly guide: the three layers, the standard that does each, why the order matters, and the part the research has genuinely converged on. The on-chain identity registry itself — ERC-8004’s mechanics — is the subject of the ERC-8004 essay; here it is one component slotted into a larger stack.
The reason “the agent identity standard” sounds like it should exist, and does not, is that the word “identity” hides three separate questions inside one noun. A human rarely has to pull them apart, because a passport, a driver’s licence, and a building pass arrive pre-bundled and a person carries all three without thinking about it. An agent has no such bundle. Each question has to be answered by a distinct mechanism, and conflating them produces a system that looks complete and is not.
layer 3 AUTHORIZATION what may this agent do, right now, on my behalf?
└─ signed, attenuated capability tokens
layer 2 CREDENTIALS what is verifiably true about this agent?
└─ W3C Verifiable Credentials
layer 1 IDENTIFIER who is this agent — a name nobody can forge or revoke?
└─ W3C Decentralized Identifiers (DIDs)The three are ordered, not merely listed, and the order is a dependency chain. Layer two is meaningless without layer one: a claim that “this agent is certified for X” has to be a claim about something, and that something is the layer-one identifier — without it the claim has no subject. Layer three is meaningless without layer two: a grant of authority is extended on the strength of what is known to be true about the recipient, and what is known to be true is the layer-two credential set. Build the stack bottom-up and each layer has the ground beneath it that it needs. Build one layer, call it identity, and ship: you have shipped a third of an identity and the two-thirds you skipped are the two-thirds that an untrusting counterparty actually interrogates.
The base layer is a name for the agent that no central directory owns and that no single party can forge or revoke. That is exactly what a W3C Decentralized Identifier provides, and the word doing the work in that sentence is decentralized. A conventional identifier — a username, an account number, an email address — is a row in some company’s database, and it exists only as long as that company keeps the row, stays online, and chooses not to delete it. Point two agents from two organizations at conventional identifiers and they cannot recognize each other at all, because neither one’s directory is authoritative for the other.
DID Core reached W3C Recommendation status in 2022 — a finished standard, not a draft — and defines three things that the layer needs. The identifier syntax itself: a string, prefixed by a method, that resolves without a central registry. The DID document: a small record, fetched by resolving the identifier, that lists the agent’s public keys and the verification methods that go with them, so a counterparty can check a signature against a key it knows belongs to that identifier. And a set of verification relationships — including, importantly for agents, an explicit delegation relationship, which is the standard’s own hook for “this key may act on behalf of this identity.” Resolution is registry-independent: it does not depend on one company’s user database staying up, which is the single property that lets two agents that share no infrastructure establish that they are talking to a stable, non-forgeable counterparty rather than an identifier minted thirty seconds ago for this conversation.
What a DID does not do is the point of the layers above it. It answers “who,” and only “who.” It asserts nothing is true about the agent — a DID for a fraudulent agent is just as well-formed as a DID for an honest one — and it grants the agent permission to do precisely nothing. It is the subject that the next two layers attach to, and on its own it is a name and not yet a reason to trust.
The second layer is the set of claims that are verifiably true about the agent: who operates it, what it has been certified or permitted for, what reputation it has accumulated, what its operator has audited it against. That is the job of W3C Verifiable Credentials, whose Data Model reached Recommendation as version 2.0 in May 2025.
A verifiable credential is a tamper-evident, cryptographically checkable claim issued by an identifiable issuer, and the standard defines three roles that make the trust transferable. The issuer asserts a claim and signs it. The holder — here, the agent — carries the credential and presents it. The verifier — here, the counterparty agent — checks the signature and decides whether the issuer is one it trusts. The mechanism’s value is that it moves a trust decision off the holder and onto the issuer: a counterparty does not have to trust the agent’s self-description, it has to trust whoever signed the credential, and that is a much smaller and more tractable trust decision. An agent claiming “I am authorized to transact for Acme Corp” is noise; a credential signed by Acme Corp’s issuing key, binding that claim to the agent’s layer-one DID, is something a verifier can act on.
The version is worth pinning, because the older 1.1 model is still widely cited and the difference is not cosmetic: cite VC 2.0, the current Recommendation. A credential answers “what is verifiably true about this agent,” and it binds those claims to the layer-one identifier, which is why layer one had to come first. And — the recurring pattern of this stack — it still does not grant the agent permission to act. Knowing an agent is certified, audited, and operated by a reputable party tells a counterparty the agent is trustworthy. It does not tell the counterparty what this particular agent may do, on whose behalf, in this particular interaction. That is a separate question, and it is the top layer.
The top layer is the one the other two are building toward, and the one most teams under-design — because it is tempting, having established who an agent is and that it is trustworthy, to simply hand it a long-lived credential and let it act. That instinct produces the standing bearer token: a secret that means “the holder may do these things,” indefinitely, until someone revokes it. It is the single most over-permissioned, longest-lived, most replayable artifact a team can put into an agent system, and it is the wrong shape for the question the layer has to answer. The question is not who the agent is or what is broadly true about it. It is what this agent is allowed to do, on whose behalf, right now — and “right now” and “on whose behalf” are the parts a bearer token throws away.
The primitive that answers it correctly is the capability token, and the standard closest to ratified is UCAN — User Controlled Authorization Networks, currently a 1.0 release candidate. UCAN gets three things right that a bearer token gets wrong. Its principals are DIDs, so it sits directly on layer one and inherits a non-forgeable notion of who is involved. It delegates authority through cryptographic proof chains rather than through a central permission server, so an agent can pass authority onward without a round-trip to an authority that has to be online. And it enforces a rule that is the heart of the design: every delegation must restate or attenuate the capability — narrow it — and may never escalate it. That rule is what makes “share authority without sharing keys” real: an agent holding broad authority can hand a sub-agent a strictly narrower slice of it — this action, this resource, this window — and the sub-agent provably cannot widen what it received, because the proof chain it would have to present does not exist. A leaked sub-agent token is a leak of a sliver, not of the whole.
On-chain, ERC-8004’s Identity, Reputation, and Validation registries give this same stack a censorship-resistant home and a place to anchor reputation that no single operator can quietly edit; its mechanics are the ERC-8004 essay’s subject. The layer-three point stands regardless of where the registry lives: authorization is a scoped, short-lived, delegable capability, not a standing grant.
Ask not just “what is the authorization layer” but “what should a capability token specifically contain,” and a cluster of recent work answers with one shape: signed, attenuated, invocation-bound capability tokens. Invocation-bound is the term to hold onto. It means the token carries three things at once — the holder’s identity, a strictly-scoped grant of authority, and a binding to the specific call the token is being used for — so that a token captured in transit cannot be replayed against a different action. A plain capability token still answers “may the holder do X”; an invocation-bound one answers “may the holder do X, as this exact request, once.” The binding closes the replay gap that scope alone leaves open.
The AIP work (arXiv 2603.24775, a preprint) proposes exactly this for delegation across MCP and A2A, fusing identity, attenuated authorization, and provenance binding into one token. LDP (arXiv 2603.08852) and the interoperable-delegation work (arXiv 2601.14982) reach compatible designs from different starting points — which is the part worth noticing, because independent groups converging on the same structure is a stronger signal than any one group asserting it. Treat these as an emerging convergence rather than settled consensus; they are early-stage preprints, and a preprint is a proposal, not a ratified fact. But the convergence is real, and the peer-reviewed anchor beneath it is the agent-interoperability survey (arXiv 2505.02279), which documents A2A already using capability-based Agent Cards and ANP already building on W3C DIDs — so the lower layers of this stack are not speculative, they are deployed. The direction is not in doubt: the authorization layer is a signed, invocation-bound capability token, and a stack that ships a bare bearer token instead has shipped the layer’s weakest possible version and called it done.
The thesis “the standards already exist” is only defensible if the maturity of each one is stated precisely, because the four layers are nowhere near equally finished, and a team that treats them as uniformly solid will build on ground that is still setting:
The honest framing for a team is layered, like the stack itself. The lower two layers are solid ground. The authorization layer is ground that is firming up fast but is not yet poured. “Assembled from existing standards” is a true description of agent identity in 2026 — as long as the team does not mistake a release candidate for a final spec, or an emerging convergence for a settled one, and tracks the drafts it depends on as the moving things they still are.
Stop hunting for the one standard that does not exist. Assemble the three that do — an identifier, a credential, a capability token — and the agent identity you needed was waiting to be built, not found.
Our taxonomy argued prompt injection is a vulnerability class you contain, not a bug you fix. Here is the quantitative half — against the strongest published defenses, indirect-injection attack success stays high, and for agents that can act it stays alarming.
10 min →
A quality-ascending curriculum beats random shuffling — until a decaying schedule delivers your best data exactly when the learning rate is too small to absorb it. The same coupling flips proxy-model ablations: which dataset wins depends on the schedule, not the data alone.
13 min →
An agent workflow that pauses for human approval and then resumes looks safe — a person clicked approve. But the approval decision and the authority the resumed step runs under are two different objects, and most systems conflate them by carrying the approval as an in-band signal the resumed call trusts. That is a confused-deputy bug: a forged resume, a replayed request, or an approval granted at one gate authorizes an action it was never meant to. The fix is to stop transporting approval and start deriving authority from the trusted approval record at resume time, scoped to the exact suspended step — capabilities enforced at the tool boundary, fail-closed by default.
14 min →