BluePhishing: Why AI Agent Consent Is the New OAuth Blind Spot (and 7 Checks for Your Entra Tenant)

Consent phishing has a new form. Instead of tricking someone into approving a fake app, an attacker can ask for approval of an AI agent. Proofpoint’s BluePhishing research, published November 9, 2026, shows how one such approval could let an attacker create a large number of agent identities in a Microsoft Entra tenant. Those identities are not people, so the controls built for people do not apply to them the same way.

Proofpoint describes BluePhishing as a proof of concept. It has not identified any in-the-wild activity. The research matters because it shows how the attack works, and because the default settings that enable it are changing now.

What BluePhishing Is

In plain terms, the attack works like this. The attacker creates an agent blueprint in a Microsoft Entra tenant the attacker controls. A blueprint is the template that defines an agent’s configuration and permissions, similar to an app registration. The attacker then sends the victim a consent link.

If the victim consents, a blueprint principal is created in the victim’s tenant, similar to a service principal. Proofpoint reports that this principal is automatically assigned the AgentIdentity.CreateAsManager permission. Microsoft does not allow that permission to be revoked from the principal, so disabling or removing the principal is the only way to stop it.

With that permission, the attacker can request a token for the victim tenant and create agent identities there. Proofpoint notes that each blueprint supports up to 250 agent identities, and that the agents can inherit permissions from the blueprint. The attacker also needs the victim’s tenant ID and the object ID of a sponsor in that tenant. Proofpoint says both can often be found through public endpoints and user enumeration.

BluePhishing is not a stolen password attack. It depends on a single approval that looks routine.

Why Existing Controls Miss It

Three gaps explain why these identities slip past familiar defenses.

Agent identities are not users. Multi-factor authentication and sign-in policies are designed for people. The same gap appeared in the MSP Process breach, where stolen app credentials reached customer tenants with no user sign-in and no MFA prompt. When an identity acts on its own, user-facing controls are not in the path.

The consent looks familiar. Users are used to approving apps, so an agent consent request can seem like one more prompt. Proofpoint notes that users may be more willing to consent to AI agents than to traditional apps, because awareness of this attack is low.

Inherited permissions are hard to see. Proofpoint cites Microsoft’s documentation as saying that inherited permissions are not visible in the Entra portal or through Microsoft Graph. They appear only in token contents at runtime. Microsoft’s admin center also includes a Granted permissions view for each blueprint, currently in preview. Use it, but do not assume it shows everything an agent can inherit. Check the effective permissions of each agent through its tokens as well.

The audit trail is also less clear than it should be. Microsoft’s preview known-issues page notes that audit logs do not distinguish agent identities from other identities. Operations on agent identities, blueprints, and blueprint principals are logged in the ApplicationManagement category.

The Default to Change Now

Under Microsoft message center item MC1506733, starting November 4, 2026, users without a built-in or custom Entra role can create agent blueprints unless an administrator turns off the setting “Users can create agent blueprints,” which sits under Default user role permissions.

Turning it off does not remove existing blueprints, and it does not stop agents from creating identities from blueprints that already exist. It controls only new blueprint creation. If your organization does not need user-created agents, set it to No now.

Seven Checks for Your Entra Tenant

1. Restrict user consent for agents. Entra’s user consent settings extend to agent blueprints, as Proofpoint notes. Limit who can consent to third-party agents, and route requests through the admin consent workflow so a person can ask for access without granting it.

2. Review consented blueprint principals. Open the Agents panel, select Agent blueprints, and check each third-party blueprint principal. Look for blueprints you did not request, and record the blueprint ID so you can search for it across the tenant. Proofpoint notes the ID is consistent across every tenant that consents to the same blueprint, which makes it a useful indicator.

3. Watch “Add application” and “Add service principal” events. Proofpoint identifies these as the audit events for blueprint and agent identity creation. Search the ApplicationManagement category, and alert on new blueprint principals and new agent identities. Pay attention to bursts of creation after a single consent.

4. Classify agent permissions. For each agent, record its permissions and rate them low, medium, or high risk. Treat directory write access, mailbox-wide access, and rights to change authentication methods as high risk. Microsoft blocks some high-risk Graph permissions, such as User.ReadWrite.All, for agents, but do not rely on that alone.

5. Apply Conditional Access and risk controls to agents. Proofpoint points to Conditional Access policies for agents and Entra ID Protection for agents as ways to limit what a compromised agent can do. Confirm which of these your license allows before you plan around them.

6. Assign an owner to every agent. An agent without an accountable person is a risk you cannot review or retire. Record the owner, the business purpose, and the approval date. Disable any agent that has no owner. Proofpoint notes that the sponsor requirement exists so that a person is accountable for each agent identity, and that a sponsor can be removed once the identity is created. Track sponsors separately.

7. Run recurring access reviews. Review agents, their permissions, and their owners on a fixed schedule, such as monthly for high-risk agents and quarterly for the rest. Remove access that no longer matches the agent’s task.

If You Find a Malicious Blueprint

Because the blueprint permission cannot be revoked from the principal, the practical response is to disable or remove the blueprint principal in the affected tenant. Then review every agent identity created from that blueprint, remove the agents, and check the audit log for the creation events. Search other tenants you manage for the same blueprint ID.

Why This Is an OAuth Problem Too

BluePhishing looks new, but its structure matches older OAuth consent attacks. Permissions are granted once, the grant persists, and the identity that holds them runs independently of the user who approved it. The MSP Process and ConnectWise incidents showed the same pattern at scale, where permissions granted in the past remained active after the original approval.

The difference is multiplicity. One approval can produce many identities, and each one can carry permissions that a reviewer has to understand separately.

Where OptyStack Fits

OptyStack’s discovery covers connections that tenant reviews often miss. It finds SaaS and AI tools using signals from spend, SSO, and browser activity, and it maps each tool to the people who sign in to it. It flags shadow AI and ranks each finding by risk, so unfamiliar agents and integrations appear in one inventory with an owner to assign.

OptyStack does not manage Entra agent blueprints or change consent settings in your tenant. Those controls belong to Entra and to your administrators. Before you rely on OptyStack for agent review, confirm in a demo whether it shows agent identities and blueprint-level permissions, and whether it supports recurring access reviews.

To see the apps and AI tools connected in your environment, you can start a free trial.