Microsoft Graph exposes agent identity permission inheritance gaps

At a glance

What this is: Semperis examines how Microsoft Graph models agent identities as inherited servicePrincipal objects while runtime rules still restrict credentials and certain permissions.

Why it matters: IAM and identity architects need to treat schema inheritance and enforcement as separate control planes, especially when agent identities can appear more capable in metadata than they are in practice.

Context

Microsoft Graph exposes a structural model for agent identities, but the model alone does not tell practitioners which inherited capabilities are actually usable at runtime. That matters because agent identity governance depends on the difference between what is represented in metadata and what the platform will permit through token issuance and API enforcement.

In this guide, Semperis focuses on Microsoft Entra agent identity permission inheritance and the control gap that appears when beta metadata, v1.0 metadata, and runtime behavior do not line up. The practical question for identity teams is whether their governance tooling is validating effective permissions or only reading object shape.

Key questions

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. Agent identities can show servicePrincipal relationships in metadata while runtime enforcement still blocks credentials or rejects specific operations, so the object model can overstate what the agent can actually do. Governance needs to validate effective permissions, not just inherited fields.

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. That creates a broad blast radius if the blueprint is over-permissioned or poorly reviewed. The risk is less about the existence of inheritance and more about unexamined propagation.

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. If a field exists in metadata but the platform rejects the action or returns it as unsupported, it is not an enforceable permission in practice. Effective access is what the runtime permits, not what the schema names.

Q: When should organisations review blueprint-level agent permissions instead of individual agent objects?

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.

Technical breakdown

How Microsoft Graph inheritance shapes agent identity objects

Microsoft Graph uses OData metadata to describe entity types, complex types, and inheritance. In this model, agentIdentity inherits from servicePrincipal, which means it appears to carry the broader servicePrincipal property set unless the platform applies subtype-specific rules. That distinction matters because schema inheritance tells you how Microsoft models the object, not whether every inherited property is functional. For agent identities, the metadata can expose permission relationships, owners, and other inherited fields, but practitioners still need to separate object shape from runtime authority. This is especially important in preview surfaces, where beta and v1.0 can expose different views of the same identity type.

Practical implication: Treat Graph metadata as discovery input only, then validate effective permissions through runtime testing and policy enforcement.

Why credential inheritance does not mean credential use

Agent identities inherit from servicePrincipal on paper, but Microsoft documents that some inherited properties are not applicable. The clearest example is credential data: agent identities do not have their own passwords, certificates, or client secrets, and attempts to add credentials directly are rejected by the API. That means the object can inherit the field names without inheriting the operational capability. The security lesson is that platform inheritance is not equivalent to authorization inheritance. If a control or audit process assumes that every inherited property is usable, it will overstate risk in some places and miss enforcement boundaries in others.

Practical implication: Verify which inherited fields are read-only placeholders versus enforceable capabilities before relying on them in governance or automation.

How permission inheritance works through blueprints and effective grants

The article shows that inheritable app role assignments and OAuth2 permission grants can flow from the agent identity blueprint principal to derived agent identities. That makes the blueprint a permission distribution point, not just a template. In practical terms, an administrator can approve permissions once at the blueprint level and have eligible permissions propagate to present and future agents created from it. The same article also notes that some high-risk permissions are blocked and that direct grants still exist. So the governance problem is not simply who gets a permission once, but which permission path created the effective grant and whether that path is still valid at audit time.

Practical implication: Track blueprint-level grants separately from direct agent grants so inherited authority does not disappear into the object model.

Threat narrative

Attacker objective: Exploit the gap between modeled inheritance and runtime enforcement to hide or misstate the effective permissions available to an agent identity.

1. Entry occurs through authoritative schema and permission inspection of Microsoft Graph metadata, which reveals how agent identities are modeled and linked to inherited permissions.
2. Credential or permission exposure emerges when inherited app roles or OAuth grants appear in the object model even though runtime rules restrict what the agent can actually use.
3. Escalation happens if defenders trust metadata alone and miss the difference between schema inheritance, beta-only navigation properties, and effective token-time enforcement.
4. Impact is governance failure: audit tooling, enumeration scripts, or control reviews can understate or misclassify what an agent identity can do in practice.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Malwarebytes breach 2021: SolarWinds attackers added a certificate to a dormant email security app's service principal at Malwarebytes and read internal email via Microsoft Graph.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Effective permission review must occur at runtime, not at the metadata layer: The article shows why beta metadata, v1.0 metadata, and API enforcement can present different pictures of the same identity. That creates a control blind spot for inventory, audit, and conditional access validation because the review may certify the wrong authority set. The practical conclusion is that permission assurance for agent identities belongs at enforcement time, not in static schema analysis.

Inherited permission paths create a blueprint blast-radius problem: Once a blueprint principal can distribute app roles or delegated grants, the blueprint becomes the governing surface for future agent identities. That is not just a templating issue, it is an authority propagation issue that can outlive the original review point. Identity teams should treat blueprint-level grants as a high-impact governance object with its own lifecycle and review cadence.

Agent identity governance exposes a control gap between what the directory can represent and what the platform should allow: Some permissions appear in the inheritance chain but are blocked, while others can be granted directly or through access packages. That means the real security boundary is a mix of schema, policy, and runtime checks, not any single layer. The discipline now is to validate which layer actually enforces each permission path before trusting the directory model.

Agent permissions are becoming a distinct governance class inside Microsoft Entra ID: The article shows separate treatment for agent identities, agent users, and blueprints, which means teams can no longer manage them as a simple extension of service principals or human users. That separation will matter more as automation, delegated access, and permission inheritance converge. Practitioners should build identity reviews around the actor type, not around the API object family alone.

What this signals

Blueprint-level inheritance is the governance choke point: once permissions are attached to an agent identity blueprint, the review problem shifts from one object to a family of derived identities. That means practitioners need governance that can follow authority propagation, not just object enumeration.

Permission modelling must account for subtype restrictions: the same inherited field can mean different things depending on whether the runtime treats it as supported, blocked, or inapplicable. For identity programmes, that makes schema-only inventory insufficient for access assurance.

Agent identity governance is now a separate operational discipline inside Entra ID: teams that still fold agent identities into generic service principal reviews will miss the lifecycle, permission, and enforcement differences that matter most. The safer model is actor-aware review, where the identity type determines how authority is validated.

For practitioners

• 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.
• Review access packages for agent scope Check whether access packages can propagate more privilege than the agent actually needs and validate sponsor or manager approval paths for each package.

Key takeaways

• Microsoft Graph can show how agent identities inherit from service principals, but that does not prove the inherited permissions are actually usable.
• The article highlights a governance gap between object schema and runtime enforcement, which is where misclassification and overreach occur.
• Practitioners need runtime validation, blueprint-level review, and subtype-specific checks to keep inherited agent permissions within intended boundaries.

Key terms

• 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.
• Permission Inheritance: The practice of allowing access on one object to flow into related objects through defined traversal rules. It reduces duplicate configuration, but it also creates hidden privilege paths that must be understood and reviewed. In complex systems, inheritance is often the real source of effective access.
• Effective Permissions: Effective permissions are the access an identity can actually use after role inheritance, scope, and policy are applied. In Azure AI environments, they often matter more than the assigned role name because inherited rights can widen access to data, logs, and secret stores.
• Blueprint Principal: The blueprint principal is the service principal instance created from the blueprint and used for execution and authentication. It matters because it is the operative identity in the chain, which means its permissions, logs, and lifecycle state must be reviewed separately from the blueprint object.

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