Researchers have shown that attackers can take over parts of a Microsoft 365 environment by tricking one person into approving a fake AI agent. No password is stolen and no login screen is faked.
The technique is called BluePhishing. It targets Microsoft Entra Agent ID, the system that gives AI agents their own identities inside a company’s cloud tenant.
The method builds on a trick security teams already know, OAuth consent phishing. In that trick, a victim clicks “Accept” on a permission screen for a harmful app.
BluePhishing moves the same idea into the new world of AI agents, where fewer people know what to look out for and fewer controls exist.
Microsoft is also about to widen the door. A Microsoft 365 Message Center notice, MC1506733, says regular Entra users will be able to create agent blueprints by default starting in November 2026. That raises the number of places where a bad consent request could slip in.
Analysts at Proofpoint identified and described the BluePhishing technique in a report published on November 9, 2026, and noted that they have not yet seen it used in real attacks.
Proofpoint says it is a research-based proof of concept. It also told Microsoft about the problem before sharing the details.
Hackers Could Abuse Microsoft Entra AI Agents
Entra Agent ID works much like the older app model. An agent blueprint is the template, similar to an app registration. A blueprint principal is its local copy inside a company tenant.
An agent identity is a working agent created from that blueprint, and one blueprint can create up to 250 of them. The attacker first builds a blueprint in a tenant they control and adds a client secret.
They set the sign-in audience to allow other organizations, which the Entra portal does not show but PowerShell or Microsoft Graph can do.
They also add broad permissions that agents will inherit. This is similar to earlier cases of OAuth apps in Entra being used to keep long-term access, where the app acts as a quiet entry point even after passwords are reset.
Next, the attacker sends the victim a consent link. When the victim approves it, a blueprint principal appears in the victim’s tenant. It automatically gets a permission named AgentIdentity.CreateAsManager, which Proofpoint says cannot be revoked.
With that permission, the attacker can request a Graph token and create agent identities inside the victim’s tenant. The attacker only needs a few details: the blueprint ID and secret, which they make themselves, plus the victim’s tenant ID and a user to act as the “sponsor.” Proofpoint notes these are not treated as secret, and the tenant ID can be found through public sign-in lookups.
Researchers showed that a created agent holding User.Read.All and Group.Read.All could be loaded into the GraphRunner tool to run Graph requests.
Admin consent is stronger because one click can grant tenant-wide application permissions. User consent only grants delegated rights tied to that person.
Why Defenders May Miss It and What to Do
Agents are expected to act on their own, so their activity looks normal. A suspicious app that works in the background may raise questions, but a busy agent does not.
Proofpoint also points out that consent controls for agents are less mature than those for apps. Inherited permissions do not show up in the Entra portal or in Microsoft Graph, so they appear only inside tokens at runtime.
.webp)
A past case with Entra Agent ID logs showed that tracing agent actions takes careful work across several log sources. The blast radius is larger too. An app registration maps to one service principal per tenant, while one blueprint can create 250 agent identities.
Earlier flaws, such as the Agent ID Administrator role problem found by Silverfort, show that this young identity system is still being tested.
Proofpoint suggests these steps:-
- Teach staff to be careful when a third-party agent asks for permissions.
- Apply the same user consent limits to agent blueprints and agent identities.
- Use permission classifications. Microsoft already blocks risky Graph permissions such as User.ReadWrite.All for agents.
- Use least privilege, Conditional Access policies for agents, and Entra ID Protection for agents.
- Watch the audit log. “Add application” shows a blueprint being created, and “Add service principal” shows an agent identity being created.
Similar lures have already worked with AI themes. The CoPhish Copilot Studio technique used a trusted-looking agent on a Microsoft domain to collect OAuth consent. BluePhishing could prove even more convincing because the agent is the identity itself.
Indicators of compromise (IoCs):-
| Type | Indicator | Meaning |
|---|---|---|
| Permission | AgentIdentity.CreateAsManager | Implicit permission on the blueprint principal that lets agent identities be created |
| Property | signInAudience = AzureADMultipleOrgs | Setting that allows a third-party blueprint to receive consent |
| Test name | BluePhish (app_displayname) | Name used in the researchers’ sample token |
| Audit event | Add application | A new agent blueprint was created |
| Audit event | Add service principal | A new agent identity was created |
| Detection key | Agent blueprint ID | The same ID appears in every tenant that consents, so it can be used to find and remove known bad agents |
| Permissions seen | User.Read.All, Group.Read.All | Application permissions held by the test agent identity |
Note: IP addresses and domains are intentionally Qdefanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.
Give your SOC the alert context on the latest threats to stop incidents quickly -> Integrate Threat Intel from 16K SOCs
