Microsoft Agent Registry and Entra ID: what it changes for governance

At a glance

What this is: Semperis shows that Microsoft’s Agent Registry and Entra Agent ID are separate control planes for AI agents, with one focused on inventory and governance and the other on identity, permissions, and token issuance.

Why it matters: IAM teams need to govern agent discovery and agent authentication differently, or they will miss gaps where an agent is visible in the registry but still blocked, disabled, or mis-issued at the identity layer.

Context

AI agent governance only works when inventory and authentication are treated as different control problems. A registry can tell you which agents exist, who owns them, and what they can do, but it does not by itself issue or deny tokens.

That separation matters for Entra-backed agents because the registry can include registry-only agents that do not have first-class identities. For IAM and IGA teams, the practical question is whether governance is being enforced at discovery time, identity time, or both.

Microsoft’s model also splits policy actions across the admin experience and the identity layer. In practice, that means teams must understand which control they are changing before they assume an agent is blocked, enabled, or offboarded.

Key questions

Q: How should teams govern AI agents when inventory and identity controls are split?

A: Treat the registry as discovery and lifecycle visibility, and treat Entra Agent ID as the enforcement layer for authentication and permissions. The two controls answer different questions, so governance needs separate ownership, separate evidence, and separate response paths. If teams collapse them into one process, blocked agents, disabled identities, and registry-only agents will be misclassified.

Q: When does a registry review fail to prove an agent is actually controlled?

A: A registry review fails whenever it shows an agent exists, but does not prove that the agent can or cannot obtain tokens. Visibility, ownership, and publication state are useful, but they do not replace identity-layer enforcement. Practitioners should use registry evidence as input to control decisions, not as proof that authentication has been governed.

Q: What breaks when teams block an agent in the registry but leave Entra identity unchanged?

A: Users may be prevented from installing or using the agent in supported Microsoft 365 experiences, but the underlying identity posture can still be inconsistent. That mismatch creates false confidence because the registry action does not equal token denial. The control failure is assuming a user-facing block automatically disables the authentication path.

Q: How do OBO and autonomous agent flows change access governance?

A: OBO adds a human user token into the exchange, so the agent’s access is partly shaped by delegated user context, while autonomous flows rely on the agent’s own credentials and resource token path. The governance difference is material because the review question changes from user delegation to machine-issued privilege. Teams need flow-specific policy and audit evidence.

Technical breakdown

Agent registry versus identity layer

The Microsoft Agent Registry is an inventory and governance surface. It records which agents exist, who owns them, where they were created, whether they are published or blocked, and what tools or data sources they touch. Entra Agent ID is different: it governs the identity that authenticates, receives tokens, and is eligible for Conditional Access and identity monitoring. The operational risk is confusing discovery with enforcement. A registry can improve visibility without changing whether an agent can actually authenticate, and an identity can be disabled while still remaining visible in the registry.

Practical implication: separate registry reviews from identity controls in your governance model.

How agent authentication flows change token issuance

Microsoft describes three OAuth-based patterns for agents: autonomous, on-behalf-of, and user-context authentication. In each case, the agent ultimately proves itself to Entra ID using configured credentials such as federated identity credentials, certificates, or client secrets. The key difference is which tokens are validated and whose context is carried into the exchange. That matters because permissions are not abstract properties of the agent alone. They are the result of flow-specific token validation, identity blueprint configuration, and whether a human user context is present.

Practical implication: map each agent flow to the exact token and claim sequence it uses.

Why blocking in the registry is not the same as disabling identity

Registry actions and identity actions do not produce the same outcome. Blocking an agent in the registry prevents supported Microsoft 365 experiences from letting users install or use it. Disabling an Entra agent identity stops authentication and token issuance, which is a different control effect. The article’s important governance point is that these actions are not interchangeable, even if they look similar in the admin experience. Teams that treat them as one control plane will misread what has actually been contained or offboarded.

Practical implication: define which layer owns user-facing blocking and which layer owns token denial.

NHI Mgmt Group analysis

Registry visibility is not identity enforcement. Microsoft’s model confirms a control split that many IAM programmes still blur: discovery, ownership, and lifecycle visibility live in one plane, while token issuance and permissions live in another. That distinction matters because governance can look complete even when identity controls are untouched. Practitioners should stop treating registry coverage as proof of agent control.

Token issuance is the real security boundary for agent identity. Once an agent can authenticate through autonomous, OBO, or user-context flows, the meaningful question is not whether it exists in an inventory but whether the token path matches the intended privilege model. The practical implication is that registry workflows need to feed identity policy, not replace it. This is where Entra-backed controls become the deciding layer.

Agent cards create a discovery artifact, not a trust decision. The metadata document helps other systems understand capabilities, interfaces, and authentication requirements, but it does not itself grant access. That means teams should govern agent cards as intake evidence for review, not as an approval mechanism. The practitioner lesson is to treat discovery metadata as input to governance, not as governance itself.

Agent authentication is now a lifecycle problem, not just an access problem. The article shows that ownership, publish state, blocked state, and token-issuing identity all move independently. That creates governance debt if offboarding and recertification only cover one of those states. The implication for identity programmes is that agent lifecycle controls must explicitly span registry state and Entra state together.

Agent visibility without first-class identity creates governance blind spots. Registry-only agents can be discoverable even when they are not represented as Entra identities, which means different classes of agents require different review paths. That is a meaningful operating model shift for IAM and IGA teams. Practitioners need separate evidence chains for discoverability, ownership, and authentication authority.

What this signals

Identity governance for agents now has two separate checkpoints. The first is whether the agent is discoverable, owned, and appropriately published in the registry. The second is whether its Entra identity can authenticate and receive tokens under the intended policy. Programmes that only certify one checkpoint will miss the real control boundary.

Registry-only agents are a governance edge case, not an exception to ignore. They show why inventory completeness and identity enforcement must be reconciled before recertification closes. That is especially important for teams building AI agent governance into existing IAM and IGA processes, because the review object may not be the same as the enforcement object.

Token exchange paths are becoming a core audit artefact. IAM teams should expect to document which flows are permitted, what credentials back them, and which claims are issued at each step. That evidence becomes more valuable as agent ecosystems grow and as agent identity moves from discovery into operational control.

For practitioners

• Separate registry governance from identity governance Document which team owns inventory, ownership, publication status, and user-facing blocking in the Agent 365 registry, and which team owns Entra Agent ID, token issuance, and access policy enforcement.
• Map each agent to its authentication flow Classify agents as autonomous, OBO, or user-context and record the exact token exchange path, credential type, and resource scope for each.
• Review registry-only agents separately Build a governance queue for agents that appear in the registry but do not have a first-class Entra identity, so they are not lost in identity-only recertification cycles.
• Test blocking and disabling as distinct outcomes Validate that registry blocking prevents install or use, while identity disabling stops authentication and token issuance, then confirm your response runbook uses the right action for the right layer.

Key takeaways

• Microsoft’s model separates registry governance from identity enforcement, so visibility alone does not prove an AI agent is controlled.
• The important operational boundary is token issuance, not just whether an agent appears in an admin inventory.
• IAM teams need separate processes for registry state, Entra identity state, and flow-level authentication review.

Key terms

• Agent Registry: An agent registry is a central catalog of sanctioned and shadow AI agents, including their identities, permissions, and lifecycle state. Its value depends on whether it feeds broader governance, because a registry without telemetry, ownership, and offboarding can become another silo.
• Entra Agent ID: The identity object used as the security layer for an agent in Microsoft Entra ID. Unlike a registry record, it is the construct that can participate in authorization, lifecycle governance, and policy enforcement, which makes it the operational boundary for access control.
• Agent Card: An Agent Card is a machine-readable description of an agent’s capabilities, endpoint, and invocation details. In A2A-style systems it helps other agents discover and call the agent at runtime, which makes the card a governance object as much as a technical descriptor.
• On-Behalf-Of Flow: A token or session pattern where one identity acts for another while preserving evidence of delegation. For agents, the value is not just access propagation. It is the ability to show that the action was performed under a specific authority and within a specific scope.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.