TL;DR: Registering an agent in Microsoft’s Agent Registry can create a management record without creating a Microsoft Entra Agent ID, according to Semperis. The core risk is assuming a registry entry implies an identity, when the actual control boundary sits at the Entra ID layer.
At a glance
What this is: Semperis explains that an agent can be registered in the Microsoft Agent Registry without being created as a Microsoft Entra Agent ID.
Why it matters: IAM and NHI teams need to distinguish discovery records from identity objects, or they will certify visibility that does not actually grant governed access.
Context
The core control gap is simple: a management or discovery record is not the same thing as an identity object. In Entra ID terms, the registry can hold metadata about an agent while the identity layer remains absent, so governance tooling may show something to review even when no Entra Agent ID exists.
That distinction matters for NHI governance because lifecycle, permissions, and audit decisions attach to the identity layer, not to the registry entry. If teams assume the registry record is the identity, they may build recertification, inventory, or approval processes around the wrong object and miss where access is actually controlled.
Key questions
Q: What breaks when a registry entry is treated as proof of agent identity?
A: Governance breaks because the registry can record an agent without creating an access-bearing Entra ID object. That creates false confidence in inventory, ownership, and lifecycle coverage. The practical risk is certifying a record that has no identity boundary behind it, so access decisions and offboarding controls never attach to the real principal.
Q: Why does discovery metadata not solve identity governance for agents?
A: Discovery metadata helps teams find and describe agents, but it does not establish authentication, authorization, or lifecycle control. Identity governance depends on the object that actually bears access. If the agent is only registered, teams can know it exists without knowing whether it is governed as a principal.
Q: How should teams govern agents that are registered but not linked to Entra ID?
A: Treat them as incomplete onboarding cases and route them through validation before any access-sensitive process. A registered but unlinked agent is useful for inventory and triage, but it should not be allowed to progress into ownership attestation, access review, or lifecycle closure until the identity object exists.
Q: What is the difference between registry visibility and identity creation for agents?
A: Registry visibility is a management function that surfaces metadata and helps administrators track agents. Identity creation is the security function that establishes the principal on which authentication, authorization, and governance depend. The two are related, but only identity creation gives teams a control boundary they can actually secure.
Technical breakdown
Agent registry records versus Entra ID identity objects
The Microsoft Agent Registry is a management and discovery plane. It can store display names, owner IDs, creator metadata, timestamps, and related fields that help administrators find and catalogue agents. Entra Agent ID is different: it is the identity layer where authentication, authorization, and lifecycle semantics attach. A registry record can exist without the identity object being created, which means the two artefacts serve different governance purposes. The important technical point is that visibility metadata does not establish an authentication principal. Practical implication: govern the registry as inventory, but govern Entra Agent ID as the access-bearing identity.
Practical implication: separate inventory review from identity governance so discovery records are never mistaken for access-bearing principals.
Why omitting the agent identity ID changes the control boundary
The article shows that when the agent identity ID is omitted, the registry record is still created but it is not linked to an Entra Agent ID. That means the endpoint accepts a registration payload that can create an observable object without binding it to the identity plane. For practitioners, this is a classic boundary problem: the system exposes a way to document an agent before a formal identity exists. That is useful for discovery, but it also creates the risk that downstream processes infer completeness where none exists. Practical implication: treat unlinked registry entries as incomplete governance artefacts, not as validated identities.
Practical implication: flag unlinked registry entries for follow-up because they are discovery artefacts, not validated identity objects.
Why discovery-first workflows can mislead identity governance
Discovery-first workflows are often built to improve coverage, but they can also blur the difference between knowing an asset exists and proving it has a governed identity. In this case, the registry provides a view of agents in the Microsoft 365 admin center, yet the article explicitly separates that view from identity creation. That separation matters because controls such as access approval, ownership accountability, and lifecycle handling apply only when the identity exists. Practical implication: design governance checks to ask whether an agent is merely listed or truly instantiated as an identity.
Practical implication: require control checks that confirm identity creation, not just registry presence, before granting lifecycle or access governance.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Meta AI Instagram Account Takeover: 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Discovery does not equal identity, and that is the governance error this article exposes. The Microsoft Agent Registry can surface an agent without establishing an Entra Agent ID, so the appearance of coverage can outpace the existence of a governed principal. That breaks the assumption that inventory completeness implies access control completeness. Practitioners should treat registry visibility as preparatory evidence, not as proof of identity governance.
Registry-first agent workflows create identity blind spots when teams use the wrong object as the control anchor. A registry entry can carry useful metadata such as display name, owner IDs, and timestamps, but those fields do not create the authentication and authorization boundary. In NHI terms, the object that can be reviewed is not always the object that can be governed. The practitioner implication is to anchor lifecycle and access decisions to the Entra ID layer, not the registry layer.
Agent inventory is a management function, while identity creation is a security function. That distinction is easy to miss when dashboards and admin-center views make the agent look established simply because it is listed. The article shows why governance programmes need explicit object classification before they can claim control coverage. The practical conclusion is to separate discovery, registration, and identity issuance into distinct control states.
Identity creation workflows need a named boundary between catalogue and principal. Without that boundary, teams can certify the catalogue and still leave the real access surface outside review. This is a familiar failure mode in NHI governance: visibility improves faster than enforceable control. Practitioners should build policy language that distinguishes registered, linked, and identity-bearing states.
Agent identity governance must be evaluated at the point where Entra ID begins, not where the registry starts. The article makes clear that the registry is a management plane, not the identity plane. That means access assurance, ownership attestation, and offboarding logic all begin later than many teams assume. The practical conclusion is that programme maturity depends on governing the transition from record to principal.
What this signals
Registry visibility is only useful when governance can prove the principal exists. Teams should assume any discovery plane can overstate control coverage unless it is reconciled against the identity plane. For agent programmes, that means inventory, onboarding, and access review need separate checkpoints rather than one shared status.
Entra ID creates the control boundary, so the programme question is whether teams can prove linkage, not just presence. A registered agent that is not linked to an Entra Agent ID cannot be treated like a governed principal. Mature identity programmes will test for that linkage explicitly before they allow lifecycle or privilege decisions.
Agent governance needs a distinct state model for listed, linked, and identity-bearing objects. That state model is what prevents teams from counting management-plane visibility as access-plane control. For IAM leads, the next step is to make that distinction visible in policy, workflow, and audit evidence.
For practitioners
- Define separate lifecycle states for registration and identity creation Document at least three states for agents in policy and workflow design: registered, linked to Entra Agent ID, and identity-bearing. Use those states to drive approvals, recertification, and escalation paths instead of relying on a single inventory status.
- Block governance sign-off on unlinked registry entries Require a human review step whenever a registry record lacks an Entra Agent ID. Treat that condition as an incomplete control state, not as a finished onboarding event.
- Align access reviews to the Entra ID object Make the identity object the review target for permissions, ownership, and lifecycle actions. The registry should support discovery and context, but not replace the access-bearing principal in governance workflows.
- Reconcile registry views with identity issuance logs Compare registry records against identity creation events so teams can spot agents that were catalogued but never instantiated as governed identities. Use mismatches as exceptions for investigation and cleanup.
Key takeaways
- The article shows that agent registry entries and Entra Agent IDs are different objects, and only the latter carries the identity boundary needed for governance.
- Visibility in the management plane can create false confidence if teams do not verify whether an agent is actually linked to an identity object.
- Practitioners should separate discovery, registration, and identity issuance so review, ownership, and lifecycle controls attach to the correct layer.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article separates registry records from the identity layer that actually authenticates agents. |
| NHI-05 — Overprivileged NHI | Identity confusion can let teams govern the wrong object and miss the real access-bearing principal. | |
| Recommendation — Treat registry presence as inventory only and verify the Entra identity boundary before any access governance. Anchor privilege review to the Entra Agent ID object rather than the discovery record. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The topic is about where authorization control actually attaches for agent identities. |
| Recommendation — Verify that permissions and entitlements are assigned only after the identity object exists. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Agents and service-like principals need identity binding before they can be governed as authenticating entities. |
| Recommendation — Apply IA-9 to ensure service and agent identities are established before access decisions. | ||
| NIST Zero Trust (SP 800-207) | Identity governance — Identity governance | Zero trust depends on the correct identity boundary, not on discovery-plane visibility. |
| Recommendation — Separate discovery functions from identity assurance in zero trust governance. | ||
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.
- Discovery Plane: The layer where objects are catalogued, described, and made visible to administrators. Discovery supports governance, but it is not the same as identity creation, so practitioners must avoid treating inventory completeness as proof of access control.
- Identity layer: An identity layer is the shared policy and trust model that sits across applications and data sources. It connects authentication, claims, access rules, and revocation into one control plane so organisations can enforce consistent decisions across fragmented environments.
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 building or maturing an identity security programme, it is worth exploring.
Published by the NHIMG editorial team on July 14, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org