Microsoft Graph exposes agent identity permission inheritance gaps

At a glance

What this is: This is a technical guide on Microsoft Graph’s agent identity model, and its key finding is that schema inheritance does not guarantee runtime permission behaviour.

Why it matters: It matters because IAM teams governing NHIs, agentic AI, and human-adjacent agent users must validate effective permissions at runtime, not trust object inheritance or preview metadata.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Semperis' guide to Microsoft Graph agent identity permissions

Context

Microsoft Graph exposes the shape of Entra ID objects, but the schema alone does not tell you which permissions actually survive to runtime. In the agent identity model, that distinction matters because the same inheritance patterns that look familiar on paper can mask materially different access behaviour once the platform enforces subtype-specific rules.

For identity teams, the issue is not simply how agent identities are represented. It is how app-only permissions, delegated permissions, group membership, Entra roles, and access packages combine or fail to combine when the subject is an agent rather than a human user or a plain service principal. That makes Microsoft Graph metadata useful for discovery, but insufficient as a governance source of truth.

The article’s starting point is typical for preview-platform analysis: schema visibility is high, runtime certainty is low. That is exactly the condition that creates audit gaps in NHI and agent identity programmes.

Key questions

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. Check the child object, the blueprint principal, and any consent or role state that applies at token issuance. If beta and v1.0 return different permission pictures, treat that as a governance finding, not a documentation issue.

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. In practice, the platform may reject some inherited capabilities, allow others only through the blueprint, and handle user-shaped agents through controls that were designed for humans. That mismatch makes effective authority harder to certify than object presence.

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. A modern agent may browse, retrieve data, interact with multiple applications, and carry state across steps, so a normal service-account model can miss the broader path of privilege and the need for tighter lifecycle control.

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.

Technical breakdown

Microsoft Graph metadata vs runtime permission enforcement

Microsoft Graph metadata describes entity inheritance, navigation properties, and type relationships, but it does not guarantee that inherited capabilities are functional. In the agent identity model, agentIdentity inherits from servicePrincipal, yet Microsoft documents that some inherited properties are not applicable. That means the schema can show credentials, roles, and grants in the object lineage while the API layer still rejects or suppresses them at execution time. For defenders, this is a classic difference between structural model and effective permission state.

Practical implication: validate permissions through live API behaviour and access evidence, not metadata inheritance alone.

Agent identity blueprints and inheritable permissions

The agentIdentityBlueprintId links a modern agent identity to its parent blueprint, and the beta schema exposes inherited app role assignments and delegated OAuth grants at token issuance time. That is operationally important because the privilege decision can occur in the blueprint principal and then flow into the agent at runtime. In other words, the effective permission set is not just a property of the child object. It is the result of blueprint-linked inheritance, consent, and token issuance logic working together.

Practical implication: review blueprint-level grants as first-class entitlements, not as hidden implementation detail.

User-shaped agent identities and privilege boundary risk

AgentUser is built on the user object, which makes it more exposed to user-centric controls such as group membership, role assignment, and collaboration features. Microsoft states that certain privileged roles and credential types should not apply, but the article shows how subtype handling can be inconsistent across endpoints. The risk is not that the object is human. The risk is that a user-shaped identity can be processed by systems that forget it is an agent, creating scoping gaps around role assignment and access boundary checks.

Practical implication: test every user-facing control path against agentUser as a distinct subtype, not as a generic user.

Threat narrative

Attacker objective: The attacker wants to turn a poorly governed agent identity into a privilege bridge that yields broader tenant access than the visible object model suggests.

1. entry: The attack surface begins when defenders rely on schema inheritance or preview metadata instead of checking the live permission state of agent identities and their blueprints.
2. escalation: Effective access can expand when inherited app role assignments, delegated grants, or mis-scoped directory roles are evaluated at token issuance and consent boundaries.
3. impact: A mis-modelled agent identity can gain broader access than intended, including access to Microsoft 365 data, directory functions, or high-impact application permissions.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Agent identity blueprints create a permission inheritance surface that can outlive local review habits. When app role assignments and delegated grants flow from a blueprint principal to every derived identity, access review becomes a blueprint-level discipline, not an object-by-object cleanup task. The implication is that lifecycle controls must track inherited grants as durable entitlements, not as incidental configuration.

AgentUser is a user-shaped boundary problem, not a human identity variant. A user object that is used for an agent can inherit user-centric workflows, group logic, and role-assignment pathways that were never designed for non-human autonomy. The control gap is not missing policy in the abstract. It is the reuse of human identity assumptions in a machine-mediated identity path.

Permission scoping for agents fails when the base object is more privileged than the intended use case. The article’s examples echo a wider Entra pattern: the ability to manage an object can become the ability to control whatever authority is already attached to that object. For identity architects, that is a reminder to model effective authority, not just object ownership.

Runtime enforcement is the real trust boundary for Entra agent identities. The named concept here is the runtime permission gap: the distance between what Graph inheritance suggests and what the platform actually permits. That gap is where agent identity governance becomes fragile, and it is where practitioners should focus audit and testing effort.

From our research:

• 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.
• For a broader breach lens, the 52 NHI Breaches Analysis shows how permission drift and lifecycle gaps repeatedly turn identity objects into attack paths.

What this signals

Runtime permission verification is now a governance requirement, not a nice-to-have. When preview schemas and live enforcement diverge, access certification based on object inventory alone will miss the real risk. Teams should expect more agent-shaped identities to be discovered through behavioural testing than through directory reporting, which is why the Ultimate Guide to NHIs remains the more reliable baseline for lifecycle and visibility work.

Agent identity programmes will need a blueprint-centric operating model. As inheritable permissions spread from parent objects into derived agents, the control point shifts upward in the chain. That means entitlement review, sponsor approval, and offboarding logic must follow the blueprint relationship, not just the child object.

Human IAM processes will keep failing where they are reused unchanged for agents. A user-shaped object is not proof that human-centric controls fit. IAM leaders should expect to rework review evidence, role assignment logic, and exception handling when agent users enter the estate, especially in environments already exposed to the kind of service-account visibility gap reported in our research.

For practitioners

• 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.
• Separate object ownership from effective authority Map which Entra roles, app permissions, and access packages can actually change the permissions already attached to an agent or service principal.

Key takeaways

• Microsoft Graph can model agent identities cleanly while still leaving runtime permission behaviour ambiguous.
• Blueprint-level inheritance makes effective access broader than any single object review can show.
• IAM teams need runtime validation, not schema inspection, to govern modern agent identities safely.

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.
• 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.
• Effective Permission State: Effective permission state is the access an identity can actually exercise after inheritance, consent, role assignment, and runtime enforcement are applied. It is the only state that matters for governance, because directory schema alone can overstate, understate, or hide what the identity can truly do.
• User-Shaped Identity: A user-shaped identity is a non-human identity built on a user object so it can fit collaboration or mailbox-driven services. That shape can be useful operationally, but it is risky when human IAM controls are applied without confirming whether the identity is actually a person or an agent.

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.

👉 Semperis' full guide covers the Graph inheritance model, runtime enforcement gaps, and practice checkpoints.

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.