What Microsoft Entra Agent ID is
Microsoft's overview describes Entra Agent ID as an identity and security framework that extends Microsoft Entra capabilities to AI agents. Microsoft's agent identity documentation defines agent identities as identity accounts within Microsoft Entra ID that provide unique identification and authentication capabilities for AI agents, and states that each time an AI agent is created, it gets an agent identity in the Microsoft Entra tenant. Agents can request access tokens from Microsoft Entra and use those tokens to access web services.
Agent identities are created from an agent identity blueprint, which Microsoft describes as an object in Microsoft Entra ID that serves as a template for creating agent identities. According to that page, credentials used to authenticate an agent identity are configured on the blueprint, and OAuth permissions granted to a blueprint are granted to all agent identities created from it.
Around the identity, Microsoft lists Conditional Access, ID Protection, identity governance, network controls, and sign-in and audit logs for agents, with support for OAuth 2.0, the Model Context Protocol and agent-to-agent authentication. Microsoft states that Agent ID is available for all Microsoft Entra customers and that extending Microsoft Entra security features to agents requires Microsoft Agent 365.
What AgenID is
AgenID is an open protocol, specified in the MIT-licensed AgenID specification, that gives an AI agent a permanent identifier of the form agenid:<ULID>. The operator generates an Ed25519 key pair on its own machine or in the browser at /issue, writes a manifest covering identity, ownership, purpose and disclosure, and signs a proof that binds that manifest by SHA-256 digest. The private key never leaves the operator.
Anyone can resolve https://www.agenid.com/a/<agenid> to a Verification Card or, with Accept: application/json, to the resolution envelope, and re-verify it offline. There is no account, no tenant and no sign-in for the verifier. The registry holds no operator private keys and cannot forge an operator signature.
Key differences
Scope is the clearest difference. An Entra agent identity lives in a Microsoft Entra tenant and is meaningful to resources that accept tokens from Microsoft Entra. An AgenID identity is public and portable: a business receiving a phone call or an API request from the agent can check it without any relationship with the operator's directory or with AgenID.
The source of assurance also differs. In Entra, a relying resource accepts an access token that Microsoft Entra issued to the agent. In AgenID, a verifier does not take the registry's word for anything: it recomputes the manifest digest, verifies the operator's Ed25519 signature over RFC 8785 canonical JSON, and compares the registry's copy of the operator key with the operator's own copy (two-path key discovery).
The largest difference is permission. Entra Agent ID is, to a large degree, an access-management system: Microsoft's authorization documentation describes delegated and application permissions, a requirement that administrators explicitly consent to any app permission an agent gets, high-privilege directory roles such as Global Administrator that agents cannot hold, and inheritable permissions granted once at the blueprint. AgenID v1.1.1 has no permission model. It answers which agent is acting and who declared it, not what that agent is allowed to do.
Where they are complementary
The two fit on opposite sides of an organization's boundary. Inside the organization, Entra Agent ID governs which resources an agent may reach and records what it did. Outside, the counterparty that receives the agent's call, message or request usually has no access to that tenant; an AgenID identifier gives that counterparty a public, operator-signed record to check. An operator could run an agent with an Entra agent identity for internal access and publish an AgenID identity for the outside world. Neither system defines a link to the other today, so any mapping between them would be the operator's own configuration.
When to use which
These are fit questions, not quality judgments.
- Consider Microsoft Entra Agent ID when your agents run inside a Microsoft Entra environment and you need them to authenticate to protected resources under Conditional Access, consent, governance and audit logging.
- Consider AgenID when parties outside your organization, who have no access to your directory, need to check which agent contacted them and which operator stands behind it.
- Consider both when the same agent both reaches internal resources and contacts outside businesses or people.
AgenID's current limits
AgenID's boundaries, stated as plainly as its design:
- Issuance ceiling: the reference deployment at agenid.com issues nothing above L1_REGISTERED today. The specification defines L2_DOMAIN_VERIFIED, L3_ORGANIZATION_VERIFIED and L4_DEPLOYMENT_VERIFIED, but each requires a VerificationAssertion signed by a root authority key, and that key has not been created yet. L1_REGISTERED is a self-declaration: it means an operator-signed manifest is in the registry, not that anyone checked the operator. L5 is reserved and not issuable.
- No revocation flow is deployed. Agent status values such as SUSPENDED and REVOKED exist in the schema so the envelope shape is stable, but nothing in production writes them, so every registered agent reads ACTIVE. The specification keeps retired and revoked keys resolvable permanently so that historical signatures remain checkable.
- No authorization object exists in v1.1.1. The DECLARED, VERIFIED and AUTHORIZED claim states are never inferred from one another, AUTHORIZED has no signed object, and
permissionsandauthorizationsare reserved manifest keys that a v1.1.1 validator rejects. A v1.2 authorization layer is a draft in development, not something available. - Two-path key discovery depends on the operator. The registry serves the operator key at
GET https://www.agenid.com/v1/keys/<key-ulid>, and the operator is expected to publish its own copy athttps://<operator_domain>/.well-known/agenid/keys.json. If the operator publishes no copy, a verifier has one source, not two.