Why does the usual permission read every mailbox?
Automations run without anyone signed in, so they use application permissions. Microsoft's Graph permissions reference describes the application version of Mail.Read as allowing the app to read mail in all mailboxes without a signed-in user. The delegated version reads only the signed-in user's mailbox, but that ties the automation to one person's account and sign-in. Granting the application permission in Entra ID with no further limit means a leaked client secret or certificate exposes every mailbox in the organisation, including the directors' and payroll's, when the workflow only needed the accounts inbox.
What is RBAC for Applications in Exchange Online?
RBAC for Applications lets an Exchange administrator grant an app permission to Exchange Online data and pair it with a resource scope that sets which mailboxes the app can reach. Microsoft states that it replaces Application Access Policies and works for Microsoft Graph and Exchange Web Services. The scope can be a management scope, which selects mailboxes with a filter on their properties, or a Microsoft Entra administrative unit. The person making the assignment needs to be in the Organization Management role group, or hold the Exchange Administrator role in Entra ID.
How is a scoped permission set up?
The work is done in Microsoft Entra ID and Exchange Online PowerShell. It suits a provider working under your administrator's supervision, with each change recorded. A management scope selects mailboxes with a filter on their properties, so a common approach is to set a custom attribute on the shared mailbox and filter on that attribute. Microsoft's documentation includes worked examples of both a management scope and an administrative unit. The outline below follows that documentation; use the current version of the page for exact parameters.
- Register the app in Microsoft Entra ID without granting tenant-wide Mail.Read.
- In Exchange Online, create a pointer to the app's service principal with New-ServicePrincipal.
- Create a management scope whose filter matches only the target mailbox, or use an administrative unit.
- Assign the role, for example Application Mail.Read, with New-ManagementRoleAssignment and the scope.
- Check the result with Test-ServicePrincipalAuthorization against an in-scope and an out-of-scope mailbox.
Why must the tenant-wide grant be removed?
Microsoft's documentation states that permissions from Entra ID and from Exchange RBAC for Applications are combined. If the app holds Mail.Read in Entra ID and a scoped Mail.Read in Exchange, the result has no effective scoping, because the Entra grant already covers every mailbox. Remove the Entra ID grant once the scoped assignment is in place and tested. Microsoft also notes that exclusive management scopes do not restrict app access, so use a normal management scope or an administrative unit. Keep a record of which grants exist in each place, so a later change does not quietly add tenant-wide access back.
How do you test that the limit works?
Run Test-ServicePrincipalAuthorization for the app against a mailbox that should be in scope and one that should not. The result shows InScope as true or false for each permission. This test bypasses Microsoft's permission cache, but live API calls do not: Microsoft says permission changes take between 30 minutes and 2 hours to apply, depending on how recently the app was used. After that period, make a real Graph call to an out-of-scope mailbox and confirm it is refused. Record both tests with the date, so the next review can repeat them.
What about sending mail, and Google Workspace?
Sending is a separate permission. The application Mail.Send permission allows an app to send mail as any user, so scope it the same way if the workflow sends replies. Choose the smallest role that does the job: Mail.ReadBasic, for example, excludes message bodies and attachments, which suits a workflow that only routes emails by sender and subject. In Google Workspace, domain-wide delegation lets a service account access users' data without their consent. Google advises checking that the app or service account has an appropriately small scope of access, so grant only the API scopes the workflow needs.
How should the app's credentials be looked after?
A scoped permission limits the damage if a credential leaks, but the credential still needs care. Prefer a certificate over a client secret where the automation platform supports it, and store either in a secrets vault, not in a workflow's settings screen or a shared document. Give it an expiry date and put the renewal in someone's calendar, because an expired secret stops the workflow without warning. Review the app's sign-in logs in Entra ID from time to time for unexpected locations or failures. When the provider changes or the workflow is retired, remove the role assignment, the service principal pointer and the app registration.