Microsoft’s agent identity model changes AI agent governance

At a glance

What this is: This is an analysis of Microsoft’s Entra agent identity model and its new identity objects for AI agents.

Why it matters: It matters because IAM teams now need governance patterns that account for agent runtime behaviour, delegated access, and lifecycle control across NHI, autonomous, and human identity programmes.

By the numbers:

• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Semperis's guide to Microsoft Entra agent identity objects and governance

Context

AI agent identity is emerging because traditional identity models were built for people or deterministic applications, not for software actors that can reason, choose actions, and act without interactive login. In Entra ID, that creates a governance problem for AI agent identity that looks familiar on the surface but behaves differently at runtime.

The core issue is not just naming a new object type. It is deciding how lifecycle, authentication, authorization, audit, and delegated administration work when the actor can create, use, and retire access in ways that do not map cleanly to a human account or a static service principal.

Key questions

Q: What breaks when AI agents are governed like ordinary service principals?

A: The main failure is that ordinary service-principal governance assumes a stable workload with predictable lifecycle and entitlement patterns. AI agents can inherit access from a blueprint, act through user-shaped interfaces, and change their operational state at runtime, so the control model no longer matches the behaviour. Teams need a separate governance view for the agent runtime, not just for the underlying credential object.

Q: Why do AI agent identities need lifecycle governance as well as authentication controls?

A: Because the risk is not only whether an agent can authenticate, but whether it can be created, delegated, monitored, and retired in a controlled way. If lifecycle is weak, a valid agent identity can outlive its business purpose, inherit excess access, or remain associated with old configuration. That creates the same kind of residual exposure seen in other NHI programmes.

Q: What do IAM teams get wrong about agent users and human users?

A: They often assume that a user-shaped object means a human-style identity process. In this model, the agent user is only an interface layer for services that expect a user object, while the actual execution root remains the agent identity. Treating the agent user as a person leads to the wrong review, offboarding, and privilege model.

Q: How should organisations govern AI agents that can inherit access from blueprints?

A: They should govern the blueprint as the source of inherited trust, then verify every downstream agent identity against that source before enabling production use. The key question is not only what each agent can do, but what the blueprint can propagate at scale. That is where policy mistakes become repeatable risk across the tenant.

Technical breakdown

Agent identity blueprint and runtime inheritance

An agent identity blueprint acts as the template from which agent identities are created, and it carries the shared configuration, credentials, and policy hooks for that family of agents. In this model, the blueprint can provision identities, hold federated credentials, certificates, or client secrets, and extend policy to all derived agents. That means the effective trust boundary is not the individual agent alone, but the blueprint plus its associated identities and inherited controls. For practitioners, this is a structural governance shift because a single mis-scoped blueprint can propagate access and policy mistakes across many agents.

Practical implication: Treat the blueprint as the primary control point and review inherited permissions before any agent is created.

Agent identity, agent user, and delegated access paths

The article distinguishes between the runtime agent identity and the optional agent user that lets an agent access user-type services such as mailboxes or chat. The agent identity authenticates on behalf of the agent, while the agent user is a linked user object with its own identifiers and permissions but no independent authentication. That separation matters because it creates a delegation path between machine identity and user-facing resources. In identity terms, this is a hybrid access pattern: one object runs the workload, another object satisfies application constraints that still expect a user-shaped principal.

Practical implication: Map every agent-to-user dependency to explicit approval, entitlement, and audit requirements before enabling user-facing access.

Administrative roles and control of the agent lifecycle

Microsoft’s model introduces owner, sponsor, and manager roles to split technical control from business accountability. Owners manage configuration and credentials, sponsors govern lifecycle and purpose, and managers handle the operational needs of the agent user. That separation is useful because it acknowledges that agent governance needs both technical and business oversight, but it also creates a new risk surface if role boundaries are unclear. The identity model only works if each role is constrained to what it actually needs, otherwise the governance layer becomes another privilege sprawl problem.

Practical implication: Assign lifecycle authority, technical authority, and operational authority separately and verify those boundaries during access reviews.

Threat narrative

Attacker objective: The objective is to obtain durable, policy-backed access that lets an AI agent act across enterprise services with an identity model the organisation can govern and audit.

1. Entry occurs when an AI agent is created from a blueprint and inherits credentials and policy from the parent object rather than authenticating as a conventional user.
2. Escalation occurs when the agent is allowed to call tools, request tokens, or access user-shaped services through an agent user path that expands its effective reach.
3. Impact occurs when the inherited trust model scales across many agents, making policy mistakes, excessive permissions, or weak lifecycle controls broadly reusable.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agent identity is becoming a separate governance class, not a renamed service principal. The article is right to separate agent identities from users and traditional application objects because AI agents can carry their own lifecycle, policy inheritance, and audit requirements. That changes how identity programmes think about ownership, onboarding, and revocation. The implication is that agent governance needs its own control model rather than a recycled human-IAM pattern.

Blueprint inheritance creates a new form of identity blast radius. If a blueprint can provision identities and carry credentials, then its configuration becomes a multiplier for both access and misconfiguration. This is where NHI governance and agentic AI governance converge: a single upstream object can silently define the exposure of many downstream identities. Practitioners should treat blueprint governance as a first-order control surface, not an implementation detail.

Agent user design exposes the old user-versus-workload boundary as unstable. The article shows that some agent behaviours still need a user-shaped object to satisfy legacy services, yet the authentication root remains non-human. That means the programme now has to govern a machine identity that can present through a human-compatible interface. The result is a hybrid trust model that will confuse teams unless they explicitly separate interface identity from execution identity.

Assumption collapse is the real story here: access review was designed for identities whose privilege persists long enough to be reviewed. That assumption fails when the actor is an AI agent because identity can be created, used, and retired as part of runtime execution rather than a stable employment-style lifecycle. The implication is that review cadences, ownership models, and offboarding assumptions all need rethinking for agentic actors, not just new tooling.

Role separation only helps if organisations resist re-centralising control through convenience. Owner, sponsor, and manager are useful distinctions, but they do not prevent privilege concentration if one role ends up carrying too many operational exceptions. The broader lesson is that AI agent identity governance will fail in the same way NHI governance fails elsewhere: by allowing exceptional access paths to become normal operations. Practitioners should validate role boundaries before scale creates entitlement sprawl.

From our research:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows why identity inventories struggle once machine actors scale.
• That visibility gap makes lifecycle control the priority, so 52 NHI Breaches Analysis is the right next step for understanding how exposed identities become incidents.

What this signals

Agent identity programmes will be judged by inheritance control, not just object creation. Once agents inherit credentials and policy from blueprints, the operational question shifts to whether those upstream objects are governed as carefully as the identities they spawn. In practice, that means inventorying blueprint-driven access paths alongside service accounts and workload identities, because inherited trust can expand faster than review cycles can catch up.

A useful way to frame this is as identity blast radius: the set of downstream agents that can be affected by a single blueprint, role assignment, or policy change. With NHIs outnumbering human identities by 25x to 50x, the blast radius problem is already large in machine identity programmes, and agent identity will widen it further unless governance is designed for scale.

Organisations should expect agent identity to force closer alignment between IAM, IGA, and runtime security. The more an agent can act through a user-shaped interface while remaining machine-driven underneath, the more difficult it becomes to rely on legacy access review assumptions. Teams that already struggle with service-account visibility will need stronger lifecycle evidence before they can safely govern agent identities.

For practitioners

• Inventory agent identity dependencies Catalogue which agent identities rely on blueprints, user-shaped objects, token issuance paths, and inherited policies so that the true trust boundary is visible in one place.
• Review blueprint-level permissions first Check whether blueprint configuration can provision identities, hold credentials, or extend policy in ways that create broad inherited access across many agents.
• Separate technical and lifecycle ownership Assign different people for owner, sponsor, and manager responsibilities so that configuration control, business purpose, and day-to-day operation do not collapse into one role.
• Document every user-facing agent path Record each place where an agent identity reaches mailboxes, chat interfaces, or other user-type services through an agent user object, then require explicit approval for that path.

Key takeaways

• AI agent identity is not a cosmetic rename. It is a separate governance problem with its own lifecycle, authorization, and audit requirements.
• Blueprint inheritance can multiply access errors across many agent identities, which makes the parent object the real control surface.
• If organisations keep using human-style review cycles for agentic access, they will miss the runtime window where the real risk lives.

Key terms

• Agent Identity: An agent identity is a dedicated non-human identity assigned to an AI agent so it can authenticate, request tokens, and access resources at runtime. It is governed as its own object rather than being treated like a person or a generic application principal, which changes lifecycle and audit expectations.
• Agent Identity Blueprint: An agent identity blueprint is the template from which agent identities are created. It stores shared configuration, credentials, and policy inheritance for a family of agents, making it the upstream control point that determines how access, management, and policy changes propagate across many identities.
• Agent User: An agent user is a user-type object linked one-to-one with an agent identity so the agent can reach services that require a user-shaped principal, such as mail or chat. It does not authenticate independently, so its governance depends on the parent agent identity and should not be treated like a human user account.
• Identity Blast Radius: Identity blast radius is the range of downstream accounts, services, or agents affected when one identity object, blueprint, or policy changes. In agentic environments, it describes how quickly a single control mistake can propagate across inherited access paths and create broad operational exposure.

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

This post draws on content published by Semperis: understanding Microsoft Entra agent identities and the agent identity platform. Read the original.