Microsoft Entra Agent ID extends the application model to AI agents by introducing blueprints, blueprint principals, agent identities, and agent users, which can greatly expand the blast radius of a compromise. If a threat actor adds a credential to a blueprint, they may access all associated identities across tenants, creating cross-tenant risk similar to the Midnight Blizzard incident. #MicrosoftEntra #MidnightBlizzard #CopilotStudio #MicrosoftFoundry
Keypoints
- Entra Agent ID is an identity and security framework that extends Microsoft Entra capabilities to AI agents.
- The model introduces blueprints, blueprint principals, agent identities, and optional agent users as subtypes of existing Entra objects.
- A single blueprint can create up to 250 agent identities per tenant, increasing the number of identities under one trust boundary.
- Blueprints are the only place where credentials can be added, and those credentials can authenticate all associated identities.
- Agent identities can carry Entra roles, application permissions, delegated permissions, and inherited delegated permissions from a blueprint principal.
- Compromise of a blueprint can impact identities and permissions across multiple tenants, creating a multi-tenant blast radius.
- The article notes that this risk is similar to third-party application compromise scenarios such as Midnight Blizzard.
MITRE Techniques
- [T1098 ] Account Manipulation – A threat actor adding a credential to a blueprint can take over all associated agent identities and users (‘If a threat actor can add a credential to a blueprint, they can access all agent identities associated with that blueprint’).
- [T1550 ] Use Alternate Authentication Material – The blueprint secret and token exchange flow let the actor authenticate as other identities using stolen/controlled credentials (‘The blueprint credential is used… to obtain a token as the blueprint principal’ and then ‘used as the credential for a second client_credentials grant’).
- [T1078 ] Valid Accounts – Compromised blueprint-based identities can be used to act with legitimate permissions across tenants (‘whoever controls the blueprint controls all its associated identities’ and ‘can use those permissions to escalate privileges’).
- [T1550.001 ] Application Access Token – Access tokens are obtained and reused in chained token exchanges to impersonate the blueprint principal and then the agent identity (‘This request returns a token valid for authentication as the blueprint principal’ and ‘This request returns a token as the agent identity’).
- [T1528 ] Steal Application Access Token – The described exchange relies on using one token as the assertion to obtain another token, enabling impersonation of higher-level identities (‘The initial blueprint principal token… is used as the credential for a second client_credentials grant’).
Indicators of Compromise
- [API endpoint ] Agent user creation endpoint in Microsoft Graph – /beta/users/microsoft.graph.agentUser, /oauth2/v2.0/token
- [Application/resource scopes ] Token audience and target scope used in exchanges – api://AzureADTokenExchange/.default, [Target Application Scope]
- [HTTP methods and request parameters ] Authentication flow parameters that define the blueprint-to-agent exchange – client_id, client_secret, fmi_path, client_assertion
- [Tenant and object identifiers ] Tenant-specific and object-specific values required for the token flow – [Tenant ID], [Blueprint Application ID], [Agent Identity Object ID]
- [Authentication domains ] Microsoft identity and Graph infrastructure used for the workflow – login.microsoftonline.com, graph.microsoft.com
Read more: https://securitylabs.datadoghq.com/articles/agent-id-blueprint-blast-radius/