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

At a glance

What this is: This is an analysis of Microsoft’s Agent Registry and Entra Agent ID split, showing that inventory governance and identity enforcement are distinct layers for AI agents.

Why it matters: IAM teams need to understand the split because discovery, blocking, ownership, and token control are different decisions, and confusing them creates gaps in agent governance, conditional access, and lifecycle oversight.

👉 Read Semperis's guide to Microsoft Agent Registry and Entra ID agent authentication

Context

AI agent governance fails when organisations assume a single control plane can both discover agents and enforce identity-level access. In Microsoft’s model, the registry provides inventory and administrative oversight, while Entra Agent ID governs authentication and permissions for agents that have first-class identities. That separation matters because registry-only agents can still be visible without being identity-governed, which creates a control gap if teams treat registration as equivalent to access control.

For identity practitioners, the key question is not whether an agent exists, but which layer owns its lifecycle, visibility, and token issuance. The article is a practical walkthrough of how Microsoft separates those functions across Agent 365 and Entra, and that model is typical of the broader governance problem facing AI agents in enterprise identity programmes.

Key questions

Q: How should security teams govern AI agents that use multiple identity layers?

A: Security teams should inventory every identity layer an agent can use, including static credentials, session identities, embedded tool identities, and any delegated relationships between agents. Governance fails when one layer is controlled while another remains open, because the agent can still act through the weaker path. Treat the layered identity surface as the actual access boundary.

Q: What is the difference between blocking an agent in the registry and disabling its identity?

A: Blocking in the registry limits whether users can install or use the agent in supported Microsoft 365 experiences. Disabling the identity stops authentication and token issuance for that agent identity. Those actions are not interchangeable, so teams should choose the control based on whether the goal is discovery suppression, usage restriction, or identity revocation.

Q: Why do AI agents make non-human identity governance harder?

A: AI agents make governance harder because they can request tools, act autonomously, and change behaviour across sessions while still relying on machine credentials. That increases the number of access paths security teams must supervise. The result is a stronger need for task-scoped access, explicit ownership, and continuous monitoring of what the agent can reach.

Q: Who should own offboarding when an AI agent is retired or replaced?

A: Ownership should sit with the workflow or system that created the agent, not with HR by default. The revocation process must remove delegated access, inherited credentials, and connected tool permissions together, otherwise a decommissioned agent can remain operational in the background.

Technical breakdown

Agent registry versus agent identity

The Agent Registry is an inventory and governance layer. It tells administrators which agents exist, who owns them, where they came from, what they can do, and whether they are shared, blocked, or published. Entra Agent ID is different. It is the identity layer that governs whether an agent can authenticate, what permissions it receives, and whether identity-based controls such as Conditional Access or governance policies can apply. The operational risk comes from conflating visibility with enforcement. A registry can show an agent, but that does not mean the agent has an Entra-backed identity or that identity controls will stop it from acting.

Practical implication: treat registry review and identity enforcement as separate governance tasks, not one combined approval.

Three authentication flows for AI agents

The article describes three OAuth-based flows: autonomous app-only access, on-behalf-of delegation, and user-context operation. All three rely on credentials configured on the agent identity blueprint, such as federated credentials, certificates, or client secrets. The distinction is in who supplies context and how tokens are chained. In autonomous flows, the agent acts without user context. In OBO, the agent acts on behalf of a human user. In user-context flows, the agent still acts autonomously but carries user context through token exchange. This is a governance problem because the same agent may traverse different authorisation paths depending on runtime intent.

Practical implication: map each agent to the exact OAuth flow it uses before deciding how to apply access policy, logging, and review.

Why blocking and disabling are not the same control

The registry layer and the identity layer produce different outcomes when an administrator blocks or disables an agent. Blocking at the registry level can prevent users from installing or using an agent in supported Microsoft 365 experiences. Disabling the Entra identity affects authentication and token issuance for that underlying identity. That difference matters because a registry listing can persist even after identity disablement, and an agent can be visible without being usable. In practice, organisations need to understand which action they are taking and which layer it actually affects. Otherwise they may believe an agent is controlled when only its discoverability changed.

Practical implication: document whether your control objective is discovery suppression, usage restriction, or token revocation before you choose the action.

NHI Mgmt Group analysis

Agent registry visibility is not agent governance. A central inventory tells you what exists, but it does not prove the agent can authenticate safely or be constrained by identity policy. That distinction is now foundational in AI agent programmes because registry-only artefacts can still expand the attack surface even when they are not first-class identities. Practitioners should treat discovery and enforcement as separate governance duties.

Authentication flow determines the governance model, not the label "agent". Autonomous app-only access, OBO delegation, and user-context flows carry different trust assumptions, token paths, and audit needs. The important issue is not whether the system is called an agent, but whether it operates with human context, delegated authority, or independent runtime access. Teams need to classify the actual token path before they assign control ownership.

Identity controls for AI agents must follow the token boundary. If the registry layer and the Entra layer are misaligned, policy decisions will land on the wrong side of the enforcement boundary. That creates false confidence, especially where ownership, publication, blocking, and identity disablement are split across administrative surfaces. The implication is straightforward: governance for AI agents must be mapped to the layer that issues or denies tokens.

Microsoft’s model reflects the broader shift from application inventory to agent lifecycle governance. Enterprises are moving from asking which app is installed to asking which agent exists, who owns it, which data sources it can touch, and how it authenticates. That is a lifecycle question as much as a security question, and it now spans discovery, onboarding, usage control, and revocation. Practitioners should expect agent governance to converge with broader identity lifecycle practices.

Agent governance will fail if human IAM assumptions are reused unchanged. Access reviews, ownership checks, and approval flows were built for relatively stable application and user identities. AI agents can be created, shared, blocked, or reconfigured faster than those cadences were designed to handle, so the control model needs sharper lifecycle boundaries. The conclusion is that identity governance must become agent-aware, not just application-aware.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• That gap makes 52 NHI Breaches Analysis the right next step for understanding how governance failures become incidents.

What this signals

Registry-first governance will not be enough as agent populations grow. Teams will need to distinguish between discoverability, ownership, and token authority because those controls fail independently. With 97% of NHIs carrying excessive privileges, per Ultimate Guide to NHIs, the danger is not just more agents. It is more agents with unclear enforcement boundaries.

Identity programmes should expect AI agent lifecycle work to converge with NHI governance. The operational question will be whether the organisation can prove who owns an agent, where it authenticates, and how quickly its access can be removed. That makes agent inventory, offboarding, and token path validation part of the same control story.

Agent lifecycle control is becoming a named governance gap. As organisations add more AI agents, the practical risk is control-plane drift between what is visible and what is enforceable. IAM teams should prepare for access reviews that include registry state, identity state, and runtime token path together.

For practitioners

• Separate discovery controls from identity controls Define whether a control action is meant to hide an agent from users, block use in Microsoft 365 experiences, or stop authentication at the token layer. Record the intended enforcement point in the runbook so administrators do not confuse registry actions with Entra identity actions.
• Map every agent to its real OAuth flow Classify agents as autonomous app-only, OBO, or user-context before assigning logging, approval, and review requirements. The same agent family may use different token paths, so policy has to follow the runtime flow rather than the product label.
• Review ownership and offboarding together Require named owners for registry-visible agents and define a revocation path for both registry presence and identity issuance. If ownership changes or the agent is retired, remove or disable both the visible entry and the authority to mint tokens.
• Align Conditional Access with the agent identity layer Apply identity-based policy only where the agent has a first-class Entra identity, and do not assume registry visibility is enough to enforce policy. Validate that the control sits on the token issuance path before relying on it for containment.

Key takeaways

• Microsoft’s model separates agent discovery from identity enforcement, and that separation is the core governance issue.
• AI agent authentication is not one thing. Autonomous, delegated, and user-context flows create different policy and audit requirements.
• Teams that do not map controls to the correct enforcement layer will mistake visibility for security.

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: Microsoft’s identity layer for agents that have first-class Entra-backed identities. It governs authentication, permissions, and identity-based policy enforcement for agent workloads. The important distinction is that an agent can be present in a registry without having a corresponding identity that can be controlled at the token layer.
• 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.
• User Context Authentication: An authentication pattern where an agent operates autonomously but carries user context through token exchange. The agent is not simply impersonating a user; it is preserving context while still making runtime access requests. That means governance must account for both the agent’s authority and the user signal embedded in the flow.

What's in the full article

Semperis's full guide covers the operational detail this post intentionally leaves for the source:

• Step-by-step walkthroughs of how the Agent Registry and Entra Agent ID behave in the Microsoft admin surfaces.
• Token-by-token explanations of the three authentication flows, including what T1, T2, TC, and TR represent.
• Practice checkpoint guidance for registering an agent and verifying claims across the different flows.
• Operational examples of how registry-only agents differ from first-class Entra agent identities.

👉 Semperis's full guide covers registry controls, identity boundaries, and the three agent authentication flows in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.