Agent identity comes in three shapes today, and the choice between them is really a choice about who can check an agent's identity. Some live inside one organization's directory, some are issued by a provider any app can verify, and some are registration protocols an app publishes on its own domain. This post explains what each shape is good for, what it can't answer, and where standards stand.
There is no single decentralized standard for AI agent identity yet; instead, three shapes are in use, and each decides differently who can verify an agent. Directory-bound identity lives in one organization's tenant, provider-issued identity comes from an issuer any app can verify with OpenID Connect, and registration protocols let each app publish how agents may sign up with it.
The words "centralized" and "decentralized" get used loosely here, and they hide the question that matters in practice. When an agent shows up somewhere, who is able to confirm what it is, and who can turn it off? A company securing its own agents and a public app receiving agents from strangers want different answers to that. Looking at the three shapes side by side makes it easier to pick the one that fits, and to see why an agent might reasonably carry more than one.
What are the three shapes of agent identity?
The three shapes are directory-bound, provider-issued and registration-protocol identity, and they differ mainly in where the identity is recorded and who can check it. The comparison of AI agent authentication platforms goes vendor by vendor; this post stays on the shapes.
| Shape | Who issues it | Who can verify it | What revocation means | Examples |
|---|---|---|---|---|
| Directory-bound | The organization's identity directory | Systems connected to that directory | A lifecycle decision made in the directory | Microsoft Entra Agent ID, Okta Agent SSO |
| Provider-issued | An identity provider outside the app | Any app, through OpenID Connect discovery and published keys | The provider stops new sign-ins; each app ends its own sessions | AgentID |
| Registration protocol | The app itself, after the agent registers | The app that issued the credential | A short-lived, revocable credential tied to the user | WorkOS auth.md |
None of these is the "decentralized" one in a pure sense. Each has an authority somewhere; what differs is whether that authority is one company's directory, a shared issuer, or each app on its own.
What does a directory-bound identity answer?
A directory-bound identity answers who an agent is inside the organization that runs it. Microsoft describes an Entra agent identity as "the primary identity an AI agent uses to authenticate to systems and access resources", and Entra records accountability in the same place: "Sponsors provide business accountability for agents, making lifecycle decisions without technical administrative access." Non-Microsoft agents can take part through a sidecar SDK or workload identity federation.
Okta takes the same shape for the workforce. Its Agent SSO registers agents "as a first-class identity in Universal Directory alongside human employees" and issues "short-lived, identity-governed tokens in place of stored credentials", for agents that support Cross App Access. This shape is the natural fit for internal agents in a company that already runs one of these directories. Its reach is the directory's reach, so it is less suited to an agent signing up at a public app that shares no directory with the agent's company.
What does a provider-issued identity answer?
A provider-issued identity answers who an agent is to any app that trusts the issuer, the same way Sign in with Google works for people. The app doesn't need a relationship with the agent's organization. It reads the issuer's discovery document, checks the token against published keys, and gets a stable subject.
AgentID, our sign-in for AI agents, takes this shape. Every subject it issues is an agent, marked as one in the token, and registered apps can also receive the email of the human who owns the agent. Revocation is per key: deleting an agent's key stops new sign-ins everywhere, while each app decides when its own session ends. How an AI agent proves its identity with AgentID walks through the token.
Where does a registration protocol fit?
A registration protocol fits at the app's front door rather than at an issuer. WorkOS describes auth.md as "a Markdown file an application hosts at its domain, typically https://yourapp.com/auth.md, that tells agents how to register on behalf of a user." It supports two flows. In the agent verified flow, "the agent's identity provider vouches for the user, no human in the loop." In the user claimed flow, "the agent shows the user a code, they sign in and confirm it."
What the app issues is "a scoped access token tied to the user, short-lived and revocable", and WorkOS notes there is "no WorkOS account required." The agent is a delegate and the human is the account. That makes it composable with the other shapes rather than a rival to them: the agent verified flow needs an identity provider to vouch, and a provider-issued identity could fill that role.
Is there a standard for agent identity yet?
There is no single standard for agent identity yet, but the provider-issued shape already runs on one: OpenID Connect, the same protocol behind human sign-in. That is also the answer for anyone asking whether one identity scheme can cover humans and agents alike. It can, as long as the token says which kind of subject it names, which is what a claim marking the subject as an agent is for.
Proposals for agent-specific protocols exist. One example is an individual IETF Internet-Draft on an agent identity protocol, which expired in September 2026 without becoming a standard. Until something like that matures, the practical approach is the one this post describes: pick the shape that matches who needs to verify your agents, and expect a real agent to carry more than one. What is an agent ID explains the parts every one of these shapes has in common.
Sources
AgentMail gives your agents real inboxes. Create inboxes via API. Send and receive Emails with 0 complexity. Free to start.
