Microsoft’s agent identity model changes AI agent governance

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Semperis's blog post: Microsoft's Entra agent identity model introduces governance changes for AI agents in identity systems.

Why it matters: It matters because IAM teams need to govern AI agents as a distinct identity class, not as user-like exceptions or repurposed service principals.

Context

Agent identity is a dedicated identity class for AI systems that can decide, use tools, and operate without an interactive human login. The security issue is not simply that agents exist, but that traditional identity models were built around users and deterministic applications, so they do not cleanly describe agent behaviour or governance requirements.

Semperis argues that Microsoft’s Entra model is an early attempt to give agents their own lifecycle, authentication, and audit constructs inside the identity plane. That makes the topic relevant to IAM, IGA, and security architecture teams that must decide whether to keep stretching existing non-human identity patterns or treat agent identity as a separate governance object.

The article is strongest where it shows that agent identities are not just renamed service principals: they have blueprint inheritance, sponsor and owner roles, and an optional agent user layer. That is a typical pattern for platform transitions, but the governance implications are more disruptive than the UI suggests.

Key questions

Q: How should teams govern AI agents without treating the model as the only control point?

A: Governance should follow the full runtime, not just the model checkpoint. Teams need approval gates for tool use, version control for prompts and procedures, isolation for sub-agents, and traceability for every governed run. If the harness changes, policy changes, even when the model does not.

Q: Why does blueprint-based agent identity increase governance risk if it is misconfigured?

A: Because the blueprint becomes the inheritance point for credentials, policy effects, and shared configuration across many derived agents. A single weak template can propagate overbroad access or poor control decisions across the population, so template review matters as much as object review.

Q: Where do access reviews fail for rapidly created and destroyed AI agents?

A: They fail when the review cycle assumes a stable identity will exist long enough to be observed and certified. If an agent is created for a short task and then removed, the governance process may never capture a meaningful review state before the access disappears.

Q: What should organisations do when an agent needs a user-shaped identity for app access?

A: Limit that pattern to cases where the target service genuinely requires a user object, then document the boundary between the agent identity and the agent user. The agent user should not be treated as a normal employee account because it does not behave like one.

Technical breakdown

Why agent identities do not fit human or service principal models

AI agents can reason, choose actions, call tools, and operate on triggers rather than interactive sign-in. That combination makes them behave differently from both human users and deterministic applications, even when they rely on familiar identity primitives underneath. A user model assumes a person, while a classic service principal model assumes an application with a fixed runtime pattern. Agent identity is a third object type because the governance problem is not just authentication, but runtime decision-making coupled to delegated access.

Practical implication: classify agent behaviour separately from both users and application identities before assigning policy, ownership, or review processes.

How blueprint inheritance shapes agent identity governance

The blueprint in Microsoft’s model acts as the shared template for agent identities and carries configuration, credentials, and inherited policy effects. In practice, that means one blueprint can govern many derived agents, and changes at the blueprint layer can cascade across the entire set. The model also introduces a central administrative role structure with owner and sponsor responsibilities, which creates explicit accountability around lifecycle actions such as disablement, deletion, and credential changes. That structure is important because it turns agent fleets into governed populations rather than isolated objects.

Practical implication: govern the blueprint as the control point, because it determines the configuration and policy posture of every derived agent.

Why agent users create a user-like access boundary without becoming human

An agent user is a specialised user-type object that lets an agent reach services that expect a user identity, such as mail or chat interfaces. It is not an independent human account, and it cannot sign in interactively or manage itself the way a person would. This hybrid design is operationally useful, but it also introduces a boundary case: the organisation now has a user-shaped object whose behaviour is entirely dependent on the parent agent identity. That means user controls cannot be applied mechanically without understanding the delegation chain.

Practical implication: treat agent users as access adapters, not as ordinary employee accounts, when designing policy, groups, and lifecycle controls.

NHI Mgmt Group analysis

Agent identity is becoming a distinct governance class, not a service principal variant. The critical change is that AI agents do not behave like deterministic applications, so the identity model built for human sign-in and static workloads no longer covers the full runtime problem. Treating agents as their own class forces IAM teams to model lifecycle, auditability, and delegation separately. The practical conclusion is that governance design must start from the identity behaviour, not from the closest existing account type.

Blueprint inheritance creates identity blast radius at the configuration layer. When credentials, policy effects, and lifecycle controls are inherited from a shared blueprint, the blueprint becomes the real control boundary. That means one mis-scoped template can replicate risk across every derived agent. The practitioner takeaway is that agent governance needs template-level review, not just object-level administration.

Accountability becomes explicit only when owner, sponsor, and manager roles are separately defined. The model matters because AI agents often sit between technical administration and business use cases, and those responsibilities are easy to blur in existing IAM workflows. Separating technical ownership from business sponsorship gives organisations a way to investigate behaviour and approve lifecycle actions without pretending the agent is a person. The conclusion is that role clarity is a control, not just an organisational chart.

Access review assumptions collapse when the identity is created for runtime action rather than long-lived use. Access review processes were designed for identities that persist long enough to be observed, certified, and recertified. That assumption fails when an agent can be created, used, and destroyed dynamically around a task. The implication is that governance must move closer to issuance and delegation time, because the review cycle may never see a stable state to certify.

Agent user design exposes a governance gap between human-shaped access and non-human execution. A user-shaped object can make integration easier, but it also tempts teams to apply human account controls to something that does not authenticate, sign in, or behave like a person. That mismatch is where policy drift starts. The practitioner conclusion is that agent users need explicit boundary rules so that convenience does not become misplaced governance.

From our research library:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
• Read next: Agentic AI Identity Guide

What this signals

Agent identity governance will force teams to redesign who gets reviewed, who gets approved, and when those checks happen. The old pattern of periodic recertification assumes an identity remains stable long enough to be observed. With AI agents, issuance and use can be tightly coupled to a task window, so the control point shifts closer to creation and delegation.

Blueprints should be treated as the unit of control for agent populations. If the template is the place where credentials, claims, and inherited policy are set, then the blueprint is where governance either scales or fails. Security teams should expect agent fleets to be managed as governed populations rather than isolated accounts.

For practitioners

• Define agent identity as its own account class Update IAM and IGA design documents so AI agents are not handled as users or ordinary service principals. Use separate lifecycle, ownership, and audit rules for agent identities and their supporting blueprints.
• Review blueprint inheritance before scaling agents Assess what authentication methods, claims, permissions, and policy effects are inherited from each blueprint before more agents are created from it. Treat the blueprint as the control boundary, not the individual agent.
• Separate technical ownership from business sponsorship Assign clear owner and sponsor roles for every blueprint and agent population, and use those roles to decide who can disable, delete, or approve changes to agent lifecycle state.
• Restrict human-account assumptions around agent users Only create an agent user where a service genuinely requires a user-shaped object, and document where interactive login, password reset, and privileged role assignment are intentionally unavailable.

Key takeaways

• AI agents are being modelled as a separate identity class because neither human accounts nor classic service principals fully describe their runtime behaviour.
• Blueprint inheritance concentrates risk because policy, credentials, and lifecycle settings can cascade from one template to many agents.
• The governance shift is toward controlling identity creation, delegation, and ownership earlier in the lifecycle, not relying on later access reviews.

Key terms

• Agent Identity: An agent identity is a dedicated non-human identity type used by an AI agent to authenticate, request tokens, and access enterprise services at runtime. In this model, the identity is governed separately from human users and from ordinary application objects because its behaviour can be dynamic and task-driven.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Agent User: An agent user is the child identity associated with an agent identity, created after the blueprint is authenticated and authorised. It is not a person, but it can still hold access and generate activity, so offboarding and attestations must cover it explicitly.
• Blueprint Inheritance: Blueprint inheritance is the propagation of configuration, credentials, claims, and policy effects from a blueprint to every agent identity created from it. It reduces manual setup, but it also means one template decision can multiply across many identities, which makes template governance a primary control point.

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