Blueprint Inheritance Abuse in Entra Agent ID

September 7, 2026

Turning an approved blueprint into a rogue cloud identity. Well, I do not need to exploit Microsoft Graph, nor do I need to register an obviously malicious OAuth application or ask an administrator to approve a new set of permissions. If I compromise the right identity within the Entra Agent ID management plane, I can use an Agent Identity Blueprint the organization already trusts to provision a new Agent Identity and have Entra issue a valid token with permissions the tenant previously approved.

This is Blueprint Inheritance Abuse.

The attack abuses trust relationships, administrative ownership, OAuth consent, and a legitimate provisioning workflow. Instead of dropping malware on an endpoint, the attacker operates inside the identity control plane. Instead of creating persistence through a service or scheduled task, the attacker leaves behind a new service principal. Instead of bypassing authentication, the attacker makes Entra authenticate the rogue identity normally.

Note: An attack sample for this scenario will be available soon in the Cloud Security Toolkit inside the Offensive-Operations.

The new Agent ID attack surface

Entra Agent ID introduces identity objects designed for AI agents. An Agent Identity Blueprint serves as a template for creating, authenticating, and governing a family of agents. Multiple Agent Identities can be provisioned from the same blueprint. Each instance receives its own identity object while retaining a relationship with the parent blueprint.

The model contains several relevant components.

Agent Identity Blueprint representing the agent template
Agent Identity Blueprint Principal representing that blueprint inside a tenant
Agent Identity represented as a service principal
Owner with administrative control over the blueprint or principal
Sponsor representing business accountability
OAuth grants and app role assignments defining approved access
Inheritable permissions defining which resource applications can pass permissions to child agents
blueprintId linking an Agent Identity to its parent blueprint
agentType distinguishing blueprints, agent instances, principals, and agent users in audit data

From an offensive perspective, this is an attack surface where human identity, workload identity, OAuth, and AI governance meet. A weak control at one layer can turn an automation-approved permission into a quiet access path for an attacker.

The permission mechanism behind the attack

Two permission configurations matter.

requiredResourceAccess declares the APIs, delegated scopes, and application roles that the agent expects to use. Administrators can review this declaration during onboarding. The declaration does not grant access by itself.

Inheritable permissions define which resource applications can pass approved permissions to Agent Identities created from the blueprint. Inheritance requires a permission grant on the local Blueprint Principal and the relevant resource application must be configured as inheritable.

When these conditions are satisfied, Entra calculates the effective permissions during token issuance, and then the delegated scopes can appear in the scp claim, and the application permissions can appear in the roles claim.

The visibility gap is valuable to an attacker because inherited permissions are not displayed as direct permissions on the Agent Identity in the Entra admin center or through Microsoft Graph. Entra merges inherited and directly assigned permissions when the token is issued. A defender inspecting only the new service principal can see an almost clean object, even though its token already carries real access.

This can be viewed as consent laundering. The attacker does not obtain fresh consent for the rogue identity. The attacker reuses consent granted to the trusted parent.

Attack chain

Stage 1: Initial access and session theft

The attacker’s primary target is not necessarily a Global Administrator, since the authority required to abuse the Agent ID provisioning workflow may exist through narrower and less closely monitored administrative relationships. More valuable targets can include an owner of an Agent Identity Blueprint, an owner of the corresponding Blueprint Principal, a user assigned the Agent ID Administrator role, or an automated provisioning workload authorized through AgentIdentity.CreateAsManager. Compromising one of these identities can provide sufficient control to enumerate approved blueprints, create child Agent Identities, and operate inside the Agent ID management plane without obtaining a highly privileged directory role.

Initial access can be established through AiTM phishing, browser session cookie theft, refresh token compromise, OAuth token theft, exposure of an automation credential, or control of a privileged management endpoint used by the blueprint owner or provisioning service.

In an AiTM operation, the attacker relays the victim’s authentication to Microsoft Entra in real time, captures the resulting authenticated browser session, and replays that session against the Entra administrative plane or Microsoft Graph. Because the victim has already completed the required MFA challenge, the attacker inherits the authenticated session state and can perform authorized management operations until the session is revoked, Conditional Access reevaluates access, or identity risk controls interrupt the activity.

A sponsor reference alone does not provide the authority required to execute this attack because sponsorship represents business accountability and lifecycle responsibility rather than automatic administrative control over the Agent Identity Blueprint. The practical attack path requires ownership of the blueprint or its principal, assignment of a relevant Microsoft Entra role, possession of an appropriate Microsoft Graph permission, or control of a provisioning workload that already holds the required application authority.

This distinction makes ownership and delegated management relationships critical targets for investigation, particularly in environments where security monitoring remains focused on privileged directory roles while overlooking specific object controls.

Stage 2: Blueprint and permission discovery

After gaining access, the attacker performs cloud discovery. The operator maps Agent Identity Blueprints, Blueprint Principals, owners, sponsors, credentials, OAuth grants, app role assignments, and inheritable permission settings.

The objective is to find a blueprint already connected to a valuable resource. Microsoft Graph is the obvious target, but an internal API, a SharePoint Embedded deployment, an Azure resource, or an enterprise SaaS application can expose equally useful data.

An attractive blueprint often has several characteristics.

Many existing Agent Identities
Broad read access to Microsoft 365
Deployment across multiple teams or environments
Predictable naming conventions that can be copied
Dynamic consent or grants that expanded over time
Automated provisioning without approval for each new instance
An owner whose routine activity provides behavioral cover

The attacker is not simply looking for the most privileged blueprint. The best target offers the strongest combination of access, stealth, and persistence.

Stage 3: Privilege abuse in the management plane

This is privilege abuse, therefore the attacker does not acquire a stronger role. The compromised session or workload already holds the authority to enumerate the blueprint, invoke provisioning, and modify identity objects. The operator simply exercises those existing privileges for an unauthorized purpose, and before session revocation, Conditional Access, or risk controls can intervene.

Blueprint ownership is the quiet path. Under the Entra Agent ID model, an owner of a blueprint or its Blueprint Principal can create and manage child Agent Identities without holding any Agent ID role. So an organization can lock down Global Administrators and Privileged Role Administrators, yet leave the same operational power exposed through an ownership relationship almost no one monitors.

Automated provisioning is even more durable. A workload identity needs no browser, no user-driven MFA, and no interactive sign-in to trigger. If the attacker controls a client secret, a certificate credential, a Federated Identity Credential, a Managed Identity, or a deployment service principal, they can invoke provisioning directly. This shifts the hunt away from user compromise and toward credential exposure, federation-trust abuse, and the automation pipelines authorized to create agents.

Stage 4: Rogue Agent Identity Provisioning

Using the authorization inherited from the compromised owner, administrator, or provisioning workload, the attacker submits an authenticated Microsoft Graph request to create a new Agent Identity and supplies the required displayName, agentIdentityBlueprintId, and sponsor reference. Entra processes the request through the legitimate Agent ID provisioning workflow, creates a new service principal with the Agent Identity type, and records the parent relationship through blueprintId, which makes the rogue instance structurally consistent with other agents created from the same blueprint.

Defense evasion is embedded in the provisioning process because the attacker can shape the identity to match the organization’s established deployment patterns rather than introducing an obviously foreign object.

The new displayName can imitate a production agent through a minor version change, regional identifier, environment label, or temporary deployment suffix, while the creation time can be aligned with a normal release window and the sponsor reference can point to a legitimate user or supported group associated with the business function. When these attributes are examined in isolation, the resulting service principal may appear to be another approved agent instance rather than controlled persistence.

The attacker does not need to modify the parent blueprint, introduce a conspicuous direct OAuth grant, or register an unrelated application with an unfamiliar publisher and permission profile.

By provisioning the rogue identity through an approved Agent Identity Blueprint, the operator reuses an identity factory that already exists within the tenant, inherits its administrative legitimacy, and may receive effective permissions during token issuance, without creating the permission changes that defenders commonly associate with OAuth application abuse.

Stage 5: Token minting and permission inheritance

Now the permissions activate. The attacker starts the appropriate auth flow and requests an access token for a resource configured as inheritable. Entra performs the permission merge at issuance and computes the new identity’s effective access.

The resulting token can carry both direct permissions and permissions inherited from the Blueprint Principal, scp and roles claims populate accordingly. The resource never sees an exploit. It receives a signed bearer token issued by Entra for a recognized agent identity and honors it like any other.

This is living off the identity plane: the attacker leverages the provider’s own authentication, authorization, and token-issuance systems rather than trying to bypass them.

Stage 6: Collection through Microsoft Graph

Once the Rogue Agent Identity obtains an access token, the attacker can begin tenant reconnaissance and data collection within the authorization boundaries represented by the token. The effective access is determined by the delegated scopes in the scp claim, application permissions in the roles claim, permissions assigned directly to the Agent Identity, grants inherited from the Blueprint Principal, and any specific resource authorization controls enforced by Microsoft Graph or the underlying Microsoft 365 service.

Read access alone can provide substantial operational value to an attacker because Microsoft Graph exposes a structured view of identities, relationships, collaboration services, and organizational content.

Depending on the effective permissions, the operator can enumerate users, identify privileged or high-value accounts, map group membership, reconstruct reporting relationships, discover SharePoint sites, locate OneDrive repositories, collect business documents, and search accessible content for API keys, credentials, internal URLs, architecture diagrams, incident reports, or other sensitive material that can support later stages of the intrusion.

Microsoft Graph effectively becomes a cloud-native reconnaissance and collection interface, allowing the attacker to query the tenant via standard HTTPS requests without scanning network ranges, opening inbound connections, or deploying traditional post-exploitation tooling on an endpoint.

Because the traffic is directed toward a legitimate Microsoft service and originates from a recognized Agent Identity carrying a valid issued token in Entra, individual requests may resemble expected automation unless defenders correlate the activity with the recent creation of the identity, its parent blueprintId, the originating principal, and the resulting resource access pattern.

Microsoft prevents Agent Identities from receiving several high-risk permissions, including Application.ReadWrite.All, RoleManagement.ReadWrite.All, User.ReadWrite.All, and Directory.AccessAsUser.All, which constrains some direct privilege escalation and takeover of tenant paths.

These restrictions do not eliminate the risk created by broad delegated or application read permissions, since tenant-wide visibility into identities, files, sites, related to mail data, or organizational relationships can still expose sensitive information, enable targeted social engineering, support credential discovery, and prepare the attacker for a more focused follow on to the compromise without requiring complete administrative control.

Stage 7: Exfiltration and command and control

After completing discovery and collection, the attacker can transfer selected data to controlled infrastructure, an external cloud storage service, or an API endpoint designed to resemble an approved business integration. Rather than generating a sudden increase in download volume, the operator can pace requests across longer intervals, preserve expected Microsoft Graph pagination behavior, reuse a user agent associated with a legitimate SDK or production agent, and divide the collected content into smaller transactions that remain close to the established workload baseline.

This approach allows the exfiltration activity to blend into normal service to service communication while reducing the effectiveness of detections based primarily on request volume, transfer spikes, or isolated destination reputation.

If the compromised agent can invoke external tools or communicate with MCP servers, a controlled MCP endpoint or a compromised tool integration can provide both tasking and data-egress capabilities.

The tool channel can instruct the agent to enumerate specific resources, retrieve selected records, transform the results, and return them through an interface that appears to be part of the agent’s expected workflow. Prompt injection is not a prerequisite for Blueprint Inheritance Abuse, since the attacker already controls the relevant identity or provisioning path, but it can extend the attack by manipulating a legitimate agent to exercise inherited permissions on the attacker’s behalf.

Traditional EDR controls may have no malicious process, executable, or persistence mechanism to terminate because the operation spans the identity provider, cloud workload, Microsoft Graph, MCP integration, and target data service.

Its focus on the endpoint security program may detect the initial browser compromise or credential theft but remain blind to subsequent token issuance, service principal activity, API-based data collection, and cloud-native exfiltration, leaving the most damaging stages of the attack outside the endpoint detection boundary.

Stage 8: Persistence through a nonhuman identity

A Rogue Agent Identity establishes durable cloud persistence by transferring the attacker’s access from a compromised human session into an independently managed nonhuman identity. Once the service principal has been provisioned, its lifecycle is no longer directly tied to the user account used during the initial compromise, which means that resetting the victim’s password, revoking browser sessions, enforcing another MFA challenge, or closing the original phishing incident does not automatically remove the newly created identity.

If the attacker also controls a valid client secret, certificate, federated identity credential, managed identity relationship, or another supported authentication mechanism, the rogue agent can continue requesting access tokens until defenders explicitly disable the Agent Identity, remove its credentials, revoke the relevant authorization grants, or disable the parent blueprint.

The potential blast radius extends beyond the malicious instance because a single Agent Identity Blueprint can serve as the parent of numerous production agents that share the same authentication configuration, permission model, and operational workflow.

Disabling the blueprint can prevent all associated Agent Identities from authenticating, including legitimate agents that support critical automation, creating a containment dilemma between immediately terminating attacker access and preserving essential services. An attacker can exploit this operational dependency as a form of resilience, knowing that defenders may delay aggressive remediation while they identify affected child identities, validate business impact, rotate credentials, and separate the rogue instance from trusted production workloads.

Tenant boundaries and attack expansion

Permission inheritance in Microsoft Entra Agent ID is evaluated within the security boundary of the tenant in which the Agent Identity Blueprint Principal exists, which means that a multitenant blueprint does not create a shared authorization context across every organization where it is deployed. Each tenant provisions its own local Blueprint Principal, and all consent records, OAuth permission grants, app role assignments, credentials, and inheritable permission configurations are bound to a specific object.

As a result, an Agent Identity created in Tenant 1 can only receive the effective permissions associated with its local parent relationship and cannot automatically inherit a grant assigned to a separate Blueprint Principal in Tenant 2.

Expanding the attack into another tenant therefore requires an independent authorization path rather than transitive permission inheritance. The attacker would need to compromise an owner, administrator, or provisioning workload in the target tenant, gain control of an existing local Agent Identity derived from the same multitenant blueprint, or reach a resource that was explicitly configured to trust the external identity.

The resulting activity should be classified as a cross-tenant pivot through an established trust chain, where the attacker abuses separately instantiated identity objects and locally approved authorization relationships, rather than as direct permission leakage between tenants.

Why the SOC can miss the chain

The evidence is distributed across multiple telemetry sources.

Initial access appears in user sign-in logs. The management action can appear in audit logs. Agent creation appears as an Add service principal event. The family relationship is stored in blueprintId. The identity class is stored in agentType. Effective permission is visible in the issued token. Data access appears in Microsoft Graph activity, the Unified Audit Log, SharePoint, OneDrive, or the target application.

When each source is investigated independently, the attacker appears as several legitimate events rather than a single attack chain.

Important agentType values include the following.

agenticApp for an Agent Identity Blueprint
agenticAppInstance for an Agent Identity
agentIdentityBlueprintPrincipal for the Blueprint Principal
agentIDuser for an agent user account

Detection should start with relationships rather than display names.

Offensive detection logic

A single analytic is not enough. Detection requires correlation across the identity control plane and data plane.

Owner or Agent ID Administrator sign-in from a new device or unusual IP address
Risky authentication followed by Agent Identity provisioning
agenticAppInstance created by a user who has no history of creating agents
New Agent Identity associated with a blueprint holding broad Graph permissions
Display name highly similar to an existing production agent
Owner, sponsor, credential, or inheritance setting changed shortly before creation
Token issued to a new agent minutes after provisioning
Immediate Microsoft Graph enumeration or file collection
Abnormal number of identities created from the same blueprintId
Agent created outside an approved change window
New identity followed by a sharp increase in SharePoint or OneDrive access
Multitenant blueprint appearing in a tenant without a documented deployment

Useful correlation fields include initiatedBy, agentType, Agent Identity object ID, blueprintId, resource application, source IP, credential identifier, and token issuance time.

Attack tactic mapping

Phase	Offensive concept	Activity
Initial compromise	Initial Access	Adversary in the middle, session theft, or credential compromise
Authority use	Privilege Abuse	Compromised owner, administrator, or provisioning workload
Environment mapping	Cloud Discovery	Blueprints, grants, owners, sponsors, and inheritance settings
Object creation	Defense Evasion	Rogue agent named like a legitimate production instance
Durable access	Persistence	Agent Identity service principal and associated credential
Permission activation	Token Minting	Access token containing inherited effective permissions
Data access	Collection	Microsoft Graph, SharePoint, OneDrive, and Microsoft 365 data
Data removal	Exfiltration	HTTPS, external API, cloud storage, or tool integration
Environment expansion	Cross Tenant Pivot	Local principal, local provisioning authority, or explicit trust

Hardening and containment

The first control is least privilege at the blueprint level. A resource application should not be marked inheritable merely to reduce consent work. Every inheritable grant increases the blast radius of every future Agent Identity.

Separate blueprints by environment, sensitivity, and business function. An agent reading executive documents should not share a blueprint with a support or development agent.

Owners, Agent ID Administrators, and provisioning workloads need phishing-resistant authentication, strict Conditional Access, workload identity protection, and controlled administrative endpoints. Protecting Global Administrators alone does not cover this attack surface.

Every new Agent Identity should enter an approval workflow that exposes the parent blueprint, creator, sponsor, credential, effective permissions, target resources, and expiration date. Security teams also need a continuous inventory connecting blueprints, principals, child identities, owners, sponsors, credentials, and grants.

During incident response, deleting the suspicious Agent Identity is not enough.

Disable the Rogue Agent Identity
Remove secrets, certificates, and Federated Identity Credentials
Revoke tokens where supported
Review every Agent Identity sharing the same blueprintId
Remove unnecessary OAuth grants and app role assignments from the Blueprint Principal
Investigate owner and sponsor changes
Review Graph, SharePoint, and OneDrive activity from the identity creation time
Disable the blueprint when the blast radius remains unknown
Review other tenants where the same multitenant blueprint is installed

Disabling a blueprint prevents its child identities from authenticating. This is strong containment with potentially significant business impact. The dependency must be documented before an incident, not discovered during one.

Conclusion

Blueprint Inheritance Abuse does not defeat Entra ID. It makes Entra execute the attack through trust, consent, and provisioning the organization has already approved.

From my position as the attacker, the target is not only an administrator account. The target is the identity factory. If I control the blueprint owner, the provisioning service, or a usable blueprint credential, I can create a new Agent Identity that appears to be part of an approved family. Entra issues a valid token. Microsoft Graph accepts it as a legitimate workload. The SOC sees a new object, but it may not see the permissions merged into that identity during token issuance.

This is the shift from endpoint persistence to identity persistence, from malware to OAuth, and from account compromise to abuse of an Agent Identity trust chain.

References

This is a research scenario and it is not a confirmed vulnerability. This article models an attack chain built entirely on penetration and simulations on production environments.