Why a mailbox scope is not enough to secure a Microsoft 365 automation

A Microsoft 365 automation should have access to the mailboxes its job requires. That sounds straightforward until an application has received permissions through more than one route. A narrowly scoped Exchange role can coexist with a broader application grant in Microsoft Entra ID. The practical question is therefore not simply whether a mailbox scope exists. It is whether the application's effective access is limited to that scope. Before trusting a mail-processing bot, test both what it can do and what it must be unable to do.

Consider a small business that wants a service to read replies in one approval mailbox and send notifications from an automation mailbox. The service does not need to read payroll correspondence, delete messages, or send mail as the owner. Write those boundaries down before creating permissions. A useful starting table has four columns: operation, allowed mailbox, denied mailbox, and evidence. This changes a vague request for mail access into a set of checks that an administrator can repeat after configuration changes.

First establish which identity the application uses. Microsoft Graph distinguishes delegated access, where an application acts on behalf of a signed-in user, from application access, where it operates without a signed-in user. An unattended job needs a deliberate service-identity design; a browser session left open on a desktop is not a dependable substitute. Record the tenant, application ID and service-principal object ID. Treat a display name as a label. Two registrations can have similar names while holding different permissions, certificates and owners.

For Exchange Online application access, Microsoft's RBAC for Applications supports role assignments combined with resource scopes. This lets an administrator describe the mailboxes an application should reach. The important qualification is that these grants are independent of unscoped permissions granted in Entra ID. A restrictive Exchange assignment does not erase a broader Entra grant. Review both places. Do not conclude that a restriction is effective merely because the Exchange scope looks correct in isolation. Microsoft's documentation explicitly calls out the relationship between these permission paths.

A practical review starts with the service principal, not the application name in an email template. Match the identity used to acquire the token to the identity configured in Exchange. Then inventory the relevant application roles and Entra application grants. For a reader, ask whether Mail.Read is sufficient. For a sender, identify the particular mailbox it may send from. Avoid adding Mail.ReadWrite simply to remember which replies have been processed: the automation can keep message identifiers and processing state in its own durable database. Permission should follow a needed operation, not a convenient implementation shortcut.

Next, perform a positive test and a negative test using the same service identity. The positive test should read a harmless test message from an allowed mailbox. The negative test should attempt the corresponding operation against an unrelated mailbox and be denied. Use safe fixtures and record the time, mailbox object identifier, endpoint, response status and service identity. Do not copy real customer mail into a test report. If the unrelated mailbox is readable, stop the rollout and investigate effective permissions instead of documenting the scope as complete.

Exchange provides Test-ServicePrincipalAuthorization to inspect its application RBAC assignments. Use it, but understand its limit: Microsoft notes that the command does not account for permissions separately granted in Entra ID. That is why a configuration result and a real API denial answer different questions. Also allow for permission propagation. Microsoft's documentation describes caching delays for application permission changes. During that interval, a mixed set of results needs investigation and a later retest; it is not a reason to relax the intended boundary or silently switch to an administrator's token.

Separate mailbox access from authority to act on the contents. A message that says Approved is still untrusted input. A publication or payment workflow needs to establish who authored the response, which request it answers, whether it is current, and whether the approved material has changed. Display names and matching email domains are insufficient. Shared-mailbox Send As behavior can obscure the individual human actor. If the workflow cannot establish the actor reliably, hold the action for clarification. Do not let a language model decide whether an email grants operational authority.

Reliable polling has its own boundary. Microsoft Graph message delta is a per-folder change-tracking mechanism. Follow all returned pages, preserve the returned continuation or delta URL, and persist processing state so a restart can safely replay a page. Record each message identifier once and make the resulting action idempotent. The purpose is not to guarantee that a delivery system never repeats an event; it is to ensure that repeating an event cannot publish the same article twice. A lost cursor should lead to controlled reconciliation, not a guess based on unread messages.

Treat sending and delivery as separate observations too. The Graph sendMail operation returns an accepted response before all delivery processing necessarily finishes. A workflow should distinguish queued, accepted, delivered, and replied states where evidence is available. When a network timeout leaves the outcome uncertain, immediately sending a second copy may create confusion for the reviewer. Keep the original request identifier and reconcile the outcome before retrying. Operational timestamps belong outside the editorial content digest so bookkeeping does not silently invalidate an otherwise unchanged review.

Before enabling a schedule, test failure and recovery. Restart the service with a request still pending. Replay a duplicate reply. Try an expired request, a reply quoting an earlier approval, and a response from an unauthorized test identity. Restore the state database into an isolated location and confirm that it cannot become a second active publisher. Keep the drafting component separate from the credential that authorizes publication. These are recommended engineering tests for the example workflow, not a claim that any particular tenant or product is already configured this way.

The trade-off is a little more setup and a much clearer operating boundary. Scoped permissions do not eliminate the need for credential rotation, monitoring, owner accountability or periodic access review. They limit what a failure can reach. For a business considering mailbox automation, the useful next step is to document one workflow, its allowed operations and its denied operations, then review the tenant evidence against that contract. Ultiblob's managed IT service page is an appropriate starting point for discussing Microsoft 365 operations; its AI services page covers broader automation opportunities. Agree the actual service scope and acceptance checks before enabling unattended actions.