What Is an Agent ID?

An agent ID is the identity an AI agent uses to sign in to applications. It is a stable identifier the agent presents, backed by a credential only the agent holds, and tied to a human or organization that is accountable for it.

Two products implement the idea for different settings:

• Microsoft Entra Agent ID is built for agents that live inside an enterprise tenant.
• AgentID by AgentMail is built for agents that sign up for apps on the open web.

Both record who stands behind the agent. They differ on who gets to see that record: Entra shows it to the company running the agent, and AgentID delivers it to the app the agent signs into.

What is AI agent identity, and what should an agent ID contain?

AI agent identity is the set of facts a system can verify about an agent before it acts: who the agent is, who is accountable for it, and whether the credential it presents is its own.

The phrase "agent ID" also names identifiers for human agents in travel, insurance, and real estate. This post is about AI agents.

For an AI agent, the agent ID is the concrete form of that identity. It needs the same things a user account needs, minus the assumption that a person is typing. Four properties cover it.

1. A stable subject. The same agent must resolve to the same identifier every time it shows up. Otherwise the app cannot recognize a returning agent, apply limits to it, or revoke it.

• OpenID Connect: the sub claim.
• Entra: the object ID of the agent identity.
• SPIFFE-based systems: the SPIFFE ID in the certificate.

2. A credential the agent holds and nobody else does. Passwords fail this test because agents share them with the humans who created them.

Agent IDs use asymmetric keys instead: the agent signs, the verifier checks against a published public key, and no reusable secret crosses the wire.

• AgentID: enrolled browsers hold a non-extractable P-256 key.
• Entra: blueprints use managed identities or federated credentials.
• Google: issues X.509 certificates.

3. A verification path that does not require trusting the agent. The receiving system needs a document it can fetch from the issuer and check the signature against: a JWKS endpoint, a certificate chain, or a tenant's token signing keys.

4. An accountable party. This is the part that distinguishes an agent ID from a plain machine identity. A service account tells you which software is running. An agent ID tells you which human or organization is answerable for what it does.

Entra calls this the Sponsor: "Sponsors provide business accountability for agents, making lifecycle decisions without technical administrative access." AgentID calls it the owner and exposes it as the owner_email claim.

How does an agent ID differ from a user account or a service account?

An agent ID sits between a user account and a service account. It is machine-held like a service account and account-shaped like a user.

A user account assumes a person who can type a password, read an OTP from their phone, and click Approve. Agents can do the first, borrow the second, and fake the third.

That is how most agents authenticate today: as their owner. The app cannot tell the difference, cannot count how many agents one person runs, and cannot revoke the agent without locking out the person.

A service account assumes software running inside a perimeter you administer. It has a client ID and a secret or a workload certificate, and internal systems trust it because you configured them to.

It has no inbox, no owner an outside party can see, and no way to introduce itself to an application it has never met.

The full comparison, with a table, is in how agentic accounts differ from user accounts.

What is Microsoft Entra Agent ID?

Microsoft Entra Agent ID is "an identity and security framework that extends Microsoft Entra capabilities to AI agents." It reached general availability in April 2026.

The model has three objects:

• Agent identity blueprint. It "serves as the template and authentication foundation for one or more agent identities. The blueprint holds credentials and uses them to acquire tokens on behalf of all agent identities created from it."
• Blueprint principal. It records the blueprint's presence in a tenant.
• Agent identity. It is "the primary identity an AI agent uses to authenticate to systems and access resources," and, unlike a user, it has no credentials of its own.

An agent can additionally be given an agent's user account that pairs 1:1 with the identity. It behaves like a person for mailboxes, calendars, and Teams.

Governance runs through the tools Entra customers already have:

• Conditional Access policies written for agents.
• Entitlement management.
• Lifecycle workflows tied to the Sponsor.
• Entra ID Protection risk signals.

Non-Microsoft agents on AWS Bedrock, Google Cloud, or n8n can participate through an Auth SDK sidecar or workload identity federation.

Microsoft Entra Agent ID is available to all Entra customers. Extending the security features to agents requires Microsoft Agent 365, which is included with Microsoft 365 E7 and sold as an add-on to E5.

Entra Agent ID is for an organization that runs agents against its own Microsoft 365, Azure, and internal APIs, and wants each agent named, sponsored, policy-controlled, and disabled on schedule.

Microsoft states the boundary directly: agent identities can only be issued tokens in the tenant where they were created and cannot access resources in other tenants.

That is the right design for governance. It also means an Entra agent identity is not something a SaaS product outside the tenant can accept at its login page. If the agent signs in there some other way, the app learns nothing about who sponsors it.

What is AgentID by AgentMail?

AgentID is a standard OpenID Connect provider that lets an agent sign in to any app with its own verified email identity. The button on the login page is "Sign in with AgentID," in the same position as Sign in with Google.

An app adds it as a custom OIDC provider in Clerk, Supabase, Auth0, Better Auth, or Auth.js with two values:

• Issuer: https://auth.agentid.com
• Client ID: a client_id

Every sign-in returns an ES256-signed id_token with two identity claims:

• sub: a stable subject derived from the agent's inbox.
• email: the inbox address itself, verified live when the token is minted.

The agent's identity is an email address, which is why it already works at almost every app. The app can send it a confirmation, a receipt, or a support reply, and the agent can read them.

Registered clients can request the owner_email scope and read the accountable human's address from the /userinfo endpoint. Those owner claims are held on the grant and never placed in the id_token, so they do not leak into logs.

A sign-in that requests owner_email from an agent whose credential does not permit disclosure fails with a 403. It does not return a token with the claim quietly missing.

The agent side is a one-time browser enrollment:

1. The agent posts an AgentMail API key.
2. The browser generates a keypair.
3. From then on, the agent signs in from that browser on its own.

Each sign-in is a fresh signature over a server-generated transaction. An agent with no browser hands the sign-in to its owner, who completes it in the AgentMail console.

AgentID is free for apps to add; agents need an AgentMail inbox. Public launch is October 6, 2026.

The full technical walkthrough is in how to let an AI agent sign in to your website.

How do Entra Agent ID and AgentID compare?

Entra Agent ID and AgentID are not substitutes. One is intra-organizational governance and the other is cross-organizational identity.

The table puts the differences side by side.

An organization can run both without conflict. Entra governs the agents at home. AgentID is how the same agents introduce themselves when they sign up for a tool the organization does not run.

The longer comparison is at AgentID vs Microsoft Entra Agent ID.

What other AI agent identity management platforms exist?

The two products called Agent ID are not the only implementations of the idea. Google Cloud, Auth0, and Descope each offer agent identities of their own.

• Google Cloud Agent Identity gives each agent on Google's runtime a SPIFFE identity and an X.509 certificate. Google states that "because the agent itself is the principal, you grant permissions directly to this identifier." It went generally available in stages through August 2026.
• Auth0's Agent as Principal registers agents "as first-class identities in Auth0, distinct from human users and traditional M2M clients" inside your tenant. It was in early access as of July 2026.
• Descope's Agentic Identity Hub 2.0 added agents "as first-class identities alongside human users" in January 2026.

All three are real agent IDs by the four-property test. All three are scoped to a platform the operator controls: Google's runtime, an Auth0 tenant, a Descope project.

That is the axis to sort the category on. Ask whether the identity can be presented to a party that did not issue it and does not share your identity provider.

If the answer is no, you have a governed internal identity. If yes, you have a portable one.

There is a longer glossary of these terms, including delegated access and workload identity, in the agent identity terminology field guide.

How is an agent ID created and revoked?

An agent ID is created when the agent gets its credential, lives as long as the credential is valid, and ends when someone revokes it. Those are the three stages of the AI agent identity lifecycle.

In AgentID, the lifecycle runs in four steps:

1. Create an AgentMail inbox for the agent.
2. Enroll a browser once. The browser generates a non-extractable P-256 key and registers the public half.
3. Sign in from that browser as often as needed, with a fresh signature each time.
4. Revoke the enrolled credential when the agent is retired.

Revocation stops that one agent and touches nothing of the owner's. AgentID's own signing keys rotate with stable key ids and an overlap window, so relying parties never break mid-rotation.

In Microsoft Entra Agent ID, the lifecycle runs through entitlement management and lifecycle workflows tied to the Sponsor, with Conditional Access policies and Entra ID Protection risk signals applied to agents.

Either way, the question to ask of any agent ID is who can revoke it and what else breaks when they do.

How is "agent ID" different from "agentic identity" and "non-human identity"?

The three phrases are used loosely and mean different sizes of thing. Agent ID is the narrowest, and non-human identity is the broadest.

• Agent ID is the identifier and credential a single agent presents.
• Agentic identity is vendor language, mostly Descope's and Okta's, for a product suite that covers agent IDs plus delegation, credential vaulting, and MCP authorization.
• Non-human identity (NHI) is the enterprise security category that includes service accounts, API keys, machine certificates, and now agents.

NHI is the vocabulary of enterprise identity and access management vendors. Its concerns are inventory, secret sprawl, and lifecycle inside a company.

If you are a security team counting credentials, NHI is your frame. If you are a developer whose login page just received a sign-in from something that is not a person, agent ID is.

What does an agent ID look like in practice?

In practice, an AgentID agent ID arrives as an ES256-signed id_token. Decoded, for an open client, it looks like this:

{
  "iss": "https://auth.agentid.com",
  "aud": "https://yourapp.com",
  "sub": "a91f2c8e...43",
  "email": "support@acme.agentmail.to",
  "email_verified": true,
  "iat": 1767225000,
  "exp": 1767225600,
  "jti": "9f1c2a44-3e77-4c19-9a2e-6b0d5f8e1c33"
}

Three of the four properties are visible:

• sub is the stable subject.
• The ES256 signature is the agent-held credential, checked against the issuer's JWKS without trusting the agent.
• email is the agent's own reachable address, and jti names this one sign-in so it cannot be replayed.

The fourth property, the accountable human, is not in this token by design. A registered client reads owner_email from /userinfo with the access token from the same exchange.

An Entra token for an agent identity carries the equivalent in a different shape. The agent identity's object ID is in the token, and the Sponsor is resolvable through the directory rather than the token.