
{/* 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` — it 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 — 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."


f0877050944e48dbf3b70a3ed52cbfd8dccfd4e8e9b3f53b26e61ebea5ddb427

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, not by your own code — is where the real work is.

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


{/* banner prompt: A vivid isometric infographic scene of a small friendly robot (an AI agent) reaching toward a laptop with a wrench in one hand, while a large shield-shaped antivirus icon looms over it, its glowing eye watching. Three of the robot's tools (a floppy disk, a gear, and a key) are shown mid-air, each caught in a translucent red "quarantined" bubble launched from the shield. Clean light-gray background, sharp isometric perspective, muted blue-and-red palette, technical but approachable, no readable text or logos. */}

We gave an AI agent real hands on a Windows machine: reach it over the network, install itself, register a background service, and get to work unattended. Straightforward, we thought — until the machine had Bitdefender GravityZone on it, and the agent could see the machine perfectly well but couldn't actually *do* anything to it. Not because of a bug in our code. Because an endpoint protection product was quietly erasing our binary and blocking Windows' own service-management APIs, without a single visible error pointing at the real cause.

This is the anatomy of that block, three layers deep, and the exact GravityZone settings that let an automated agent actually operate on a managed endpoint.

## Layer 1: the binary just disappears

The first symptom looked like a download bug. Our install step used a plain `WebClient.DownloadFile` to fetch the agent binary, and it failed with a generic wrapper exception: *"An exception occurred during a WebClient request."* No useful detail.

The real cause was buried in `.Exception.InnerException`, only visible with `Format-List * -Force`:

```
System.UnauthorizedAccessException: Access to the path
'...\agent.exe' is denied.
```

Access denied, on a fresh download, to a brand-new file, in a folder we owned. Ruling out the obvious suspects — TLS, proxy, file locks, ACLs — took a while, because every one of them came back clean. What finally confirmed it: a pure local `Rename-Item` on the same filename, no network involved at all, threw the identical `UnauthorizedAccessException`. That ruled out anything related to how the file arrived (download provenance, Mark-of-the-Web, whatever) and pointed at one thing: **something was reacting to the filename itself, the instant it appeared on disk.**

`Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct` gave the answer: Bitdefender Endpoint Security Tools, centrally managed through GravityZone. It was quarantining the binary on write, silently, with no local error dialog and no entry in the Windows Application or System event logs — Bitdefender logs to its own console, not to Windows, so `Get-WinEvent` finds nothing. From the process's point of view it just looks like the filesystem refused to cooperate.

## Layer 2: even SYSTEM can't create a service

Once we worked around the file-quarantine (more on the fix below), the same binary would download and sit on disk just fine. Installing it as a Windows service was the next wall:

```
Error: install service (run as Administrator if not elevated): Access is denied.
```

Our first assumption was a permissions problem in our own service-install code. To rule that out, we dropped straight to the raw OS tool, running as `nt authority\system`:

```
sc.exe create myagent binPath= "C:\Path\To\agent.exe" start= auto
[SC] CreateService FAILED 5:
Access is denied.
```

`SYSTEM` failing `CreateService` with error 5 is not a permissions problem — SYSTEM has unrestricted access to the Service Control Manager by definition. Something was intercepting the call itself. That's a signature of behavioral/EDR monitoring, not access control: GravityZone's **Advanced Threat Control** module watches for exactly this pattern — a process registering itself as a persistent Windows service — and treats it as a textbook malware-persistence technique, regardless of whether the binary passed the earlier file scan.

## Layer 3: the registry write underneath it

`CreateService` isn't a single atomic action from Windows' perspective — it writes a new key under `HKLM\SYSTEM\CurrentControlSet\Services`. That key path falls under GravityZone's **Sensitive Registry Protection**, a separate sub-feature of Advanced Threat Control that specifically guards persistence-related registry locations and can kill the offending process outright. Two independent enforcement layers were converging on the same operation for two different reasons: one watching "is this process trying to persist," the other watching "is this process touching a sensitive registry key." Either one alone is enough to block a legitimate service install.

## Where "just add an exclusion" falls short

The standard advice for AV false positives is an exclusion: GravityZone's **Antimalware → Exclusions** tab lets you add a Folder, File, Process, or Extension exclusion, and pick which scanning **Modules** it applies to (on-access, on-demand, and — separately — **ATC/IDS**, GravityZone's label for Advanced Threat Control and its Intrusion Detection System). We added both a folder and a process exclusion with all modules selected, including ATC/IDS.

It stopped Layer 1. It did **not** stop Layer 2 or Layer 3. Sensitive Registry Protection turned out to be its own gate, evaluated independently of the Exclusions list — an exclusion tells the scanner to skip a file or process, but it doesn't override a behavioral rule that's watching a system resource (the registry key) rather than the process that's touching it.

## The actual fix

Two policy settings, both under **Antimalware → On-Execute → Advanced Threat Control** in the GravityZone policy:

<Table data={
    {
        headers: ['Setting', 'Default', 'Changed to'],
        rows: [
            ['Action for infected applications', 'Block / Kill process', 'Report only'],
            ['Sensitive Registry Protection', 'Block / Kill process', 'Report only'],
        ]
    }
} />

"Report only" keeps GravityZone watching and logging — you still get visibility into what the agent is doing on the endpoint — but stops it from silently killing the process or deleting the file before the operation can complete. We kept the folder and process exclusions from earlier too, as a belt-and-suspenders measure for the plain file-scan layer, but the two "Report only" toggles are what actually unblocked service installation and registry writes.

This is a real trade-off, not a free lunch. Loosening ATC's response mode on a managed endpoint reduces the odds it auto-remediates a genuine compromise on that box. The right scope for this change is narrow: apply it via a dedicated policy assigned only to endpoints that are supposed to run this kind of automation, not your default fleet-wide policy — and keep "Report only" instead of disabling the module outright, so you still see every detection GravityZone would otherwise have acted on.

## What to check if your automation is being silently eaten

If a process on a GravityZone-managed Windows box can create files but can't seem to keep them, or can enumerate/read everything but can't write to the service registry or call `CreateService`, even running as SYSTEM:

1. **Get past the wrapper exception.** .NET's `WebClient`/`HttpClient` errors and generic "Access is denied" messages hide the real exception. Always drill into `.Exception.InnerException` (`Format-List * -Force` in PowerShell) before concluding it's your own code.
2. **Rule out provenance with a pure local operation.** If `Rename-Item` on the same destination filename also fails with no network involved, the block is about the file/process identity, not how it arrived.
3. **Identify the real AV product**, don't assume it's Windows Defender. `Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct` tells you what's actually active — often a third-party product has silently superseded Defender, and Defender's own cmdlets (`Get-MpPreference`) will fail with a generic COM error when that's the case.
4. **Test service creation with the raw OS tool**, not your own code. `sc.exe create` failing under SYSTEM isolates the problem to the platform/EDR layer, not your service-install logic.
5. **Don't stop at Exclusions.** A file/process exclusion silences on-access scanning, but a dedicated behavioral rule — like registry-key protection — can still be watching the *resource* rather than the *process*, and needs its own toggle.

The broader lesson: modern EDR products don't have one enforcement point, they have several, stacked on different signals — file content, process behavior, and resource access — and each one can independently veto the same operation for a different reason. Debugging "access denied" on a managed endpoint means finding out which layer is actually talking, not just the first one you can reproduce.

c7a32d8904e2b087f20b4cdaf8ed027394a9e954e6a0c239b6c3116bdc9a7043

How Bitdefender GravityZone silently blocked an AI agent's own binary, service installation, and registry writes on Windows, and the exact policy settings that fixed it.

Our AI ops agent could reach a Windows box over the network but couldn't install itself, start its own service, or even keep its own binary on disk. The culprit: Bitdefender GravityZone silently eating it, one enforcement layer at a time.

When Your Antivirus Fights Your AI Agent: A Bitdefender GravityZone War Story

554907b6924a38f48066abe6723b969f08e202f563c5d59e021ba5862a1a38d6

Learn about the React2Shell vulnerability (CVE-2025-66478) affecting Next.js apps, how attackers exploit it, and immediate steps to secure your applications.

Critical CVE-2025-66478 vulnerability allows remote code execution in Next.js applications worldwide.

Tag: Security

Tag: Security

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

When Your Antivirus Fights Your AI Agent: A Bitdefender GravityZone War Story

React2Shell: Critical RCE Flaw in Next.js & How to Fix It