TL;DR: Microsoft Entra agent identities can combine direct app-only permissions with inheritable delegated scopes, including enumerated or allAllowed inheritance, creating a runtime access model that can expand beyond the original assignment if governance is weak, according to Semperis. The governance issue is not the API call itself, but the assumption that access boundaries stay stable once a blueprint is created.
At a glance
What this is: Semperis explains how Entra agent identities can inherit both app-only and delegated permissions, widening the effective access boundary at runtime if blueprint governance is loose.
Why it matters: IAM and NHI teams need to treat inherited agent permissions as a live authorisation problem, because the control point shifts from static assignment to runtime scope expansion.
Context
The security problem here is permission inheritance in Microsoft Entra agent identities, where direct app-only rights and delegated scopes can both flow into runtime access. That creates a governance gap if teams assume the agent’s effective privilege is identical to the original assignment made at build time.
Semperis walks through how an agent identity blueprint can grant delegated permissions, mark them inheritable, and even allow allAllowed inheritance. In practice, that means the access boundary is not just what was configured initially, but what the runtime model permits once inheritance is applied.
Key questions
Q: How should teams govern inherited permissions on Entra agent identities?
A: Treat inheritance as part of the authorisation model, not as an implementation detail. Teams should review both direct app-only permissions and blueprint-level delegated scopes, then validate the effective token output in each runtime flow. If the blueprint can inherit permissions, the review must cover the inheritance mode and the downstream access boundary together.
Q: Why do inherited scopes increase risk for agent identities?
A: Because the permissions an agent can use at runtime may be broader than the permissions originally assigned to the object. Inherited scopes can expand authorisation through delegated consent or app-role inheritance, which weakens the assumption that a created identity remains within a fixed boundary. That creates drift between nominal and effective privilege.
Q: What breaks when access reviews ignore inherited permissions on file shares?
A: Access reviews become inaccurate because they certify the top-level folder state instead of the permission path that actually grants reach. Inherited access can expose thousands of downstream files even when the parent share looks constrained. If teams do not resolve inheritance, they risk approving access that should never have been allowed in the first place.
Q: Should organisations allow allAllowed inheritance for agent identities?
A: Only when the risk of broad runtime access has been explicitly accepted and monitored. allAllowed removes the constraint that enumerated scopes preserve, so the agent can inherit whatever is available rather than a tightly bounded set. For most IAM programmes, that makes the authorisation boundary harder to predict and harder to govern.
Technical breakdown
How direct app-only permissions and inherited delegated scopes combine
The article describes two separate permission paths. First, an app role is assigned directly to the agent identity, which gives it app-only capability in its own context. Second, delegated permissions are granted to the blueprint and marked as inheritable so that downstream authentication flows can carry those scopes into runtime. When both exist, the agent’s effective authorisation is the union of the direct app role and the inherited delegated rights, not a single static grant. That creates a broader access surface than many teams expect when they think only in terms of object creation and initial consent.
Practical implication: Model agent identity access as a combined entitlement set, not a single assignment.
Enumerated inheritance versus allAllowed inheritance
Semperis highlights two inheritance modes. Enumerated inheritance restricts the agent to specific scopes such as Group.Read.All, while allAllowed permits everything that is available to inherit. The distinction matters because it changes whether governance is explicit or open-ended. Enumerated scopes preserve some intention in the permission model, while allAllowed removes that boundary and can silently widen operational access as the blueprint is reused. The technical issue is not the API call itself, but the fact that inheritance settings define the agent’s runtime ceiling.
Practical implication: Review whether inherited permissions are enumerated or open ended before the blueprint is reused.
Why inherited app roles matter in delegated authentication
The article notes that even app-only permissions can be inherited when using appRoleIds instead of scopes. That is important because it blurs the line between direct application rights and delegated flows, especially in systems where operators expect those models to stay separate. If an agent can inherit app roles as well as delegated scopes, runtime identity behaviour depends on the permission container and not just the authentication method. For identity architects, this is a governance boundary issue as much as a protocol issue, because the permission model itself becomes composable.
Practical implication: Test both delegated and app-only inheritance paths when validating agent identity permissions.
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.
- Meta AI Instagram Account Takeover: 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
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
Inherited permission blueprints create a runtime access boundary, not a static grant: Semperis shows that Entra agent identities can inherit delegated scopes and app-only rights from the blueprint as execution unfolds. That means the original assignment is only the starting condition, not the final effective privilege. For identity governance, the problem is the widening of runtime authority after the object has already been approved.
Permission inheritance is a governance control, not just a configuration detail: The difference between enumerated and allAllowed inheritance is the difference between bounded scope and open-ended authorisation drift. Once teams allow inheritance at the blueprint layer, the real control point moves from creation time to runtime scope management. Practitioners should treat that layer as part of the approval model, not as a passive implementation choice.
Agent identity authorisation now sits at the intersection of NHI governance and application permission design: These identities are not human users, but they also do not behave like classic service accounts when permissions are inherited dynamically across flows. That makes the effective access model harder to reason about with human IAM assumptions alone. The practical conclusion is that agent identities need governance that explicitly tracks inheritance semantics, not just assigned permissions.
Identity review processes must follow the effective privilege path, not the nominal one: If a blueprint can extend access through delegated consent and inherited app roles, recertification based only on the base object will miss the true blast radius. This is a classic effective-access problem in NHI governance, but it is amplified by agentic runtime behaviour. Teams should evaluate permission inheritance as part of the access review scope, not as an afterthought.
Blueprint inheritance is the named concept that matters here: This is the control pattern where an agent identity blueprint defines permission behaviour that is later inherited at runtime by the agent instance. In practical terms, the blueprint becomes an authority source, which can outlive the assumptions made when the agent was first created. That makes blueprint governance a first-class identity control surface for Entra agent identities.
What this signals
Blueprint inheritance is the control surface that teams are likely to underestimate. In Entra agent identity designs, the nominal assignment is not the whole story once delegated scopes and app-role inheritance are allowed to flow into runtime. Practitioners should map the effective permission path, not just the object record, before they rely on recertification or least-privilege reviews.
Runtime access for agent identities now depends on how permission inheritance is expressed. Enumerated inheritance preserves an auditable boundary, while allAllowed creates authorisation ambiguity that can outgrow the original blueprint. Identity teams should expect this pattern to show up wherever agent identities are reused across multiple flows or applications.
For practitioners
- Audit inherited permission settings Inventory every agent identity blueprint that can pass permissions into runtime flows, then separate direct app-only grants from inheritable delegated scopes so you can see the full effective access path.
- Restrict open-ended inheritance Replace allAllowed inheritance with enumerated scopes wherever possible, and review any blueprint that can inherit both scopes and appRoleIds because that combination broadens the authorisation boundary.
- Validate effective privilege in tokens Test the tokens produced by delegated and app-only flows to confirm that the runtime permission set matches the intended blueprint boundary, not just the original assignment record.
- Recertify blueprint-level access Include inheritable permissions in access reviews for agent identities so reviewers validate the blueprint, the inheritance mode, and the downstream scopes together.
Key takeaways
- Entra agent identities can inherit permissions beyond their initial assignment, so the real access boundary is defined by runtime inheritance as much as by the object itself.
- Semperis shows that both delegated scopes and app-only roles can be inherited, which widens the gap between nominal permission and effective privilege.
- Teams need access reviews that validate inheritance mode, effective tokens, and blueprint-level governance rather than relying on the original grant alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Inherited permissions can expand effective access beyond the original agent assignment. |
| NHI-04 — Insecure Authentication | The article focuses on how agent authentication flows carry inherited permissions into tokens. | |
| NHI-09 — NHI Reuse | Blueprint-level inheritance encourages repeated permission patterns across agent instances. | |
| Recommendation — Review agent blueprint inheritance settings and constrain any runtime privilege that exceeds the intended scope. Validate authentication flows to ensure inherited permissions do not widen trust beyond the intended identity boundary. Track reused agent blueprints and re-assess inherited rights before each new deployment. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The article is fundamentally about preventing effective access from exceeding need-to-know scope. |
| Recommendation — Apply least-privilege reviews to the effective runtime permissions, not only the original grant. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Runtime entitlements on agent identities must be governed as part of authorisation management. |
| Recommendation — Map inheritable permissions into entitlement reviews and verify the resulting authorisation set in tokens. | ||
Key terms
- Inherited Permissions: Inherited permissions are access rights passed from the authorizing user or application to a connected integration. They become risky when the granted scope is broader than the integration needs, because the downstream app can retain high privilege long after the original business need has changed.
- 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.
- Enumerated Scope: A restricted permission set in which only specific scopes are allowed to inherit. This preserves a bounded authorisation model because the runtime identity receives only the named rights, rather than every available permission exposed by the parent configuration.
- AllAllowed Inheritance: An inheritance mode that allows all available permissions to flow into the runtime identity instead of a selected subset. For agent identities, this removes a key boundary and makes the effective access set harder to predict, certify, and contain.
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.
Published by the NHIMG editorial team on July 12, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org