One Consent Click, 250 Agent Identities: Proofpoint’s BluePhishing Turns Entra Blueprints Into Initial Access

2026-11-11 Agent & Supply Chain Security by al-ice.ai Editorial

On 9 November 2026 Proofpoint researcher Rachel Rabin published “BluePhishing: Initial Access via Third-Party Agent Blueprint Consent” — the agent-identity era’s answer to OAuth consent phishing. The mechanics will feel familiar to anyone who has triaged an illicit-consent-grant attack: the victim clicks one consent link for something that looks legitimate, and the attacker gets a persistent foothold. What is new is the unit of compromise. Consent is granted not to an app but to an agent blueprint in Microsoft Entra Agent ID, and a single approval lets the attacker mint up to 250 agent identities inside the victim tenant, each operating with the blueprint’s permissions. This is a research proof of concept: Proofpoint states plainly that it has not observed any in-the-wild activity, and that it notified Microsoft before publishing. Treat it as a forecast with working code, not an active campaign — and as a governance deadline, because the exposure window opens this month.

The identity model, in one paragraph

Entra Agent ID extends Entra to AI agents and deliberately mirrors the application model, which means it inherits the application model’s abuse cases. An agent blueprint is the analog of an app registration: a template defining the agent’s configuration and credentials. A blueprint principal is the analog of a service principal: the blueprint’s representation inside a tenant. An agent identity is a concrete instance created from a blueprint — and up to 250 of them can hang off a single blueprint, with delegated permissions scoped to a user context rather than the whole tenant. Contrast that with an app registration, which maps to one service principal per tenant: the blueprint is a one-to-many compromise primitive. And per Microsoft 365 Message Center post MC1506733, cited by Proofpoint, default Entra users will be able to create agent blueprints starting November 2026 — the population able to be socially engineered into, or to originate, a malicious consent just got much larger.

How the attack works

The attacker configures a blueprint in a tenant they control: sign-in audience set to AzureADMultipleOrgs (which makes it a consentable third-party blueprint, and which cannot be set through the Entra portal — only via Graph, PowerShell, or the manifest), a client secret, and a permission bundle expressed through required resource access (RRA) plus inheritable permissions so every derived identity silently carries the grant. The consent link is the familiar admin-consent shape with an agent-specific twist — client_id={blueprint_id}&scope=https://graph.microsoft.com/.default — requesting everything pre-configured on the blueprint at once, with response_type=none since interactive token acquisition is blocked. When the victim approves, a blueprint principal materializes in the victim tenant carrying an implicit AgentIdentity.CreateAsManager application permission that cannot be revoked from the principal. The attacker then requests a client-credentials token against the victim tenant’s token endpoint using their own blueprint credentials, and presents it to Graph to create agent identities — each requiring only a sponsor, i.e. a victim user’s object ID, which is a governance label rather than a barrier since it can be removed after provisioning. Finally the attacker redeems tokens for those identities through the autonomous agent flow (the fmi_path exchange) and operates with their permissions; Proofpoint’s demo used User.Read.All and Group.Read.All piped into GraphRunner for arbitrary Graph requests.

What the attacker needs to know (less than you’d hope)

From their own tenant: the blueprint application ID and client secret. From the victim: the tenant ID and a sponsor object ID — neither of which Proofpoint considers sensitive. Tenant IDs fall out of the public OpenID configuration endpoint, and users can be enumerated through the GetCredentialType endpoint, both per publicly documented techniques. Admin consent is the dangerous path — application permissions across the whole tenant from one link — but it requires the phished user to hold grant privileges; where user consent is blocked by policy, the request can be routed into the admin-approval workflow, which is a second social-engineering surface, not a dead end. One nuance worth keeping: in Proofpoint’s testing, silent permission inheritance from blueprint principal to agent identity was observed for delegated grants (user consent), while admin-consented grants carried an explicit “inherited from parent” grant source. Either way, Microsoft’s own documentation says inherited permissions are not visible in the Entra portal or via Graph — only in token contents at runtime, which is the auditability gap the whole attack leans on.

Why this is worse than the app-consent phishing it descends from

Proofpoint’s comparison is unusually crisp, and worth restating in full. Lower user awareness: people are likelier to approve an AI agent than an app because the vector is unfamiliar. Less mature governance: agent consent controls lag their app counterparts in deployment. A 250-to-1 blast radius: one blueprint, hundreds of identities. Invisible scopes: inherited permissions show up nowhere an auditor looks. Camouflage by design: agents are expected to act autonomously, so malicious agent activity blends into environments already full of agent identities — whereas an app with offline access acting on its own at least looks odd. That last point connects directly to the doctrine Microsoft itself has been pushing: we covered its agentic-insider framing and guardian agents last month, and BluePhishing is the concrete initial-access story for that threat model — the insider that was never compromised, invited in through a consent dialog.

What this means next to everything else we track

BluePhishing slots into a lineage this site has followed all year. The consent-abuse mechanics are the direct descendant of the shadow-AI OAuth cascades and unmanaged OAuth grants from AI tools that turn one approval into persistent access — except the unit of persistence is now a fleet of agent identities, not a grant. The governance gap echoes the Register’s ungoverned-agent-identity warning from February and Qualys on MCP servers as shadow IT: identity systems built for humans and apps are being asked to govern autonomous actors, and the controls haven’t caught up. And the detection story — a blueprint ID that is consistent across every consenting tenant, audit-log events mirroring app-consent operations — is the same cross-tenant-indicator logic defenders already use for malicious applications, which means existing consent-phishing playbooks transfer if teams update them to cover the agent object types.

What to actually do

Extend consent-phishing defenses to blueprints now, not after the first incident. User consent settings that block third-party app grants also cover agent blueprints — verify yours do, and use permission classifications to keep users from approving anything above low risk. Microsoft already blocks high-risk Graph permissions such as User.ReadWrite.All for agents; treat that list as a floor.
Decide who may create blueprints before the default changes. MC1506733 widens blueprint creation to default users; review that posture deliberately and restrict it where the risk doesn’t justify the convenience, just as you would app-registration rights.
Hunt the cross-tenant constant. A malicious blueprint ID is identical in every tenant that consented to it — collect consent-grant and blueprint-principal creation events from the audit log and join on blueprint IDs, exactly as you would for a malicious application ID.
Assume inherited permissions are invisible and compensate. Since grants surface only in token contents, inspect the tokens: decode agent-identity tokens for scopes and roles rather than trusting portal or Graph views, and alert on agent identities whose effective permissions exceed their documented purpose.
Contain the blast radius with agent-aware policy. Apply Conditional Access policies for agent identities, use Entra ID protection signals for agents, and enforce least privilege on every blueprint — a 250-identity fleet with User.Read.All is a directory-reading botnet waiting for a prompt.

Our verification was read-only. We read the full Proofpoint blog post first-hand (Rachel Rabin, 9 November 2026: research PoC, no in-the-wild activity observed, Microsoft notified pre-publication, 250-identity limit, MC1506733, AzureADMultipleOrgs, AgentIdentity.CreateAsManager, RRA/inheritable permissions, GetCredentialType and OpenID tenant-ID disclosure, fmi_path autonomous flow, User.Read.All/Group.Read.All GraphRunner demo, invisible inherited permissions, consent-settings and classification mitigations, audit-log detection). GBHackers’s 11 November 2026 write-up (Mayura Kathir, including the per-non-Microsoft-managed-blueprint limit) and TechRadar’s 11 November 2026 coverage (agent “cloning” framing) are carried as reported. We requested no consent, created no blueprint, minted no identity, redeemed no token, and contacted no vendor. Brave Search was used for discovery only.

Sources: