Agent registry visibility does not equal Entra ID identity creation

At a glance

What this is: This is a practice checkpoint explaining that Microsoft’s Agent Registry creates discovery and management records, but not an Entra Agent ID unless the identity layer is explicitly established.

Why it matters: IAM teams need to separate inventory from identity proofing and authorization, or they will misread agent visibility as governance coverage across NHI and emerging autonomous workflows.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Semperis's guide on Microsoft Agent Registry and Entra ID agent identity

Context

Agent registry records and identity records are not the same thing. In Entra ID, a management or discovery plane can hold metadata about an agent while the actual identity layer remains separate, which matters because policy, authorization, and lifecycle controls attach to the identity object, not the directory listing.

That distinction is familiar to IAM teams that have already dealt with service principals, workload identities, and other non-human identity patterns. If teams treat registry presence as proof of identity creation, they risk overestimating control coverage and underestimating where access can still be granted, linked, or left dangling.

Key questions

Q: How should teams govern agent registry records that do not yet have an identity object?

A: Treat them as incomplete identity states, not as harmless metadata. A registry entry without a linked identity object should be tracked separately, ownership should be explicit, and no access should be assumed until the identity layer is created and validated. That prevents inventory from being mistaken for enforceable authorization.

Q: Why does separating discovery from identity matter for IAM teams?

A: Because security controls attach to the identity object, not to the descriptive record. Discovery tells you what exists, while identity tells you what can be authorised, reviewed, and revoked. If those layers are conflated, teams overestimate governance coverage and miss gaps in access enforcement.

Q: What do security teams get wrong about agent registration in Microsoft environments?

A: They often assume that registration creates an identity and that visibility implies control. In reality, a registry can hold metadata without creating the enforceable identity layer, so teams must verify linkage, ownership, and permission boundaries before treating the agent as governed.

Q: Who should own the lifecycle of a registered agent?

A: The team responsible for the identity object should own the lifecycle, because that is the layer where access, policy, and revocation are actually enforced. Registry administrators may maintain records, but they should not be the sole source of truth for identity governance.

Technical breakdown

Agent registry metadata versus Entra Agent ID

A registry is an inventory and governance surface. It captures descriptive properties such as display name, owner, creator, timestamps, and optionally a blueprint or agent card, but those fields do not themselves establish a security principal. An Entra Agent ID is the identity object that can participate in authorization, policy evaluation, and lifecycle operations. In practice, this split mirrors a common IAM pattern: discovery first, identity second. That distinction matters because governance teams often assume that any managed object is already an enforceable identity, when in fact metadata can exist without a usable access boundary.

Practical implication: validate whether each recorded agent actually has an identity object before you assign permissions, reviews, or ownership.

Why /copilot/agentRegistrations permissions matter

Calling the registration endpoint requires AgentRegistration.ReadWrite.All, which means the ability to create or update registry entries is itself a privileged action. That permission governs who can introduce new agent records into the management plane, enrich them with metadata, or create records that may later be linked to identity objects. For identity teams, the security question is not only who can use the agent, but who can create or mutate the authoritative record that other tools and administrators will trust. When the registry and identity layer are separated, write access to the registry becomes a governance choke point.

Practical implication: review registry-write permissions as a privileged control surface, not as a simple administrative convenience.

Linked and unlinked agent records create different governance states

A registry entry with an Entra Agent ID and a registry entry without one are materially different states. The first can be tied to identity governance workflows, while the second is only a managed object in the discovery plane and may not yet be enforceable in the same way. That creates a classic lifecycle ambiguity: teams may believe an agent is onboarded, while it is only documented. The result is uneven policy application, incomplete accountability, and the potential for shadow AI-like drift in administrative records even when the agent itself is not yet fully provisioned.

Practical implication: define a separate control state for unlinked agent registrations and require explicit remediation before access is granted.

NHI Mgmt Group analysis

Registry visibility is not identity governance: A record in an agent registry documents an object, but it does not by itself establish the identity that security policy can control. That separation is useful only if practitioners treat the registry as discovery and Entra ID as the authoritative identity boundary. The implication is that governance reports based on registry counts can materially overstate actual control coverage.

AgentRegistration.ReadWrite.All is a privileged governance choke point: The ability to create or alter agent registrations determines which objects enter the management plane and how they are described. That means registry-write permission is not a low-risk administrative setting. It is the control that decides which agents become visible, linkable, and potentially trusted by downstream processes.

Unlinked agent records are an offboarding and accountability problem in waiting: A registry entry without an Entra Agent ID creates a documented object that has not yet reached the identity state needed for full governance. That gap can confuse ownership, lifecycle status, and enforcement readiness. The practitioner lesson is to treat unlinked registrations as incomplete identity work, not as harmless placeholders.

Discovery-plane governance must be treated as part of the NHI lifecycle: Agent registries, service principals, and other non-human objects all create a lifecycle question before they create an access question. Ownership, creation provenance, and identity linkage need to be valid before policy can be meaningfully enforced. The practitioner conclusion is that inventory workflows and identity workflows must be joined, but never conflated.

Named concept, registry-to-identity gap: This guide exposes a registry-to-identity gap where an administrative record exists without the corresponding enforceable identity object. That gap is small in wording and large in consequence because it invites false confidence in coverage, especially when teams scale agent onboarding. The practitioner implication is to build controls around linkage status, not just record existence.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing how slowly remediation can lag behind discovery events.
• This visibility gap is why practitioners should review 52 NHI Breaches Analysis alongside registry and lifecycle workflows, not after them.

What this signals

Registry-first programmes tend to overcount governance maturity. Once teams can enumerate agents, it is easy to mistake visibility for control. The more useful programme signal is linkage quality, because the identity boundary is where ownership, policy, and revocation become enforceable, not where objects are merely catalogued.

When agent governance scales, registry records should be treated like onboarding evidence, not as proof of complete control. That distinction will matter more as agent populations grow and teams need consistent lifecycle states across human, workload, and AI-derived identities. The right programme metric is not how many objects are listed, but how many are truly enforceable identities.

For practitioners

• Separate discovery from identity state Track agent registry entries and Entra Agent IDs as distinct lifecycle states. Require a linkage check before any permissions, attestations, or operational trust are assigned to the agent.
• Review registry-write permissions as privileged access Treat AgentRegistration.ReadWrite.All as a high-impact control because it governs who can create, change, or enrich the records that the rest of the programme will rely on.
• Flag unlinked registrations for immediate follow-up Create an operational queue for registry records that do not map to an Entra Agent ID so ownership, onboarding status, and policy enforcement do not drift apart.
• Align lifecycle ownership to the identity layer Assign accountability to the team that can actually provision, review, and revoke the identity object, not only the team that can document the agent in the registry.

Key takeaways

• Agent registry entries and Entra Agent IDs are different governance states, and confusing them creates false confidence.
• Registry-write permission is a privileged control because it determines which agent records enter the trust chain.
• Teams should govern linkage status, ownership, and lifecycle completion before treating a registered agent as secure.

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.
• Linkage Status: The state that shows whether a registry record is connected to the underlying identity object. In agent governance, linkage status is the practical signal that determines whether the object is merely documented or actually ready for enforcement, review, and revocation.

What's in the full article

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

• Step-by-step agent registration flow using the Microsoft Graph endpoint and the minimum required properties.
• Screenshots showing how linked and unlinked agent records appear in the Microsoft 365 admin center.
• The exact permission requirement for registry creation and what it means for administrative access.
• The follow-on chapter path that connects registry state to how agents operate in Entra ID.

👉 The full Semperis guide shows how registry validation, linked identities, and operator workflows fit together.

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 identity security programme, it is worth exploring.