Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

Agent identity permission inheritance in Microsoft Graph: what breaks?


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 11936
Topic starter  

TL;DR: Microsoft Graph metadata shows that agentIdentity inherits servicePrincipal structure while runtime enforcement still strips or rejects credential use, role assignment, and permission inheritance behaviour, according to Semperis. The gap between schema and runtime makes agent identity governance a control problem, not just a modelling exercise.

NHIMG editorial — based on content published by Semperis: Exploring the Microsoft Graph data model and agent identity permissions

By the numbers:

Questions worth separating out

Q: How should teams validate permissions for agent identities in Microsoft Graph?

A: Teams should validate the effective permission set by querying live API behaviour, not by trusting inherited schema alone.

Q: Why do agent identities create governance gaps in Entra ID?

A: They create gaps because many IAM processes assume the object model tells the full access story.

Q: What breaks when an agent is treated like a normal service account?

A: What breaks is the assumption that the account only performs one bounded function.

Practitioner guidance

  • Validate effective permissions at runtime Query live agent identity behaviour across beta and v1.0 endpoints, then compare returned grants, role assignments, and rejected operations to the schema view.
  • Audit blueprint-level inheritance paths Inventory all inheritable app role assignments and delegated grants on agent identity blueprints, then trace which child identities receive them at token issuance time.
  • Test user-shaped controls against agentUser Review group membership, role assignment, and collaboration workflows to confirm that agentUser is handled as a subtype and not as a generic human user.

What's in the full article

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

  • Step-by-step walkthrough of the Microsoft Graph metadata relationships behind agentIdentity and agentUser.
  • Detailed examples of how inheritable permissions flow through blueprints, delegated grants, and app-only permissions.
  • Endpoint-by-endpoint discussion of where v1.0 and beta metadata diverge in the agent identity model.
  • Practice checkpoints for assigning permissions to agent identities in Entra ID.

👉 Read Semperis' guide to Microsoft Graph agent identity permissions →

Agent identity permission inheritance in Microsoft Graph: what breaks?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 2 months ago
Posts: 11491
 

Schema inheritance is not a governance control. The article shows that Microsoft Graph can describe object structure accurately while still leaving defenders blind to the runtime restrictions that decide what an agent identity can actually do. That means the governance problem is not object modelling, it is effective permission verification. Practitioners should treat schema as a discovery layer and nothing more.

A few things that frame the scale:

  • 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, according to Ultimate Guide to NHIs.

A question worth separating out:

Q: Who should own access reviews for agent identity blueprints?

A: Blueprint owners and IAM governance teams should own them jointly, because inherited permissions flow from the blueprint principal into every agent created from it. Review the parent entitlement set, not just the derived object, and verify which grants are effective at runtime. That is the only way to avoid certifying inherited access as if it were local access.

👉 Read our full editorial: Microsoft Graph exposes agent identity permission inheritance gaps



   
ReplyQuote
Share: