Configure the integration with delegated Mail.Read.Shared, require assignment to the enterprise application, assign only the authorized user, and do not approve the consent request while it still includes Mail.ReadWrite, Mail.Send, or any application permission.
Recommended least-privilege configuration
- Use delegated permissions only
- For access to both the signed-in user’s mailbox and mailboxes or folders already shared with that user,
Mail.Read.Shared is generally sufficient by itself.
- It permits reading mail the signed-in user can access, including their own and shared mail.
- It does not grant write or send capability. ^1^
Mail.Read.Shared does not create mailbox rights. An Exchange administrator must separately grant the user read access to each intended shared mailbox or folder. Validate this by signing in as that user and confirming the mailbox or folder is readable in Outlook. If the mailbox has not been shared or delegated to the user, Graph access returns an error. ^2^
- Restrict sign-in to one user
- Microsoft Entra admin center → Entra ID → Enterprise apps → All applications → select the ChatGPT integration.
- Open Properties.
- Set Assignment required? to Yes and save.
- Open Users and groups and assign only the designated user.
With assignment required, only assigned identities can obtain a token for the application. Global Administrators are an exception to assignment enforcement. ^3^
- Prefer consent for the single user where possible Instead of tenant-wide consent, a Cloud Application Administrator, Application Administrator, or Privileged Role Administrator can grant delegated consent on behalf of one user. The executable Microsoft Graph method creates an OAuth grant with:
{
"clientId": "<enterprise-app-service-principal-id>",
"consentType": "Principal",
"resourceId": "<Microsoft-Graph-service-principal-id>",
"principalId": "<authorized-user-object-id>",
"scope": "Mail.Read.Shared"
}
ConsentType: Principal and PrincipalId bind the delegated grant to that user. Programmatic grants take effect immediately, so verify all IDs and the exact scope first. The complete PowerShell and Graph procedures are documented here. ^4^
If the vendor requires tenant-wide admin consent instead, assignment still limits who can sign in. Tenant-wide consent authorizes the delegated scopes for users across the organization; it does not turn a delegated permission into app-only mailbox access. ^5^
Verify delegated versus application access
In Enterprise apps → application → Permissions:
- Admin consent shows permissions already granted tenant-wide.
- User consent shows permissions already granted for particular users or groups.
- Open each permission’s details and verify its permission type.
- There should be no Microsoft Graph application permission such as application
Mail.Read or Mail.ReadWrite.
Application Mail.Read means reading all mailboxes without a signed-in user; delegated Mail.Read means reading the signed-in user’s mailbox. The identical scope name can therefore be misleading unless its permission type is inspected. ^1^
If the actual Graph access token can be securely obtained from the integration:
- Delegated permissions appear in the token’s
scp claim.
- Application permissions appear in
roles, normally without scp.
- App-only permissions can be obtained through the client-credentials flow; delegated permissions use an interactive user flow. ^6^
If the third-party integration does not expose its token, rely on the enterprise application’s permission details and require the vendor to identify its client ID, OAuth flow, requested scopes, and a sample token-claim listing with secrets removed.
Why the consent prompt can show broader permissions
Disabling tools in ChatGPT does not prove that the corresponding Microsoft Graph scopes were removed from the OAuth request or vendor-owned application registration.
Two Microsoft identity behaviors can produce the discrepancy:
- An application can request delegated scopes dynamically at runtime. ^7^
- A request for
https://graph.microsoft.com/.default can prompt for all required permissions configured on the application registration when consent does not already exist. ^8^
Therefore distinguish:
- Requested permissions: displayed by the current consent prompt.
- Granted permissions: recorded on the enterprise application’s Permissions page.
Do not approve based only on the integration’s tool settings. The live Microsoft consent prompt represents what the application is currently asking Microsoft Entra to authorize.
Remove existing excessive grants
A Cloud Application Administrator or Application Administrator can review and revoke grants:
- Entra ID → Enterprise apps → All applications → application → Permissions.
- Select Admin consent.
- For each unwanted grant, select … → Revoke permission.
- Review User consent as well; user grants cannot be revoked from that portal tab and require Microsoft Graph or PowerShell.
Revocation does not prevent the application from requesting the permission again dynamically. If a new authorization attempt still requests Mail.ReadWrite or Mail.Send, deny it and ask the vendor to remove those scopes from its OAuth request or registration. ^9^
The approval criteria should be: the correct publisher and client ID, only delegated Mail.Read.Shared, assignment to the one authorized user, and Exchange read rights granted only to the intended shared mailboxes.
References
- Microsoft Graph permissions reference
- Get Outlook messages in a shared or delegated folder
- Properties of an enterprise application
- Grant consent on behalf of a single user by using PowerShell
- Grant tenant-wide admin consent to an application (ms-graph)
- Application and delegated permissions for access tokens in the Microsoft identity platform
- Developer’s guide to requesting permissions and consent in Microsoft Identity Platform
- Scopes and permissions in the Microsoft identity platform
- Review permissions granted to enterprise applications (portal)