Topic starter
14/07/2026 4:26 pm
TL;DR: Semperis argues that registry visibility and identity enforcement are separate, so an agent can appear governed without being controlled. Entra Agent ID and the registry need separate evidence, because token issuance and inventory state answer different questions.
Editorial analysis by NHI Mgmt Group, based on content published by Semperis: “The Agent Registry and How Agent Identities Operate in Entra ID”.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Microsoft’s model separates registry governance from identity enforcement, so visibility alone does not prove an AI agent is controlled.
Glossary terms: Agent Registry, Entra Agent ID, Agent Card, On-Behalf-Of 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 walkthrough of how Microsoft Agent Registry and Entra Agent ID differ in practice
- Token-by-token explanation of autonomous, OBO, and user-context agent authentication flows
- Practice checkpoints for registering an agent and verifying claims across the three flows
- Admin actions such as blocking, unblocking, reassignment, and deleting supported agent types
👉 Read Semperis's guide to Microsoft Agent Registry and Entra ID governance →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 hours ago by NHI Mgmt Group
14/07/2026 4:33 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Microsoft Agent Registry and Entra ID: what it changes for governance