Start with the correction, because it matters for accuracy.
Earlier survey work in this field flagged Entra Agent ID as too new to assess.[3] That is no longer the case: Entra Agent ID reached general availability in April 2026 and is documented in depth.[1][2] This teardown reads the shipped product.
The Inversion
The architecture is a clean inversion of every other format in the arc. There is no self-published record. There is no well-known endpoint an agent publishes about itself. An agent identity is a special service principal in a Microsoft Entra tenant — it has an object ID, a display name, and, critically, no credentials of its own.[1] It cannot authenticate itself. It obtains tokens only through an agent identity blueprint, a reusable template that holds the actual credentials — federated identity credentials, certificates, or client secrets — and acquires tokens on the agent’s behalf, and only for scopes a user or tenant admin has consented to.[1] The agent does not assert who it is and what it may do. The enterprise directory issues it an identity and grants it scopes, and the agent operates strictly within them.
This is why the notarization wall inverts. In the self-describing formats, the hard problem is that a signature attests authorship, not truth — a signed record can claim a capability the agent does not have. In Entra, there is no self-asserted capability claim to notarize. The identity is not something the agent presents and asks you to trust; it is something an accountable authority — the enterprise’s own Entra tenant — issued, and can revoke. The trust root is not the agent and not a distributed ledger. It is the identity provider the enterprise already runs and already answers to its auditors for. That is a materially different assurance posture: the question shifts from “can I verify this agent’s claim about itself” to “do I trust my own directory’s issuance and governance” — which is a question enterprises already know how to answer.
| Dimension | Self-describing (A2A / AGNTCY / AgentFacts) | Entra Agent ID |
|---|---|---|
| Who describes the agent | The agent publishes a card / record | The enterprise directory issues an identity |
| Where credentials live | With the agent / its signing pipeline | On the blueprint; agent has none of its own |
| Trust root | The signer’s key (trust it yourself) | The enterprise’s own Entra tenant |
| What’s proven | Authorship + integrity of a claim | Issuance + governance by an accountable authority |
| Boundary | Open-network, cross-organization | Single-tenant, inside the enterprise |
Governance by Construction
The governance surface is where Entra is strongest, and it is real, shipped capability. Blueprints let an administrator act on an entire class of agents at once — apply a conditional access policy to every “Sales Assistant Agent,” revoke a permission grant across all of them, or disable the entire class in a single operation.[1] Every agent identity carries a sponsor: a named human or group accountable for it, used to prevent orphaned agents and to reach an accountable person during an incident.[1][2] Identity governance extends lifecycle management, access reviews, entitlement, and time-bound access packages to agents, with all authentication and activity logged for compliance and audit.[2] This is the governance-by-construction posture the parent series argues for — authority granted, scoped, reviewed, and revocable on the enterprise’s own clock, at the class level, with named human accountability.
The Boundary
The inversion has a real cost, and honest accounting requires naming it. Entra governs identity and authority extremely well and says very little about capability description or discovery. There is no rich, portable capability manifest — what an agent may do is expressed as directory permissions and consented scopes, not as a self-describing skill taxonomy other systems can discover and reason over. And the model is bounded to the tenant: agent identities are single-tenant by design — they can only be issued tokens in the tenant where they were created and cannot access resources in other tenants.[1] Blueprints can be published multitenant, but the identities themselves remain tenant-local. This is excellent for governing agents an enterprise runs inside its own boundary and silent on the cross-organization, open-network discovery problem the other formats were built for. Entra answers “who is this agent inside my enterprise and what may it do here,” not “how does an agent in one organization discover and trust an agent in another.” Those are different problems; Entra solves the first and does not attempt the second.
Read against the five Substrate Fitness Criteria:
Discoverability — partial, and inward-facing. Entra provides centralized discovery of every agent identity in the tenant through the admin center and Microsoft Graph, which is real discoverability for governance — it prevents shadow agents and maintains a complete inventory.[2] What it does not provide is a portable, cross-organization capability discovery mechanism; discovery is of governed identities within a boundary, not of capabilities across an open network.
Context integrity — strong. Because the identity lives in the directory rather than in a self-published file, its state is authoritative and current by construction — there is no stale card to drift from reality. Lifecycle management, real-time risk detection, and time-bound access keep the identity’s authority aligned with its current governed state.[2]
Action authority — strong. This is Entra’s standout. Authority is bound to identity through consented scopes and Graph permissions, enforced at token issuance, and governed at the blueprint level so a whole class inherits and can be changed together.[1][2] Authority is not described alongside the identity; it is enforced by the issuer of the identity.
Permissioning — strong. Grant, scope, review, and revoke are first-class and operate on the enterprise’s governance clock: conditional access, entitlement management, access packages, class-level permission revocation, and single-operation disablement of an entire agent kind.[1][2] This is the strongest permissioning in the arc.
Provenance — strong within the tenant, bounded at its edge. Issuance provenance is excellent: every agent identity traces to a blueprint, a publishing organization, and an accountable sponsor, with full audit logging.[1][2] The bound is scope — provenance is anchored in and verifiable within the enterprise’s own trust domain, not a cross-organization attestation that a foreign agent’s claims are true. Inside the boundary, provenance is as strong as the enterprise’s own identity governance; across boundaries, it does not reach.
| Criterion | Rating | Basis |
|---|---|---|
| Discoverability | Partial · inward | Centralized tenant inventory via admin center and Graph; no cross-org capability discovery |
| Context integrity | Strong | Identity lives in the directory, authoritative by construction; no stale self-published card |
| Action authority | Strong | Authority bound to identity via consented scopes and Graph permissions, enforced at issuance, governed at blueprint level |
| Permissioning | Strong | Conditional access, entitlement, access packages, class-level revocation and disablement on the enterprise clock |
| Provenance | Strong · tenant | Blueprint, publisher, and accountable sponsor with audit logging; anchored within the tenant, not cross-org |
The Honest Accounting
Entra is the inverse specimen, and the inversion is its strength and its limit in one. By refusing self-description and making the enterprise directory the issuer, it sidesteps the notarization wall the other formats hit — there is no self-asserted claim to over-trust, because authority flows from an accountable issuer the enterprise already governs. That makes it, on identity, authority, and permissioning, the strongest format in this arc for agents an enterprise runs inside its own boundary. What it deliberately does not do is describe capabilities portably or solve cross-organization discovery — the open-network problem the self-describing formats exist to address. The field’s error would be to read these as competitors on one axis. They are answers to different halves of the problem: Entra governs the agents you own; the descriptor formats discover the agents you don’t. An enterprise architecture that needs both cannot get both from either — and that gap is exactly what the synthesis matrix makes visible.
The other formats make an agent’s self-description trustworthy. Entra removes the self-description entirely — the agent has no credentials of its own and obtains authority only through an identity the enterprise directory issues and governs.
The trust root is not the agent and not a distributed ledger. It is the identity provider the enterprise already runs and already answers to its auditors for.
