Topic starter
12/07/2026 12:16 pm
TL;DR: Semperis's analysis of Microsoft Graph finds agentIdentity inherits servicePrincipal structure in metadata while runtime enforcement still blocks credentials and some permissions. That means permission reviews have to check what the platform actually allows, not just what the schema describes.
Editorial analysis by NHI Mgmt Group, based on content published by Semperis: “Agent Identities: Design Deep Dive”.
Key questions
Q: Why do inherited permissions in agent identities create governance risk?
A: Inherited permissions become risky when a blueprint or parent object can distribute authority to present and future agents without a separate runtime check for each grant.
Q: How can security teams tell whether an agent identity permission is actually enforceable?
A: Teams should compare the object model, the token issued at runtime, and the API response for the specific operation they care about.
Q: What breaks when Microsoft Graph inheritance is used as proof of agent identity privilege?
A: The control breaks when teams assume inherited schema means inherited authority.
Practitioner guidance
- Validate effective permissions at runtime Compare Graph metadata with live token issuance and API enforcement so inherited fields do not masquerade as usable authority.
- Separate blueprint grants from direct grants Maintain a distinct inventory for inheritable app roles and OAuth grants assigned at the blueprint principal versus those set directly on each agent identity.
- Test subtype-specific restrictions Confirm which inherited servicePrincipal properties are blocked, empty, or rejected for agent identities before relying on them in automation or audit tooling.
Bottom line: Microsoft Graph can show how agent identities inherit from service principals, but that does not prove the inherited permissions are actually usable.
Glossary terms: Agent Identity, Permission Inheritance, Effective Permissions, Blueprint Principal
What's in the full article
Semperis' full analysis covers the technical detail this post intentionally leaves at the governance layer:
- The exact Microsoft Graph inheritance paths for agentIdentity, agentUser, and agentIdentityBlueprintPrincipal
- The beta-versus-v1.0 metadata differences that can cause audits to miss inherited permissions
- The runtime enforcement cases where credential fields are rejected or treated as inapplicable
- The permission inheritance flow across blueprints, direct grants, and access packages
👉 Read Semperis' analysis of Microsoft Graph agent identity permission inheritance gaps →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
12/07/2026 12:30 pm
Schema inheritance is not governance inheritance: Microsoft Graph can accurately describe object structure while still obscuring the control boundary that matters to defenders. AgentIdentity inheriting from servicePrincipal does not mean all inherited fields are functionally usable, and that difference is where many governance assumptions break. Practitioners should treat object modelling and effective authorisation as separate questions, not sequential answers.
A question worth separating out:
A: They should do both, but blueprint-level review comes first when permissions are inherited. A blueprint can act as the distribution point for app roles and delegated grants, which means one over-broad review at the parent level can silently affect every descendant agent. Review the parent when you need to bound future inherited access, then verify each child.
👉 Read our full editorial: Microsoft Graph exposes agent identity permission inheritance gaps