
{/* banner prompt: A clean isometric technical infographic. Two glowing email envelopes, each sealed inside its own separate glass vault. A small friendly robot stands at each vault holding a single distinct key that fits only its own vault. A third robot tries the wrong vault and its key bounces off, met by a red shield symbol reading "403". Light-gray background, muted blue-and-teal palette with a single red accent, sharp clean vector illustration, strong sense of enforced separation. */}

We were asked to give two colleagues an AI assistant that could work with their email: read the mailbox, search it, pull an attachment, draft a reply for them to review and send. Standard stuff. Microsoft Graph exposes all of it, and wiring an AI agent to Graph through a small server takes an afternoon.

The hard part wasn't the plumbing. It was one sentence in the requirements: *each person's assistant must be able to touch only that person's mailbox.* Not "should." Must. And "must" is a security claim: the kind you have to be able to prove, not merely intend.

This is the story of how we made that boundary real, and the three places it tried to fool us into thinking it was already there when it wasn't.

## Application permissions are tenant-wide by default

To act on a mailbox without a signed-in user, a Graph app uses *application permissions* and the client-credentials flow: the app authenticates as itself and calls the API. The permission we needed was `Mail.ReadWrite`, which covers reading too, so there's no separate read permission to add. Crucially, we did **not** grant `Mail.Send`. The app can create drafts but physically cannot transmit them; every reply lands in a Drafts folder for a human to send.

Here's the trap. `Mail.ReadWrite` as an *application* permission is **tenant-wide**. Once an admin consents, the app can read and write *every mailbox in the organisation*, not the one you had in mind, all of them.

We confirmed this the blunt way, before trusting anything. We took the app's own credentials, asked Microsoft for a token, and called the API against a *different* colleague's mailbox. It returned their inbox, cheerfully, with a message count. The app we had registered "for one person" could read the whole company.

So the app permission is not the boundary. It's the blast radius. The boundary has to come from somewhere else.

## Put the wall where a bug can't reach it

There are two ways to constrain which mailbox an app can touch.

The tempting one is to do it in your own code. The server knows which user's token is calling, so it just... refuses any request for a different mailbox. One shared app, a lookup table, a check before every call.

Don't. That wall lives entirely in your code, which means one missed check, one refactor, or one clever prompt-injection that talks your agent into passing a different address, and it's gone. When the requirement is "must," you don't want the enforcement sitting in the same place as the bugs.

The better option is a control the provider enforces: an **Application Access Policy** in Exchange Online. You create one small mail-enabled group per app, containing exactly the mailbox (or mailboxes) that app is allowed to touch, then bind a `RestrictAccess` policy from the app to that group. After that, Microsoft itself refuses any Graph call from that app to any mailbox outside the group: a `403`, at the source, regardless of what your code does or doesn't check.

So we registered **one app per person**, not one shared app with code checks, and pinned each to a single mailbox with its own access policy. Now the wall between the two users is enforced by Microsoft. A bug in our server cannot leak one person's mail to the other, because the credential itself cannot see it.

The general principle: *when you can push a boundary down to the layer that owns the data, do it.* Your code should rely on the wall, not be the wall.

## The setup, in PowerShell

Application Access Policies live in Exchange Online, so the whole thing is a short, one-time PowerShell run: one mail-enabled group and one `RestrictAccess` policy per app. (Placeholders below: `contoso.com`, two people `alice` and `bob`, and the Application/client ID of each person's app registration.)

```powershell
# Run once, interactively, signed in as an Exchange/Global admin on a managed device.
Connect-ExchangeOnline -UserPrincipalName admin@contoso.com

# One app registration per person; paste each app's Application (client) ID.
$aliceApp = '<alice-app-client-id>'
$bobApp   = '<bob-app-client-id>'

# One mail-enabled security group per app, holding only that person's mailbox(es).
New-DistributionGroup -Name 'sg-mail-alice' -Type Security `
  -PrimarySmtpAddress 'sg-mail-alice@contoso.com' -Members 'alice@contoso.com'
New-DistributionGroup -Name 'sg-mail-bob' -Type Security `
  -PrimarySmtpAddress 'sg-mail-bob@contoso.com' -Members 'bob@contoso.com'
# (A group can hold more than one mailbox — add every address that app may touch.)

# Pin each app to its group. After this, Graph refuses any mailbox outside it.
New-ApplicationAccessPolicy -AppId $aliceApp -PolicyScopeGroupId 'sg-mail-alice@contoso.com' `
  -AccessRight RestrictAccess -Description 'mail agent: alice -> own mailbox only'
New-ApplicationAccessPolicy -AppId $bobApp   -PolicyScopeGroupId 'sg-mail-bob@contoso.com' `
  -AccessRight RestrictAccess -Description 'mail agent: bob -> own mailbox only'

# Verify the policy DEFINITION: Granted for own mailbox, Denied for the other.
Test-ApplicationAccessPolicy -Identity alice@contoso.com -AppId $aliceApp   # Granted
Test-ApplicationAccessPolicy -Identity bob@contoso.com   -AppId $aliceApp   # Denied
Test-ApplicationAccessPolicy -Identity bob@contoso.com   -AppId $bobApp     # Granted
Test-ApplicationAccessPolicy -Identity alice@contoso.com -AppId $bobApp     # Denied
```

Those last four lines are Microsoft telling you the policy is correct. Which brings us to the first trap.

## "Configured" is not "enforced"

We created the policies and ran Microsoft's own checker, `Test-ApplicationAccessPolicy`, for every combination: each app against its own mailbox, each app against the other's. All four came back exactly right: Granted where it should be, Denied where it shouldn't. Green across the board.

Then we ran the *real* test, the app's credentials against the live API, the way the agent would actually use it, and every mailbox still returned `200`. Wide open. The policy was defined, verified by Microsoft's own tool, and completely un-enforced at runtime.

`Test-ApplicationAccessPolicy` tells you what the policy *says*. It does not tell you the enforcement layer has caught up. Those are different systems, and on the day we set this up they were **about four hours apart**.

The lesson generalises well beyond email: verify a security boundary the way it is actually exercised, not with the vendor's "is it configured?" checker. For an API boundary, that means real calls, with the real credentials, returning the real deny.

## Propagation is slow *and* uneven

The four-hour wait had a sting in the tail.

We polled the live API in the background, watching for the cross-mailbox calls to start returning `403`. Eventually they did, and we nearly declared victory on the spot, because we were only watching the deny cases.

Good thing we looked at the whole picture. Enforcement hadn't landed atomically. The blanket "deny everything" propagated first; the per-mailbox *allow list* lagged behind it. For a window, each app was denied **its own** mailbox, so the two users would have been locked out of their own email, while strangers' mail was (correctly) refused. The deny rule was live; the "except your own" hadn't caught up.

If we had gated go-live on "cross-mailbox returns 403," we'd have shipped a broken permission set. The right gate was the *entire* matrix correct at once, every allow returning `200` **and** every deny returning `403`, not a convenient subset. When a distributed system rolls out a rule, don't assume the parts you didn't check moved in lockstep with the parts you did.

## A detour: you can't always automate the admin step

One more trap, because it cost real time. Creating those access policies needs Exchange Online admin PowerShell, and we wanted to run it unattended from a server. We couldn't, for reasons worth knowing up front:

- The old, universally pre-consented "Exchange Online Remote PowerShell" app that used to make headless sign-in easy has been **disabled** by Microsoft.
- The device-code sign-in flow, the usual fallback for a machine with no browser, **cannot show a consent screen**, so it dead-ends on any app that isn't already consented.
- And even past that, the tenant's **Conditional Access** policy refused to issue a token to an unmanaged, unregistered device. (The error, if you ever meet it, is `AADSTS530035`.)

The lesson here isn't a workaround; it's an expectation. Admin actions in a well-secured Microsoft 365 tenant are *designed* to resist unattended automation. Plan to run them interactively, once, from a managed device, and build everything else around that single human step instead of fighting to remove it.

## What to check if you're doing this

1. **Prove the blast radius before you trust anything.** Take the app's own credentials and call a mailbox it shouldn't reach. If it answers, your boundary isn't there yet.
2. **Enforce isolation at the provider, not in your code.** One app per scope, each pinned by an Application Access Policy. Make a bug in your code harmless by construction.
3. **Never grant more than the job needs.** Drafting replies needs `Mail.ReadWrite`, not `Mail.Send`. If the app can't send, no bug or injection can make it send.
4. **Verify with real calls, not the "is it configured" checker.** Configured and enforced are different systems, sometimes hours apart.
5. **Gate go-live on the whole matrix.** Every allow *and* every deny correct, at the same moment, not the deny cases alone.

The reassuring part: once it settles, it is genuinely solid. The isolation isn't a promise in our code or a line in a runbook. It's Microsoft returning `403` to a credential that was never allowed to see the data in the first place. That's the kind of wall you can point at and call "must."


50ffde05273df1598df54e5813672be243916b8cb08ce1a19d6ea82778b1dc3f

How to scope an AI assistant's Microsoft 365 mailbox access with Exchange Application Access Policies, why the boundary belongs at the provider layer, and the verification and propagation traps we hit along the way.

Giving an AI assistant read-and-draft access to a Microsoft 365 mailbox is easy. Making sure it can touch only the right mailbox, enforced by Microsoft rather than by your own code, is where the real work is.

Letting an AI Read Email Without Letting It Read Everyone's


{/* banner prompt: A clean isometric technical illustration of a Windows laptop caught between two tall cloud-office towers in different colors. A jammed identity turnstile made of key cards and token rings blocks the direct path from the laptop to the second tower. A confident blue mail bird carrying a sealed envelope flies around the turnstile through a separate glowing OAuth gateway. Light gray background, restrained blue, teal and amber palette, crisp editorial infographic style, no company logos, no readable text, no error-code typography. */}

The mailbox was healthy. Outlook on the web worked. The same account worked on other computers. Only one Windows PC refused to add it, and that PC happened to be Microsoft Entra joined to a *different* tenant.

That distinction sent us through three separate identity systems wearing one Outlook-shaped trench coat: Windows Web Account Manager (WAM), Microsoft 365 desktop licensing, and Outlook's own profile state. We cleared caches, counted accounts, reset applications, tested both Outlook clients, and captured the exact broker errors. Each step explained a symptom. None produced a dependable mailbox.

Our final answer was not another registry key. It was **use Thunderbird instead**.

This is what we learned, including how to configure Thunderbird without falling back to the basic-authentication password prompt that Microsoft 365 has already retired.

## The setup that triggered it

The Windows user signed in with an account from Tenant A. The device was fully Entra joined to Tenant A and held a Primary Refresh Token (PRT) for that identity. The user also needed a normal Exchange Online mailbox from Tenant B.

The Tenant B mailbox was not broken:

- Outlook on the web worked.
- The credentials and MFA worked.
- The mailbox worked on computers that were not joined to Tenant A.
- Autodiscover and Exchange Online were reachable.

That left the local identity context as the meaningful difference.

## Four errors, four different layers

The failure changed as we removed stale state. That was useful: each new message exposed the next layer underneath.

<Table data={
    {
        headers: ['Client or test', 'Visible symptom', 'What it actually told us'],
        rows: [
            ['New and classic Outlook', 'Add account operation is blocked because account limit is reached', 'Windows WAM believed the user had exhausted its Entra account slots'],
            ['New Outlook after reset', 'Your account is not supported', 'The mailbox could not license new Outlook as its first account'],
            ['Classic Outlook', 'An unexpected error occurred, tag 7anyj', 'The Windows identity broker could not match Outlook\'s login hint to a cached WebAccount'],
            ['Manual IMAP in Outlook', 'A plain username and password prompt', 'Outlook had selected basic authentication, which Exchange Online no longer accepts'],
        ]
    }
} />

Treating all four as "Outlook cannot sign in" would have produced an endless loop of reinstalls. They came from different components and needed different evidence.

## The account-limit detour

Windows 10 and 11 limit a user session to three Microsoft Entra accounts. Microsoft documents the exact resulting message: *"Add account operation is blocked because account limit is reached."* The limit exists to control token-request size and keep single sign-on reliable. See the [Microsoft Entra device management FAQ](https://learn.microsoft.com/en-ca/entra/identity/devices/faq).

The important words are **user session**. Our remote management shell ran as `SYSTEM`, so this command initially inspected the wrong profile:

```powershell
dsregcmd /listaccounts
```

The giveaway was immediate:

```text
USERPROFILE=C:\Windows\System32\config\systemprofile
```

WAM is per-user state. An elevated shell, service, RMM agent, or SSH daemon commonly runs under a service account and can return an empty list or a meaningless error even while the interactive user has a broken account store.

We used a temporary scheduled task with `LogonType=Interactive` to execute `dsregcmd /listaccounts` inside the signed-in user's session. After backing up and rebuilding the TokenBroker account directory, the real result was clean:

```text
User accounts: 1
Application accounts: 0
Default account: tenant-a-user@example.com
```

The count was no longer the blocker. Outlook still failed.

## The silent cleanup script trap

Microsoft provides `signoutofwamaccounts.ps1` for removing Office-associated WAM tokens on managed devices. It is a legitimate tool, but it has two operational surprises:

1. It is deliberately silent. Its asynchronous results are piped to `Out-Null`, so no output can mean success, failure before useful work, or simply no matching Office accounts.
2. It works on the current user's WAM store. Running it from an RMM shell as `SYSTEM`, or as a different administrator, does not clean the affected desktop user's account store.

Microsoft's [activation reset guidance](https://learn.microsoft.com/en-us/previous-versions/troubleshoot/microsoft-365/microsoft-365-apps/activation/reset-office-365-proplus-activation-state) correctly says the script removes Office tokens without unjoining an Entra-joined device. What it cannot do is make a service-context PowerShell session become the interactive user.

The reusable rule is simple: when troubleshooting WAM, always record `whoami`, `$env:USERPROFILE`, and the session ID beside every result.

## New Outlook exposed a licensing problem

Resetting the new Outlook package did not clear all of its data. Its packaged `LocalState` and `LocalCache` were empty, while `%LOCALAPPDATA%\Microsoft\Olk` still contained the account state. Renaming `Olk` to a timestamped backup finally produced a genuine first-run experience.

The next message was *"Your account is not supported."*

That was progress, not regression. New Outlook reads the licence attached to its accounts. Microsoft says a work or school account needs a plan that includes desktop applications to license Outlook as the initial account. Once a qualifying account is present, Business Basic or E1 mailboxes can be added as secondary accounts. The details are in [Microsoft's new Outlook licensing guide](https://learn.microsoft.com/en-us/microsoft-365-apps/outlook/get-started/licensing-options).

In this case the second tenant's mailbox was not a suitable first account. Adding the Tenant A account first was theoretically valid, but it pulled us straight back into the cross-tenant WAM path we were trying to escape.

## Classic Outlook gave us the decisive evidence

Classic Outlook replaced the licensing message with a generic page:

```text
Message: An unexpected error occurred.
Tag: 7anyj
Code:
```

The page itself was nearly useless. The timestamp was not.

We queried `Microsoft-Windows-AAD/Operational` for the surrounding twelve minutes. At the same second as the Outlook error, Windows logged an application-specific account warning. Before and after it, Event ID 1098 repeated this error:

```text
0xCAA100D8
A login hint was sent that doesn't match any WebAccount in the system.
```

That closed the loop. Outlook was asking WAM silently for Tenant B, but WAM contained only Tenant A. The browser credentials were fine. The Exchange mailbox was fine. The tenant was fine. The local broker could not map the requested identity to an account in its store.

We tried seeding the second Office identity through another desktop Office application. That also failed. At that point we could keep editing identity stores and registry associations, or we could choose a mail client that did not inherit the Windows session's PRT and Office WAM state.

## Why guest accounts and cross-tenant settings were not the first fix

Inviting the user as a guest into Tenant B sounds attractive, but a B2B guest object does not turn an existing mailbox login into a healthy Outlook desktop identity. Cross-tenant access settings can control trust, MFA claims, device claims, and inbound or outbound B2B access. They do not repair a local WAM account mapping.

Those settings matter when the Tenant B sign-in logs show a Conditional Access or cross-tenant policy denial. Our evidence stopped earlier: Windows could not even match the login hint to a local WebAccount.

Fix the layer that failed. Do not redesign tenant trust because a local token broker returned `0xCAA100D8`.

## Why Thunderbird was the practical answer

Thunderbird runs its own Microsoft OAuth flow and maintains its own account state. It does not need Outlook to reconcile Tenant A's Windows PRT with Tenant B's mailbox identity. That makes it a clean isolation boundary: the user signs directly into the mailbox's home tenant, completes MFA, and Thunderbird stores the resulting OAuth tokens in its own profile.

As of Thunderbird 153, native Exchange email over EWS is available without an add-on. Mozilla's [Thunderbird and Exchange guide](https://support.mozilla.org/en-US/kb/thunderbird-and-exchange) recommends version 145 or later and explains the Microsoft-hosted OAuth prompt. Thunderbird 153 made that support prominent in the new Account Hub; see the [Thunderbird 153 release announcement](https://blog.thunderbird.net/2026/07/thunderbird-153-meadow-is-out-now/).

For this kind of case, the immediate setup is:

1. Install Thunderbird 153 or newer.
2. Select **New Account → Email**.
3. Enter the Tenant B mailbox address.
4. Let Account Hub detect Exchange, or select **Manual Configuration → EWS**.
5. Complete the branded Microsoft OAuth and MFA flow for Tenant B.

Do not type the mailbox password into a "Normal password" IMAP configuration. Microsoft removed basic authentication from Exchange Online. OAuth is the difference between "IMAP is obsolete" and "IMAP works securely with Microsoft 365."

If EWS is unavailable, use IMAP and SMTP with OAuth2:

<Table data={
    {
        headers: ['Purpose', 'Server', 'Port and transport', 'Authentication'],
        rows: [
            ['Incoming mail', 'outlook.office365.com', '993, SSL/TLS', 'OAuth2'],
            ['Outgoing mail', 'smtp.office365.com', '587, STARTTLS', 'OAuth2'],
        ]
    }
} />

Microsoft explicitly lists Thunderbird as an Exchange Online IMAP client in its [POP3 and IMAP4 documentation](https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/pop3-and-imap4/pop3-and-imap4). Mozilla's [Microsoft OAuth guide for Thunderbird](https://support.mozilla.org/en-US/kb/microsoft-oauth-authentication-and-thunderbird-202) also notes two tenant-side caveats: an administrator may need to approve Thunderbird once, and SMTP AUTH may need to be enabled for sending.

## The EWS warning in August 2026

Native EWS is a good immediate bridge, not a forever architecture for Exchange Online. Microsoft begins phased EWS disablement on October 1, 2026 and plans full retirement on April 1, 2027. Administrators can temporarily allow approved EWS applications during the transition. Microsoft's current timeline is in [Deprecation of Exchange Web Services in Exchange Online](https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-ews-exchange-online).

Thunderbird's Graph implementation was approaching feature parity in June 2026, but Thunderbird 153 still shipped it behind a preference while the project completed the work. For a deployment made today:

- Use native EWS if it works and the tenant is prepared to allow it during the transition.
- Use IMAP/SMTP with OAuth2 for basic mail when EWS is blocked.
- Track Thunderbird's Graph rollout for the long-term Exchange path.
- Expect email first; Exchange calendar and address-book parity is still catching up.

## What we would do first next time

1. **Prove the mailbox independently.** Test OWA and a non-joined device before touching the tenant.
2. **Map the identity contexts.** Record Windows sign-in tenant, device join tenant, mailbox tenant, Office licensing account, and the user context of every shell.
3. **Run WAM diagnostics as the interactive user.** Never trust `dsregcmd /listaccounts` from `SYSTEM` for a desktop-user problem.
4. **Use the error timestamp as a join key.** A generic Outlook page becomes actionable when matched to `Microsoft-Windows-AAD/Operational`.
5. **Separate authentication from licensing.** "Account not supported" in new Outlook can be a licence decision even when OAuth and Exchange are healthy.
6. **Stop when the architecture is fighting the requirement.** A second mail client is cheaper and safer than repeatedly rewriting a joined user's identity stores.

The technical lesson is not that Outlook is bad or Thunderbird is magic. It is that coupling matters. Outlook integrates deeply with Windows and Microsoft 365, which is excellent when the device, user, licence, and mailbox all belong to one identity story. In a two-tenant edge case, the integration itself can become the failure domain.

Thunderbird gave the second mailbox its own OAuth boundary. That was the feature we actually needed.


69553745fb3591b6a7188b74db6f66d2e843e59bfbb58dd754d08c3b00cb0a81

A practical investigation of cross-tenant Outlook failures on an Entra-joined Windows PC, including WAM diagnostics, misleading fixes, and the Thunderbird alternative.

A Microsoft Entra-joined PC could open a second tenant's mailbox everywhere except Outlook. WAM limits, PRT routing, licensing checks, and a silent cleanup script eventually pointed us to the simpler answer: Thunderbird with OAuth.

Tag: Microsoft 365

Tag: Microsoft 365

Letting an AI Read Email Without Letting It Read Everyone's

Two Microsoft 365 Tenants, One Windows Session: Why We Chose Thunderbird