Proofpoint researchers have detailed BluePhishing, a proof-of-concept technique that extends OAuth consent abuse into Microsoft Entra Agent ID.
An adversary socially engineers a victim into consenting to a malicious third-party agent blueprint and obtains initial access to the tenant. Proofpoint has not observed in-the-wild exploitation, and Microsoft was notified before publication.
Entra Agent ID closely mirrors the application model. An agent blueprint maps to an app registration, and a blueprint principal maps to a service principal.
BluePhishing Campaign Abusing Third-Party AI Agent Consent
An agent identity is an instance derived from the blueprint, and up to 250 can exist per blueprint. Microsoft Message Center notice MC1506733 states that default users can create blueprints from November 2026, which widens exposure. Researchers have already shown how a single link can spawn a rogue enterprise AI agent, so the attack surface is real.
The attacker first builds a blueprint in a tenant they control. The signInAudience property must be set to AzureADMultipleOrgs, which the Entra portal does not expose, so the attacker sets it through Microsoft Graph or PowerShell. The blueprint also carries a client secret, requiredResourceAccess (RRA) entries, and inheritable permissions.

A single adminconsent URL using client_id, a Graph .default scope, and response_type=none then bundles every permission into one consent event. Distribution can piggyback on social-engineering infrastructure such as the ROMULUS ClickFix platform.
Once the victim consents, a blueprint principal is created in the victim tenant. It automatically receives the non-revocable AgentIdentity.CreateAsManager application permission.
The attacker needs only the victim tenant ID and a sponsor user’s object ID, and both can be enumerated without authentication through the GetCredentialType endpoint and the OpenID Connect discovery document.
Post-consent, the attacker requests a client_credentials token from the victim tenant’s token endpoint, and the roles claim carries AgentIdentity.CreateAsManager.
That token authorizes a POST to the servicePrincipals/Microsoft.Graph.AgentIdentity endpoint, supplying agentIdentityBlueprintId.
The sponsor can be removed after provisioning. The attacker then uses the autonomous agent flow. The blueprint presents its credential and an fmi_path pointing at the agent identity, receives an exchange token, and redeems it for a Microsoft Graph access token.

In testing, the researchers loaded the resulting token into GraphRunner and executed arbitrary Graph requests with User.Read.All and Group.Read.All. Agent identities that hold secrets are an attractive target, as seen when AI agents stole API keys and student data in a recent college breach.
Consent type shapes the outcome. Application permissions require admin consent but apply tenant-wide. User consent grants only delegated permissions, which cannot be redeemed through the autonomous flow and require an on-behalf-of (OBO) flow with additional consent.
Silent inheritance to agent identities was observed only for delegated permissions from user consent, while admin-consented grants showed a grant source of “inherited from parent”. Inherited permissions are not visible in the Entra portal or Microsoft Graph and appear only in runtime token contents, which hinders auditing.
Defenders can use the blueprint application ID, which stays consistent across every tenant that consents, as a hunting and removal indicator.
The audit log records “Add application” for blueprint creation and “Add service principal” for agent identity creation. Recommended controls include restricting user consent for third-party blueprints, tightening permission classifications, and enforcing Conditional Access and Entra ID Protection for agents under least privilege.
Site: Thecyberdef.com
Follow TheCyberDef on Google News, LinkedIn & X for the latest cybersecurity updates. Stay informed.