Listen to this Post
Introduction:
Microsoft Entra Agent ID introduces a hierarchical identity framework designed to govern AI agents at enterprise scale, using blueprints as master templates that can spawn multiple agent identities across tenants. However, this architectural power creates a dangerous attack surface: a single administrative consent to a malicious multitenant Agent Blueprint can establish an extensible “identity factory” within the victim tenant, enabling persistent, privileged Microsoft Graph operations long after the original consent is forgotten.
Learning Objectives:
- Understand the technical anatomy of Entra Agent ID and the consent-based attack chain that transforms a Blueprint Principal into a persistent identity factory
- Learn how attackers leverage inheritable permissions and the `AgentIdentity.CreateAsManager` role to create child identities with elevated Graph permissions
- Master detection strategies and mitigation controls to defend against Agent Identity consent phishing and blueprint-based privilege escalation
You Should Know:
- The Agent Identity Attack Chain: From Consent to Persistent Access
The attack begins when a malicious actor publishes a multitenant Agent Blueprint that requests Microsoft Graph application permissions and configures inheritable permissions via allAllowed. Unlike traditional consent phishing that targets a single service principal, this approach establishes a persistent foothold through a four-stage chain:
Step 1 – Blueprint Consent: The attacker creates an Agent Identity Blueprint in their own tenant and publishes it as a multitenant application. When a victim tenant administrator approves the consent request, a Blueprint Principal is instantiated in the victim tenant with the approved Microsoft Graph permissions.
Step 2 – Blueprint Principal Activation: The newly created Blueprint Principal receives the `AgentIdentity.CreateAsManager` role. This role grants the principal authority to provision and manage the lifecycle of child agent identities within the tenant.
Step 3 – Child Identity Proliferation: The attacker, operating through the Blueprint Principal, creates child Agent Identities. These child identities automatically inherit the Microsoft Graph permissions granted to the Blueprint—including powerful permissions such as Application.ReadWrite.All.
Step 4 – Persistent Authentication: At this point, the attacker no longer depends on the original Blueprint Principal. They can authenticate directly as any child Agent Identity and perform privileged Microsoft Graph operations, including adding credentials to existing application registrations or taking ownership of service principals.
Detection Command (Azure CLI):
List all blueprint principals in the tenant az rest --method GET --url "https://graph.microsoft.com/beta/identity/agentIdentityBlueprintPrincipals" Identify blueprint principals created within the last 7 days az rest --method GET --url "https://graph.microsoft.com/beta/identity/agentIdentityBlueprintPrincipals?$filter=createdDateTime ge 2026-06-17"
PowerShell Detection:
Connect to Microsoft Graph with appropriate permissions
Connect-MgGraph -Scopes "AgentIdentityBlueprintPrincipal.Read.All"
Retrieve all blueprint principals
Get-MgBetaIdentityAgentIdentityBlueprintPrincipal |
Where-Object { $_.CreatedDateTime -gt (Get-Date).AddDays(-7) } |
Select-Object Id, DisplayName, CreatedDateTime, AppId
- The Inheritance Mechanism: Why `allAllowed` Is the Critical Flaw
The attack’s success hinges on the inheritable permissions configuration. When a blueprint is created, the resource app (e.g., Microsoft Graph) must be explicitly marked as an inheritable resource for permissions to cascade down to agent identities. The `allAllowed` inheritance pattern grants every child agent identity the full set of permissions approved for the blueprint.
Understanding Inheritance Patterns:
– `allAllowedScopes` – All approved scopes are inherited by every child agent identity (highest risk)
– `enumeratedScopes` – Only explicitly listed scopes are inherited (moderate risk)
– `noScopes` – No permissions are inherited (lowest risk, requires per-identity consent)
The Danger: Once a blueprint with `allAllowed` is consented, any child identity created by the attacker inherits the same privileged Graph permissions. This creates a “permission cascade” where a single consent grants an unlimited number of attacker-controlled identities with identical privileges.
Verification Command (Graph API):
Check inheritance configuration on a blueprint
curl -X GET "https://graph.microsoft.com/beta/identity/agentIdentityBlueprints/{blueprint-id}/inheritablePermissions" \
-H "Authorization: Bearer $ACCESS_TOKEN"
3. The Role of `AgentIdentity.CreateAsManager`: Privilege by Design
The `AgentIdentity.CreateAsManager` role is assigned to Blueprint Principals by design, enabling them to create and manage child agent identities. While this is necessary for legitimate agent fleet management, it becomes a powerful weapon in the hands of an attacker who controls the blueprint.
What This Role Enables:
- Creation of new Agent Identities without requiring additional administrative consent
- Management of the lifecycle of all child identities owned by the blueprint
- Bypass of traditional privileged role assignments—the attacker doesn’t need `Application Administrator` or `Global Administrator` to create privileged identities
The Escalation Path: An attacker who controls a consented blueprint can create hundreds of child identities, each with the same Graph permissions as the original consent. This provides:
– Persistence: Even if the original blueprint is detected and removed, child identities remain active
– Scale: Multiple identities can be used simultaneously for different attack objectives
– Evasion: Each child identity has its own Object ID and audit trail, complicating detection
Audit Log Query (Azure Monitor):
AuditLogs | where OperationName == "Add member to role" | where TargetResources has "AgentIdentity.CreateAsManager" | project TimeGenerated, InitiatedBy.user.userPrincipalName, TargetResources | order by TimeGenerated desc
4. From Consent Phishing to Tenant-Wide Takeover
The attack doesn’t stop at creating identities. Once child Agent Identities with `Application.ReadWrite.All` are established, the attacker can:
Step 1 – Enumerate Applications:
List all application registrations in the tenant curl -X GET "https://graph.microsoft.com/v1.0/applications" \ -H "Authorization: Bearer $CHILD_IDENTITY_TOKEN"
Step 2 – Add Credentials to Existing Applications:
Add a client secret to a target application
curl -X POST "https://graph.microsoft.com/v1.0/applications/{app-id}/addPassword" \
-H "Authorization: Bearer $CHILD_IDENTITY_TOKEN" \
-H "Content-Type: application/json" \
-d '{"passwordCredential": {"displayName": "BackupSecret"}}'
Step 3 – Authenticate as the Compromised Application:
Once credentials are added, the attacker can authenticate as the compromised service principal and inherit all its assigned roles and permissions. If the service principal holds `RoleManagement.ReadWrite.Directory` or Directory.ReadWrite.All, this results in full tenant takeover.
Windows Detection (PowerShell):
Monitor for new credential additions to service principals Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Add service principal credentials'" | Select-Object ActivityDateTime, InitiatedBy, TargetResources
Linux Detection (Azure CLI + jq):
Check for recently modified service principal credentials
az rest --method GET --url "https://graph.microsoft.com/v1.0/servicePrincipals?$expand=owners" | \
jq '.value[] | select(.keyCredentials != [] or .passwordCredentials != []) | {id, displayName, createdDateTime}'
5. Defensive Controls: Hardening Against Agent Identity Attacks
Control 1 – Restrict Inheritable Permissions:
Configure blueprints with `enumeratedScopes` or `noScopes` instead of allAllowed. This ensures that even if a blueprint is consented, child identities do not automatically inherit dangerous permissions.
Control 2 – Monitor Blueprint Consent Activity:
Treat any consent to a multitenant Agent Blueprint as a high-risk event. Require additional approval workflows for blueprint consents that request Microsoft Graph permissions.
Audit Query for Blueprint Consents:
AuditLogs | where OperationName == "Consent to application" | where TargetResources has "agentIdentityBlueprint" | project TimeGenerated, InitiatedBy.user.userPrincipalName, TargetResources, AdditionalDetails
Control 3 – Enforce Conditional Access for Agent Identities:
Apply Conditional Access policies to agent identities, requiring managed device compliance or trusted IP ranges for authentication.
Control 4 – Regular Blueprint and Agent Identity Reviews:
Conduct weekly reviews of all blueprint principals and agent identities in the tenant. Remove any that are not actively used or approved.
PowerShell Review Script:
List all agent identities and their parent blueprints
Get-MgBetaIdentityAgentIdentity | ForEach-Object {
$identity = $_
$blueprint = Get-MgBetaIdentityAgentIdentityBlueprintPrincipal -AgentIdentityBlueprintPrincipalId $identity.BlueprintPrincipalId
[bash]@{
AgentIdentityId = $identity.Id
AgentIdentityName = $identity.DisplayName
BlueprintId = $blueprint.Id
BlueprintName = $blueprint.DisplayName
CreatedDateTime = $identity.CreatedDateTime
Owner = $identity.Owners
}
} | Export-Csv -Path "agent_identity_inventory.csv" -1oTypeInformation
Control 5 – Restrict the `AgentIdentity.CreateAsManager` Role:
Limit which principals can be assigned the `AgentIdentity.CreateAsManager` role. Ensure that only trusted, internally managed blueprints have this capability.
6. Detection: Identifying Active Attacks in Your Tenant
Indicator 1 – Unusual Child Identity Creation:
Multiple Agent Identities created in a short time window from the same Blueprint Principal.
Detection Query:
AuditLogs | where OperationName == "Add agent identity" | summarize Count = count() by TargetResources, bin(TimeGenerated, 5m) | where Count > 5
Indicator 2 – Blueprint Principals with External App IDs:
Blueprint principals where the `appId` does not correspond to an internal application registration.
Indicator 3 – Cross-Tenant Authentication:
Agent identities authenticating from IP addresses outside expected geographic regions.
Indicator 4 – Service Principal Credential Addition:
Activity where a service principal’s credentials are modified shortly after a blueprint consent event.
Correlation Query:
let blueprintConsent = AuditLogs | where OperationName == "Consent to application" | where TargetResources has "agentIdentityBlueprint" | project ConsentTime = TimeGenerated, ConsentActor = InitiatedBy.user.userPrincipalName, BlueprintAppId = tostring(TargetResources[bash].modifiedProperties[bash].newValue); let spCredentialAdd = AuditLogs | where OperationName == "Add service principal credentials" | project CredAddTime = TimeGenerated, TargetSpId = tostring(TargetResources[bash].id); blueprintConsent | join kind=inner (spCredentialAdd) on $left.ConsentActor == $right.InitiatedBy.user.userPrincipalName | where CredAddTime > ConsentTime and CredAddTime < ConsentTime + 1h
What Undercode Say:
- Key Takeaway 1: The Agent Identity consent attack transforms a single administrative approval into an unlimited identity creation capability. Unlike traditional service principal compromise, this attack establishes a persistent “identity factory” that can generate new privileged identities on demand, making detection and remediation significantly more challenging.
-
Key Takeaway 2: The inheritance model—particularly the `allAllowed` configuration—is the critical enabler. Organizations must treat any blueprint requesting inheritable Microsoft Graph permissions as a high-risk event requiring enhanced scrutiny and approval workflows. The architectural power of blueprints to spawn multiple identities with inherited permissions is also its greatest security vulnerability.
Analysis: This attack vector represents a fundamental shift in consent phishing tactics. Traditional consent phishing compromises a single identity; Agent Identity attacks compromise the ability to create identities. Once a malicious blueprint is consented, the attacker gains persistent, scalable access that outlives the original consent. The hierarchical nature of Entra Agent ID—where blueprints own and control child identities—means that removing the original blueprint does not automatically remove the child identities or their credentials. Organizations must adopt a “zero-trust” approach to blueprint consents, treating every multitenant blueprint as potentially malicious until proven otherwise. The most effective defense is proactive: configure blueprints with restrictive inheritance patterns (enumeratedScopes or noScopes) and implement continuous monitoring for abnormal agent identity creation patterns.
Prediction:
- -1 Within 12 months, we will see the first major ransomware campaign leveraging Agent Identity consent phishing as an initial access vector, targeting organizations that have deployed AI agents without proper governance controls.
- -1 The attack surface will expand as more organizations adopt Entra Agent ID, with attackers developing automated tools to scan for tenants with permissive blueprint consent policies and `allAllowed` inheritance configurations.
- +1 Microsoft will respond by introducing “privileged blueprint” designations requiring multi-admin approval and mandatory Conditional Access policies, similar to the protection offered for Privileged Identity Management (PIM) roles.
- +1 Security vendors will develop specialized detection rules for agent identity proliferation, treating rapid child identity creation as a critical alert comparable to mass user account creation.
- -1 The complexity of auditing agent identities will create detection gaps; many organizations will struggle to distinguish between legitimate agent fleet scaling and attacker-controlled identity factories.
- +1 Industry best practices will emerge requiring organizations to treat blueprint consent with the same rigor as granting Global Administrator privileges, including mandatory 48-hour waiting periods and secondary approval from security teams.
- -1 Attackers will increasingly target managed service providers (MSPs) through this vector, using a single consented blueprint to gain persistent access across multiple customer tenants simultaneously.
- +1 Microsoft Graph API will introduce new controls to limit the number of agent identities that can be created from a single blueprint within a time window, reducing the scalability of this attack.
- -1 The “identity factory” concept will inspire similar attack techniques against other identity providers that implement hierarchical identity models, expanding the threat beyond Microsoft Entra ID.
- +1 Organizations that implement proactive blueprint governance—including `enumeratedScopes` inheritance, regular inventory reviews, and Continuous Access Evaluation (CAE) for agent identities—will successfully mitigate this threat before it becomes widespread.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Elishlomo Security – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
