Inherited permissions in Entra agent identities widen runtime access

At a glance

What this is: This is a technical walkthrough of assigning direct and inheritable permissions to Entra agent identities, with a key finding that permission inheritance can widen effective access at runtime.

Why it matters: It matters because IAM and NHI teams must govern agent identity permissions as living delegation paths, not static assignments, or they will miss how access expands across flows.

By the numbers:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 5.7% of organisations have full visibility into their service accounts.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read Semperis's guide to agent identity permission inheritance in Entra ID

Context

In Entra ID agent identity design, permissions are not just attached to an object, they can be inherited through a blueprint and reused across authentication flows. That makes the primary governance problem permission propagation, not simple permission assignment, because the same agent can present different effective access depending on how delegated and app-only rights are combined.

For identity teams, this is a Non-Human Identity governance issue first and an application design issue second. The control gap is familiar: if the lifecycle, review, and offboarding process only tracks the base identity, it can miss inherited scopes that remain available long after the original use case changes.

Key questions

Q: How should teams govern AI agents that inherit human access rights?

A: Teams should treat inherited access as temporary and bounded to a specific task, owner, and expiry. The key is to govern the delegation chain, not just the agent itself, because the original human authority can persist far beyond the session that created it. If revocation cannot outrun execution, the governance model is already behind the risk.

Q: Why do blueprint-based permissions increase NHI governance risk?

A: Blueprint-based permissions create reuse and persistence. A single mis-scoped permission can flow into every agent built from that template, which makes privilege drift harder to detect and revoke. That is especially risky when the platform supports broad inheritance modes, because the effective access surface can exceed the original intent.

Q: What breaks when teams review only the agent object and not the blueprint?

A: They miss inherited access. The agent object may look clean while the blueprint still carries delegated scopes or app-only rights that survive into runtime tokens. That creates a false sense of least privilege and can leave over-permissioned access active across multiple agent instances.

Q: Who is accountable when an inherited permission grants too much access?

A: Accountability sits with whoever owns the blueprint, the permission policy, and the review process, not only the person who created the individual agent. If inherited access was allowed without explicit approval and token validation, then governance failed at the template layer and the operational layer.

Technical breakdown

Direct app-only permissions on the agent identity

Direct app-only permissions bind an application role to the agent identity itself. In the article’s example, the agent identity receives a role such as User.Read.All through appRoleAssignments, which means the token issued for that identity can carry privileges independent of a user context. In Entra ID, that is a machine-to-machine authorization pattern, not human delegated consent. The security significance is that the agent becomes a first-class privileged subject whose token content must be understood and constrained like any other NHI credential.

Practical implication: inventory direct app roles on agent identities and treat them as privileged NHI entitlements.

Inheritable delegated permissions in agent identity blueprints

The blueprint introduces a second permission path. Delegated permissions can be granted to the agent identity blueprint through oauth2PermissionGrants and then marked inheritable, so future identities created from that blueprint can receive the same scoped access. This is governance by template, which is efficient but also persistent. The article shows both enumerated scopes and an allAllowed mode, which means inherited access can be tightly bounded or broadly passed through depending on configuration.

Practical implication: review blueprint inheritance settings separately from the agent object, because effective access may originate upstream.

Enumerated scopes versus allAllowed inheritance

The distinction between enumerated and allAllowed inheritance is the core control decision. Enumerated inheritance passes only named permissions such as Group.Read.All, while allAllowed removes the scope list and effectively allows everything within that inheritance rule. The article also notes undocumented inheritance of enumerated app-only permissions via appRoleIds, which means control visibility depends on both documented and observed platform behaviour. For governance, the problem is not just whether inheritance exists, but whether the organisation can prove the resulting access surface.

Practical implication: document every permitted inheritance mode and test the token output, not just the configuration record.

NHI Mgmt Group analysis

Inherited access is the real control plane for Entra agent identities. The article shows that the effective privilege of an agent is created by both the direct app role and the inherited blueprint permission, not by one setting alone. That means reviewers who inspect only the agent object will miss the true access boundary. Practitioners should treat inheritance as the authoritative entitlement source, not a convenience feature.

Permission inheritance creates governance drift unless lifecycle ownership follows the blueprint. When delegated scopes are granted at the blueprint layer, they survive the creation of new agents and can outlast the original operational need. That shifts the risk from one-off misconfiguration to structural persistence. The implication is that access reviews must include blueprint-level inheritance and not stop at the visible identity instance.

Template-defined privilege: the article describes a model where agent capability is pre-authored into the blueprint and then instantiated repeatedly. This is efficient for operations, but it also means least privilege is no longer decided only at provisioning time. For IAM and NHI teams, the takeaway is that template governance becomes privilege governance.

Entra agent identities expose the same NHI pattern seen in service accounts: stable objects with expanding effective access. The difference is that the inheritance path can layer delegated and app-only rights in one design. That makes token review, permission lineage, and offboarding more important than the creation workflow itself. Practitioners should align agent identity governance with the same control discipline used for high-value service accounts.

Undocumented inheritance behaviour is a governance risk even when the platform accepts the request. The article’s note that app-only permissions can also be inherited through appRoleIds shows why configuration acceptance is not the same as policy assurance. If security teams do not validate the final token contents, they are trusting the request shape rather than the effective authorization state. Practitioners should require token-level verification for every permission model change.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• The 52 NHI Breaches Analysis shows how over-privileged identities repeatedly extend attacker reach once access is obtained.

What this signals

Template governance is becoming a first-class identity control for agentic environments. As agent identities inherit rights through blueprints, security teams need lineage-aware reviews that connect the object, the template, and the token outcome. That aligns with the broader NHI picture: 92% of organisations expose NHIs to third parties, according to the Ultimate Guide to NHIs, which means inherited privilege is already a supply-chain governance problem.

The practical next step is to make entitlement provenance visible in IAM reporting so reviewers can see where access originated and how it propagates. Without that, agent identity governance will keep looking complete while effective permissions continue to expand behind the scenes.

For practitioners

• Map blueprint-level permissions before agent rollout Record every delegated scope and app-only role granted at the blueprint level, then trace which agent identities inherit them in delegated and app-only flows. Use the inherited permission set as the real access inventory, not the base object alone.
• Test token contents after each permission change Validate issued tokens for both direct and inherited rights after changing appRoleAssignments, oauth2PermissionGrants, or inheritablePermissions settings. Confirm that enumerated scopes remain bounded and that allAllowed was not enabled accidentally.
• Separate blueprint review from identity review Add blueprint inheritance records to access reviews, recertification, and offboarding workflows so inherited permissions are reviewed even when the agent identity itself is unchanged. This closes the gap between object ownership and effective access.
• Restrict broad inheritance modes by policy Allow allAllowed inheritance only where a business case is explicit and approved, and require named scopes for routine agent permissions. If undocumented inheritance behaviour is present in your tenant, treat it as a control exception until tested and documented.

Key takeaways

• Inherited permissions, not just direct assignments, determine the real access boundary for Entra agent identities.
• Blueprint-level permissions can silently widen privilege across every agent created from the same template.
• Token validation and blueprint review are both required if teams want agent identity governance to match effective access.

Key terms

• Agent Identity Blueprint: An agent identity blueprint is the template that defines how new agent identities are created and what access they inherit. It matters because governance applied only to the instantiated identity can miss privileges embedded upstream in the template, where repeated access is actually determined.
• 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.
• App-Only Permission: An app-only permission is access granted to an application or agent without a human user present in the transaction. For non-human identities, app-only permissions often carry the strongest operational risk because they can be used independently of interactive approval and may persist across runtime sessions.
• Delegated Consent: The authorisation a user or administrator gives to an application to act on their behalf. Once granted, that consent can outlive a password reset or even off-boarding unless it is explicitly reviewed and revoked, creating long-lived access that security teams must govern.

What's in the full article

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

• Step-by-step MS Graph request patterns for appRoleAssignments, oauth2PermissionGrants, and inheritablePermissions.
• Token validation examples showing how direct and inherited permissions appear in delegated and app-only flows.
• Blueprint update handling with Patch requests for existing inheritable permissions.
• Practical lab workflow for building and testing agent identity permissions end to end.

👉 Semperis's full guide covers the MS Graph patterns, inheritance modes, and token checks behind the walkthrough.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.