As organizations rush to adopt AI agents across their Microsoft 365 environments, researchers at Proofpoint have published a proof-of-concept technique showing how the identity infrastructure behind those agents can be turned against the very companies deploying them. The technique, which Proofpoint calls BluePhishing, requires no stolen password and no fake login page — just one person approving what looks like a routine permission request.

An Old Trick, Repackaged for the AI Agent Era

BluePhishing builds directly on a well-understood attack pattern that security teams have dealt with for years: OAuth consent phishing. In the classic version, a victim clicks “Accept” on a permissions screen for what turns out to be a malicious application, unknowingly granting it access to their account or tenant. BluePhishing transplants that same basic mechanic into Microsoft Entra Agent ID — the relatively new system Microsoft uses to give AI agents their own distinct identities within a company’s cloud tenant — where Proofpoint argues fewer defenders know what red flags to look for, and fewer technical controls currently exist to stop it.

The timing is notable. A Microsoft 365 Message Center notice (MC1506733) indicates that, starting in November 2026, ordinary Entra users will be able to create agent blueprints by default, rather than that capability being restricted to administrators. That change meaningfully widens the pool of people who could be tricked into approving a malicious agent blueprint.

Proofpoint published its findings on November 9, 2026, stating explicitly that the technique is a research-based proof of concept and that the firm has not observed it being used in real-world attacks. Proofpoint also disclosed the issue to Microsoft before publishing.

How the Attack Chain Works

Entra Agent ID largely mirrors Microsoft’s existing application identity model. An “agent blueprint” functions much like an app registration — it’s the template. A “blueprint principal” is the local copy of that template inside a specific company’s tenant. From there, an “agent identity” is an actual working agent instantiated from the blueprint, and critically, a single blueprint can spawn up to 250 separate agent identities.

To carry out the attack, an adversary first creates an agent blueprint inside a tenant they control and attaches a client secret to it. They then configure the blueprint’s sign-in audience setting to allow consent from other organizations — a setting Proofpoint notes is not visible or adjustable through the standard Entra admin portal, but can be set directly via PowerShell or the Microsoft Graph API. The attacker also attaches broad permissions that will be inherited by every agent identity later spawned from the blueprint, echoing a pattern seen in earlier cases where malicious OAuth applications in Entra were used to maintain long-term, password-independent access to compromised tenants.

Next, the attacker sends the intended victim a consent link. The moment the victim approves it, a corresponding blueprint principal is created inside the victim’s own tenant — and it automatically receives a permission called AgentIdentity.CreateAsManager. According to Proofpoint, this permission cannot be revoked once granted. Armed with it, the attacker can request a Microsoft Graph access token and begin creating new agent identities directly inside the victim’s tenant, using only a handful of details: the blueprint ID and secret (which the attacker controls from the start), the victim’s tenant ID, and a designated “sponsor” user. Proofpoint notes that none of these values are treated as particularly secret — the tenant ID in particular can often be discovered through public sign-in lookup tools.

In testing, Proofpoint demonstrated that an agent identity created this way, holding permissions like User.Read.All and Group.Read.All, could be loaded into the open-source tool GraphRunner to issue arbitrary Graph API requests against the victim’s tenant — full reconnaissance capability without a single stolen credential.

Why This Kind of Compromise Could Go Unnoticed

Perhaps the most unsettling part of BluePhishing is how naturally it blends into normal operations. AI agents are, by design, expected to act autonomously and continuously — a suspicious background application making repeated API calls might eventually raise a security analyst’s eyebrows, but a busy, legitimate-looking AI agent doing the same thing typically won’t.

Compounding the problem, consent controls built around agents are considerably less mature than those for traditional applications. Inherited permissions on agent identities don’t appear in the Entra admin portal or standard Graph queries — they only surface inside access tokens at runtime, making after-the-fact auditing harder. A single app registration maps to one service principal per tenant; a single malicious blueprint can spin up to 250 agent identities, each its own potential foothold.

This isn’t the first identity-related weak point discovered in Entra Agent ID since its introduction — a previously identified issue with the Agent ID Administrator role showed the system is still being actively stress-tested by the security research community as it matures.

Recommended Defenses

Proofpoint’s recommendations for organizations deploying Entra Agent ID include:

• Train staff specifically on the risks of approving permission requests from third-party AI agents, not just traditional applications.
• Apply the same user-consent restrictions and policies that already govern application consent to agent blueprints and agent identities.
• Use Microsoft’s existing permission classification controls — the platform already blocks certain high-risk Graph permissions, such as User.ReadWrite.All, from being granted to agents.
• Enforce least-privilege principles, apply Conditional Access policies to agents specifically, and enable Entra ID Protection coverage for agent identities.
• Monitor audit logs closely for “Add application” events (indicating a new blueprint was created) and “Add service principal” events (indicating a new agent identity was spawned).

Researchers also compared the technique to CoPhish, an earlier method that abused Microsoft Copilot Studio by presenting a trusted-looking agent hosted on an actual Microsoft domain to harvest OAuth consent. BluePhishing could prove even more convincing, since here the agent isn’t just the bait — it is the attacker’s actual persistent identity inside the victim’s environment, a reminder that identity governance built for humans and conventional apps doesn’t automatically extend to autonomous agents.