Microsoft 365 OAuth Risks: AI Agents and Consent Phishing

ChatGPT did not create Microsoft 365’s OAuth consent problem. It made the problem easier to see.

Connecting ChatGPT, Claude, or another AI agent to Microsoft 365 can turn a chat interface into a client for company email, files, calendars, contacts, or directory data. The important questions are which application was approved, what access it received, and who owns that decision.

Delegated OAuth access is also a threat surface of its own. Consent phishing can persuade a user to approve a malicious application without stealing a password. A legitimate integration can become unsafe if its infrastructure, publisher account, or stored tokens are compromised. MFA protects authentication, but it does not make a harmful consent decision safe or remove permissions already granted to an application.

Identify the application behind the AI connector

An AI tool may not connect to Microsoft 365 directly. A built-in connector, third-party integration, or MCP server may use a Microsoft Entra application to call Microsoft Graph. That Entra application holds the OAuth permissions, not simply the AI product name visible to the user.

For example, Claude may call an MCP server, which then calls Microsoft Graph. The permissions belong to the registered application used by that server. ChatGPT integrations can follow a similar connector pattern. The product name visible to a user does not, by itself, establish the application’s publisher or effective access.

Review the Entra application identity, publisher, consent type, and granted permissions. A familiar display name is not enough because application names can be copied.

OAuth approval can also become a data-governance decision. When an AI connector retrieves company content, the provider or its subprocessors may process or retain it outside Microsoft 365. Check the data-processing agreement, processing locations, cross-border transfer safeguards, retention and deletion controls, model-training policy, and differences between enterprise and consumer accounts. Permission alone does not prove that data was transferred.

How delegated access becomes a threat

An OAuth grant shows authorization, not malicious behavior. Several events can turn that authorization into an attack path:

• Consent phishing: A user approves a malicious app through Microsoft’s real sign-in and consent pages. The attacker does not need to imitate a password prompt or defeat MFA.
• Supplier compromise: A legitimate SaaS integration, MCP server, or deployment pipeline is breached. Existing grants may provide a route to customer data.
• Token theft: Stolen access or refresh tokens may be used without asking the user to approve the app again.
• Publisher impersonation: A malicious app uses a convincing name or domain. Names alone are not proof of authenticity.
• Stale consent: A former supplier, trial, or abandoned integration retains permissions without an owner to justify them.

The review question is the same: which applications retain useful access to company data, and can the organization justify each grant?

Control who can grant new access

The tenant’s user consent policy is the first preventive layer. Microsoft recommends either blocking user consent or allowing it only for verified publishers and selected low-risk permissions, with other requests sent for administrator review.

This reduces consent-phishing opportunities, but it does not revoke existing grants or protect a legitimate supplier that is compromised later. An MSP therefore needs both controls: a restrictive policy for new consent and an inventory of delegated grants already in place.

Tenant-wide consent does not mean every mailbox is exposed

Microsoft Graph has two important permission models.

Delegated permissions let an application act for a signed-in user. Its effective access is limited by both the granted OAuth scopes and what that user can already reach. A delegated Files.Read.All grant does not automatically let an ordinary employee read every file in the tenant; it lets the app read files available to that employee.

Administrator consent for all users removes the need for each person to obtain a separate admin approval. It does not convert delegated access into unrestricted tenant-wide access. It does, however, make adoption easier and extends the original approval decision to more users.

Application permissions work without a signed-in user and can provide broader access, but an administrator must explicitly grant them. They are a separate app-only model and require a separate review.

Microsoft’s Graph permissions overview explains the distinction and recommends least-privileged access.

Read the permissions as business capabilities

Read permission names as business capabilities. Calendar read/write access may suit a scheduling service. Mail read/write and send access lets an app change and send messages as the user. File permissions apply to reachable SharePoint and OneDrive content, while directory permissions expose organizational data. These are authorized capabilities, not evidence of activity.

For each grant, confirm the owner, publisher, business purpose, current use, consent audience, and whether read, write, or send access is still justified.

Microsoft recommends routinely auditing applications and consented permissions. Its guidance on consent phishing also warns against trusting an application name alone. For AI deployments, Microsoft advises applying the same governance and lifecycle controls used for other corporate applications in its secure generative AI guidance.

Make application access reviewable

PosturIQ checks whether users can unilaterally grant application access. It also performs a read-only review of delegated OAuth grants to non-Microsoft applications, highlighting sensitive access and distinguishing organization-wide consent from individual grants.

The findings are a starting point, not a verdict on the vendor. After confirming the publisher, owner, current use, and least privilege, an MSP can revoke unused access or accept a justified risk with a reason, owner, and review date. If the evidence changes, the finding requires a fresh decision instead of inheriting the old exception.

A later assessment verifies the result. Application permissions and other app-only access require a separate review.

This is one part of a wider small business security posture audit: users are not the only identities with access to company data, and application approvals should not become permanent simply because they happened once.