Notifications
Clear all
Topic starter
14/07/2026 4:26 pm
TL;DR: Microsoft’s Agent Registry centralises discovery, ownership, and governance for AI agents, while Entra Agent ID governs identity, permissions, and token issuance across autonomous, OBO, and user-context flows, according to Semperis. The core issue is that registry visibility and identity enforcement are separate control planes, so governance fails if teams treat them as interchangeable.
NHIMG editorial — based on content published by Semperis: Chapter 5 of Understanding and Preventing Entra ID Agent Identity Attacks
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Review ownership and offboarding together Require named owners for registry-visible agents and define a revocation path for both registry presence and identity issuance.
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.
👉 Read Semperis's guide to Microsoft Agent Registry and Entra ID agent authentication →
Agent Registry and Entra ID governance: what changes for IAM teams?
Explore further
14/07/2026 4:33 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Microsoft Agent Registry and Entra ID: what it changes for governance
