BluePhishing turns agent consent into cloud initial access
On November 9, Proofpoint disclosed BluePhishing, a proof-of-concept attack against Microsoft Entra Agent ID. The technique uses a real consent page to persuade a victim to authorize a third-party agent blueprint. There is no fake login page. The consent flow is genuine. The resulting identity is valid inside the tenant.
That changes the security question. The problem is no longer only whether a user clicked a suspicious OAuth prompt. It is whether the organization can tell the difference between a legitimate agent onboarding event and the creation of an attacker-controlled cloud principal.
The key finding: a single consent decision can create a blueprint principal in the victim tenant. Proofpoint found that the blueprint can then create tenant-local agent identities that inherit permissions configured by the attacker.
The attack is familiar. The principal is new.
Traditional consent phishing abuses an application registration. BluePhishing applies the same social-engineering pattern to an agent identity blueprint.
Microsoft describes a blueprint as a reusable template for agent identities. The blueprint holds the credentials and shared metadata. Each agent identity is a tenant-local service principal created from that template. Microsoft says a blueprint can support up to 250 agent identities.
Proofpoint's demonstration used a multitenant blueprint, a consent link, and a sponsor from the victim tenant. After consent, the blueprint principal received the ability to create agent identities. The attacker could then request tokens for those identities and use the permissions assigned to them.
The important detail is not the product name. It is the sequence: consent creates a principal, the principal creates more principals, and the resulting activity looks like normal agent automation.
Legitimate consent link
The victim receives a link to a real identity provider page.
Blueprint is approved
The user or administrator grants the requested agent permissions.
Principal appears in the tenant
The attacker now has a cloud identity object inside the target environment.
Agent identities are created
The blueprint can provision additional identities tied to its configuration.
Tokens drive normal APIs
Requests arrive through valid identity and Graph flows, not an obvious exploit.
Why agent consent deserves a separate control
An application consent review usually asks which app is requesting access, who published it, and which scopes it wants. Those checks still matter for agents, but they do not answer several questions that are specific to agent identity:
- Who owns the blueprint after it enters the tenant?
- Which identities can it create, and who sponsors them?
- Can permissions flow from the blueprint to future identities?
- Can the security team see inherited permissions before a token is issued?
- What stops an agent identity from becoming an unreviewed service account?
Proofpoint reported that inherited permissions were not visible in the Entra portal or through Microsoft Graph in the tested flow. The permissions were observable in token contents at runtime. That creates a practical audit gap: a reviewer may approve the blueprint, see the resulting object, and still miss what a derived identity can do until it authenticates.
This is a governance problem with a runtime consequence. The approval happens once. The authority can persist through identities created later.
The OWASP Agentic Top 10 connection
BluePhishing maps most directly to ASI03, Identity and Privilege Abuse. The attacker does not need to forge a user session after consent. They use a legitimate agent identity and its issued tokens.
It also touches ASI08, Trust Boundary Violations. A principal created from an external blueprint crosses into the tenant, then creates identities that operate alongside internal agents. The identity provider authenticates the requests, but authentication does not establish that the workflow or publisher should be trusted.
The case also shows why ASI03 and ASI08 cannot be handled only during agent registration. The security decision must remain active when an agent requests a token, creates another identity, or accesses a new resource.
What security teams should check this week
Restrict third-party blueprint consent
Review user consent settings and permission classifications. Require administrator review for external blueprints and high-impact Graph permissions.
Inventory the new object types
Search for agent blueprints, blueprint principals, and agent identities. Record the publisher, owner, sponsor, creation time, permissions, and intended workload.
Detect identity multiplication
Alert when one blueprint creates several identities, when a new identity has no clear sponsor, or when creation is followed quickly by token requests and data access.
Bind access to workload and evidence
Use Conditional Access and least privilege for agents. Require a known workload, approved sponsor, and expected resource before allowing a token to be used.
The blueprint ID is a useful detection key. Proofpoint notes that the same blueprint ID remains consistent across tenants that consent to it, which allows defenders to find the same external object in multiple environments. Audit logs should connect these events rather than treating them as unrelated administrative activity.
| Event | Question to answer |
|---|---|
| External blueprint consent | Who approved it, what publisher information was shown, and which permissions were requested? |
| Blueprint principal creation | Was the principal expected, and does its owner have a documented business purpose? |
| Agent identity creation | Who is the sponsor, which blueprint created it, and why was another identity needed? |
| Token issuance and Graph activity | Does the identity access the resources and APIs associated with its approved workload? |
The consent screen is not the trust boundary
The consent dialog tells a user what the platform is about to authorize. It does not prove that the publisher is safe, that the blueprint will remain within its stated purpose, or that future identities will have no broader effective authority.
That distinction matters because agent systems make identity creation part of normal operation. A new agent principal is no longer an exceptional event. It can be the expected result of scaling a workflow, onboarding a business unit, or creating a temporary worker.
Security teams need a policy decision for each of those cases. The decision should be visible in the identity system and enforced at runtime, not inferred from the display name of an agent.
BluePhishing is a research proof of concept, and Proofpoint says it has not identified the technique in the wild. That is exactly why now is the right time to close the gap. Once agent blueprints become common, a malicious one will be harder to distinguish from the hundreds of legitimate identities that follow it.
The first control is simple: treat agent consent as privileged identity creation. The second is harder: keep checking what that identity does after it is approved.