On November 9, 2026, Proofpoint published BluePhishing, a research proof-of-concept in which a victim approves a malicious Microsoft Entra agent blueprint and the attacker gains persistent Graph access through derived agent identities—without stealing a password. Researchers notified Microsoft before publication and have not observed the technique in the wild. If you run coding agents only on a laptop, the immediate risk is indirect: the same “click approve” reflex that leaks MCP keys or self-approved hooks also applies when your company adopts Entra Agent ID. This post walks through the mechanism Proofpoint documented, what Microsoft is changing this month, and what security teams—and individual agent operators—should verify.
explainx.ai covered Microsoft's agent backdoor research the same week; BluePhishing is a different angle—identity consent, not model weights.
TL;DR
| Question | Answer |
|---|---|
| Am I affected? | Enterprises using Entra Agent ID where users or admins can consent to third-party blueprints; not a local Claude Code/CVE issue |
| Is there a fix? | Governance and consent policy, not a single patch—restrict third-party agent consent, classify permissions, monitor blueprint IDs |
| Is it exploited? | No in-the-wild cases cited by Proofpoint as of Nov 9, 2026 |
| What is new in November 2026? | Message Center MC1506733: default Entra users may create agent blueprints starting November 2026, widening exposure |
| What should I do? | Train consent skepticism, mirror app consent restrictions for agents, hunt Add application / Add service principal for blueprints |
How Entra Agent ID maps to the attack
Microsoft Entra Agent ID extends Entra to AI agents using vocabulary that mirrors classic app registrations:
| Entra Agent ID term | Traditional app model analogue |
|---|---|
| Agent blueprint | App registration (template + credentials) |
| Blueprint principal | Service principal in a tenant |
| Agent identity | Running instance (up to 250 per blueprint) |
Proofpoint stresses that delegated permissions can scope to a sponsor user, while application permissions support autonomous app-only access—the same split defenders know from OAuth applications, now applied to agents that are expected to act on their own.
Microsoft's Agent ID best practices urge distinct identities per agent instance for traceability. BluePhishing abuses that scalability: one consented blueprint becomes a factory for many identities.
BluePhishing attack chain (step by step)
Proofpoint's scenario assumes the attacker controls Tenant A and targets Tenant B.
Step 1 — Configure a malicious blueprint in the attacker tenant
The attacker creates an agent blueprint and configures:
- Client secret on the blueprint (like a multi-tenant app with credentials).
signInAudience=AzureADMultipleOrgsso other organizations can consent. Proofpoint notes this value is not exposed in the Entra portal but can be set through Microsoft Graph, PowerShell, or the manifest.- Application and delegated permissions on Microsoft Graph, plus required resource access (RRA) and inheritable permissions so child agent identities pick up bundled rights after a single consent click.
Inherited permissions are especially important for defenders: Proofpoint cites Microsoft documentation that inherited permissions are not visible in the Entra portal or via Graph and appear in token contents at runtime—harder to audit than classic app role assignments displayed in UI.
Step 2 — Deliver a consent link
The consent URL pattern Proofpoint documents uses the blueprint's application ID (not a legacy client_id label) and can request admin consent to https://graph.microsoft.com/.default, granting everything pre-declared in RRA on the blueprint.
User-facing prompts show publisher metadata and an explicit inheritance step (“permissions will flow to agents created from this blueprint”). Proofpoint argues users may treat AI agent approvals more casually than classic “this app wants to read your mail” dialogs—especially as enterprises accumulate legitimate agent identities.
Step 3 — Blueprint principal appears in the victim tenant
When the victim accepts the link, Entra creates a blueprint principal in Tenant B. Proofpoint observed:
- Implicit
AgentIdentity.CreateAsManageron that principal—described as non-revocable. - Ability to exchange the attacker's blueprint credentials for an app-only Graph token in the victim tenant bearing that role.
Step 4 — Create agent identities and obtain operational tokens
With the blueprint ID, client secret, victim tenant ID, and a sponsor user object ID (required to provision an identity; Proofpoint notes sponsors can be removed after creation), the attacker calls Graph to create agent identities. Proofpoint demonstrated application permissions User.Read.All and Group.Read.All on a test identity named BluePhish, then imported the token into GraphRunner for arbitrary Graph requests.
Attacker prerequisites sound sensitive but Proofpoint emphasizes tenant IDs and user identifiers are often discoverable through documented unauthenticated techniques (for example OpenID configuration and GetCredentialType enumeration, as they reference in the post).
Image: Proofpoint
Step 5 — Persistence at scale
Unlike one service principal per consented multi-tenant app, a single blueprint can mint up to 250 agent identities, each potentially inheriting delegated or application permissions granted at consent time—amplifying insider-style agent risk Nadella's essays describe at the organizational layer.
Why Proofpoint thinks defenders will miss it
The post lists structural gaps:
- Lower user awareness of agent consent compared with app consent phishing.
- Less mature consent controls deployed for agents than for enterprise applications.
- Activity blends with legitimate automation—agents are supposed to run unattended.
- Inherited scopes invisible in admin UI, complicating audits (Microsoft's ID Protection for agents is positioned partly at this behavior gap).
Proofpoint also separates admin consent (tenant-wide application roles, powerful when the victim is privileged) from user consent (delegated scopes tied to one user). During testing they saw silent inheritance behavior differ between admin and user consent paths—details that matter for purple teams reproducing the PoC.
Admin consent versus user consent (why purple teams care)
Proofpoint walks through two consent paths because the privilege model changes the blast radius:
When an administrator with permission to grant tenant-wide consent clicks an admin consent link, application permissions configured on the blueprint can land as inherited from parent on child agent identities. That mirrors classic tenant-wide app role grants—one misclick, many objects readable.
When a standard user follows a user consent link, only delegated permissions operate in that user's context unless additional flows (such as on-behalf-of with another consent stage) expand scope. Proofpoint notes OBO may still require further user approval, but during their testing silent inheritance from blueprint principal to agent identity was only observed for delegated permissions granted via user consent, while admin-consent grants showed grant source inherited from parent.
For red teams, that split means playbooks differ: user-consent phish may need a visible sponsor user but caps autonomous app-only roles; admin-consent phish is rarer (requires a privileged victim) but can wire application roles like User.Read.All across the tenant.
Defenders should align training materials: an “AI agent” banner on a consent screen is not a reason to skip change-control review.
Historical context: OAuth apps and earlier Agent ID issues
BluePhishing is explicitly framed as the successor to OAuth consent phishing. Entra tenants have seen multi-tenant apps with client secrets abused as long-lived backdoors even after password resets—Proofpoint draws that parallel before introducing blueprints.
Separate from consent phishing, Silverfort documented Agent ID Administrator scope overreach in 2026—a different Entra Agent ID flaw Microsoft patched in April. BluePhishing is social consent, not role assignment, but both show the agent identity stack is still maturing.
Microsoft's own ID Protection for agents documentation discusses anomalous sign-in patterns—unusual locations, unfamiliar clients, and bursts of activity after dormancy. Those detections matter after BluePhishing succeeds; consent phishing prevention still starts with blocking unapproved third-party agents the same way security teams block unapproved multitenant apps.
Security news coverage on November 11, 2026 (for example Cyber Security News) largely restates Proofpoint's findings; treat the Proofpoint article and Microsoft Learn as canonical when reproducing timelines or permission names.
Policy context: MC1506733
Proofpoint cites Microsoft 365 Message Center announcement MC1506733, which states that default Entra users will be able to create agent blueprints by default starting in November 2026. That does not create BluePhishing by itself, but it increases the number of principals who can publish blueprint templates—similar to widening who can register OAuth apps without also widening monitoring.
Detection and response indicators
Proofpoint offers concrete hunting leads:
| Indicator | Meaning |
|---|---|
Permission AgentIdentity.CreateAsManager | Implicit on blueprint principal after malicious consent |
Property signInAudience = AzureADMultipleOrgs | Third-party blueprint open to external tenants |
Sample display name BluePhish | Proofpoint lab naming in JWT app_displayname |
| Audit Add application | New agent blueprint recorded |
| Audit Add service principal | New agent identity recorded |
| Stable blueprint ID across tenants | Same malicious blueprint ID wherever victims consented—use for eviction |
They recommend mirroring enterprise app user consent settings for agent blueprints and identities, using permission classifications (Microsoft already blocks some high-risk Graph permissions such as User.ReadWrite.All for agents), Conditional Access policies for agents, and Entra ID Protection for agents.
Reproducing the PoC safely
Proofpoint notes they notified Microsoft before publication and used a display name BluePhish in sample tokens—use those strings only in lab tenants. Their JWT snippet shows appidacr, idtyp: app, and role AgentIdentity.CreateAsManager in the access token used to create identities.
Organizations validating detection rules should:
- Snapshot Entra audit and sign-in logs around a controlled consent in a sacrificial tenant.
- Document whether inherited permissions appear anywhere administrators routinely look (portal, Graph, SIEM)—Proofpoint claims gaps here.
- Test remediation: blueprint ID reuse across consented tenants is their proposed eviction key—confirm your runbooks can search on application ID across blueprint principals and agent identities.
Do not run consent links from untrusted email in production tenants; pair tests with Microsoft’s agent consent settings documented under enterprise applications.
What this means if you run AI coding agents
Most readers of Beam run Claude Code, Codex, or Cursor on a workstation, not Entra Agent ID in production. The direct BluePhishing path requires Microsoft Entra Agent ID and a victim who can approve a third-party blueprint. Still, three lessons transfer:
- Consent is code execution for the cloud. Approving an unfamiliar agent blueprint is closer to installing a persistent OAuth app in Entra than to trying a local CLI plugin.
- Autonomous agents lower suspicion. Techniques that would look odd for a background sync app may look normal for an “AI assistant” identity—parallel to attackers abusing MCP and hook auto-approval patterns on developer machines.
- Secrets in agent pipelines still matter. Enterprise agent identity abuse is separate from cloud control-plane keys stolen via agentic frameworks, but the blast radius stacks when the same tenant runs both SaaS agents and autonomous coding tools with broad repository access.
If your security team inventories local agents, ensure they also plan governance for Entra-issued agent identities before blueprint creation defaults widen.
What Beam can and cannot do here
Beam is local-first observability for coding agents on a developer machine: PreToolUse hooks, skill/MCP heuristic scans, and on-device event history. It does not parse Entra audit logs, enforce tenant consent policy, or block Microsoft 365 approval screens. It can help the same teams by flagging when a coding agent reads or exfiltrates client secrets, refresh tokens, or Graph keys from a repo before they enter prompts—often the next step after identity footholds like BluePhishing enable Graph automation.
Limits: scanning is heuristic, not semantic; cloud identity governance remains in Entra and SIEM tooling.
Frequently asked questions
The FAQ front matter mirrors the sections above. Key reminders: no confirmed in-the-wild BluePhishing yet; AgentIdentity.CreateAsManager is the pivot permission; inherited permissions are hard to see in portal; MC1506733 expands who can publish blueprints in November 2026.
Related reading
- Microsoft Guardian Agents: treating coding agents as insider threats
- Postman plugins and self-approved hooks in Claude Code and Codex
- Storm-0940: ConnectWise supply chain and Microsoft 365 tenants
- Northflank incident: control-plane secrets and AI key abuse
- Railway breach: environment variables and AI keys
Entra Agent ID names, permission strings, and Message Center identifiers in this article match Proofpoint's November 9, 2026 publication and Microsoft Learn pages linked above, as of publication date.