Noise Gates: Why an Alert Was Lowered or Silenced

If you are looking at an alert marked Low and wondering why it did not page anyone - or you expected an alert and never got one - this page is the answer.

Much of what Microsoft 365 records as "user activity" was not done by the user. SharePoint renders a page, an Office web viewer fetches a document, a service account provisions a site: all of it lands in the audit log under somebody's name, and much of it has the same shape as an attack. A folder downloaded as a ZIP looks exactly like 150 manual downloads. Somebody creating a Team looks exactly like somebody granting themselves site admin.

Burrow recognises these patterns as noise gates - fixed rules that say "this shape is the platform, not a person". They are deterministic. No AI decides what is or is not machinery; each gate describes one specific pattern and applies the same way every time.

What happens when a gate matches

This page uses three words for three different outcomes, and the difference matters:

	What it means for you
Excluded	The activity is never counted toward the rule. It cannot push a threshold over the line, so no alert comes from it.
Demoted	The alert is still raised and still recorded, but at Low. It stays visible in the dashboard. It does not email you.
Suppressed	The alert is not raised at all, and the decision is written to the record so you can see it was made.

Nothing is deleted. A demoted alert keeps its full evidence and still counts toward the daily escalation score. It is removed from your inbox, not from the record.

Every gate explains itself. The reason is written into the alert's Trigger Why text, so you can always see which gate applied and why - see reading the evidence box for where to find it.

The platform moved the bytes, nobody downloaded anything

The largest source of false exfiltration alerts. In each of these, content moved inside Microsoft's own infrastructure and never reached anyone's device.

Thumbnail and preview generation

• What you would see: a bulk download - potentially gigabytes, across many files, in seconds.
• What actually happened: SharePoint generated preview thumbnails, or an Office web renderer fetched document content in order to display it. The actors behind it are Microsoft service processes rather than accounts; in your audit log they appear under names like ODMTADemand-Transform_* and the Office*CA family.
• What Burrow does: excluded from download counts entirely. They never contribute to data-exfiltration metrics.

Opening a document in Office Online

• What you would see: "Downloaded 523 MB 5x" - one file counted as several downloads in a short window.
• What actually happened: someone opened a document in Word, Excel or PowerPoint Online. The web viewer fetches the file's bytes several times as pages render. None of those bytes left the tenant.
• What Burrow does: excluded from manual-download counting. The investigation digest labels them "NOT a download to a device", so it is obvious when you read the alert.

Reading a large PDF in the browser

• What you would see: "63 downloads of one file" - the same document apparently pulled over and over.
• What actually happened: somebody read a long PDF in the browser. The viewer fetches it in chunks, and each chunk is logged as its own event.
• What Burrow does: demoted when the fetches-per-file ratio is 10x or higher across three or fewer files. Real exfiltration looks like the opposite - many different files, each fetched about once.

The SharePoint start page loading site cards

• What you would see: "Accessed 15 new sites in one minute".
• What actually happened: the SharePoint start page drew its site cards. Each card fetches that site's icon, and each fetch lands in the audit log as a site-access event.
• What Burrow does: icon fetches are excluded from site-access tracking, so the count reflects sites the person actually navigated into.

Co-authoring reported as an unmanaged device

• What you would see: "unmanaged device access" on labelled files.
• What actually happened: Excel or Word Online rendering and co-authoring. These report as an unmanaged device because there is no device in the request path at all - the work happens in Microsoft's browser render farm.
• What Burrow does: excluded from unmanaged-device rules. Genuine traffic from a real unenrolled device is unaffected.

One click, many audit events

Microsoft 365 often records a single human action as a burst of events. Counting the events instead of the action is what makes these look severe.

Downloading a folder as a ZIP

• What you would see: "150 manual downloads", firing deviation, velocity and sensitive-extension alerts all at once.
• What actually happened: one click on Download against a folder. SharePoint fetches every file in it individually to build the zip - one audit event per file, for one action.
• What Burrow does: the pattern is recognised (from five files upward) and reported as what it was: "downloaded an entire folder as a ZIP: one click packaged N files". The download itself stays visible at full severity, because copying a whole folder is a real exfiltration route worth checking against the person's role. The alerts that piled on around it - deviation, velocity, sensitive-extension - are demoted.

Sharing something once

• What you would see: "6 org-wide links created" after a single share.
• What actually happened: clicking Share creates the link, then logs bookkeeping and initial-open events alongside it - four to six events for one visible action.
• What Burrow does: the rule counts distinct files newly shared org-wide rather than raw events. See risky_sharing in the rule catalog.

Creating a Team or a Plan

• What you would see: three alerts at once on an ordinary user - a permission escalation, a critical site-collection-admin grant, and a critical tenant policy change. Three emails from one action.
• What actually happened: somebody created a Team or a Plan. Microsoft's provisioning pipeline stamps the new site with an admin grant and a sharing-policy change automatically - and records those automatic operations under the creating user's name, which is why the service-account gate further down does not catch it.
• What Burrow does: the alerts are correlated by site. Where every admin, policy and permission operation in the window is on a site created in that same window, and the admin grant goes to that site's own Owners group, Burrow recognises the provisioning burst: the permission-escalation and tenant-policy alerts are suppressed, and one Low record is kept for the cluster. A real admin grant to a specific person, or any grant on a site that already existed, is untouched and stays critical.

This is the one gate that keys on a real person's activity rather than a service account. What identifies it is the correlation - every operation landing on a just-created site, with the grant going to that site's own Owners group - not who did it.

Ordinary work that matches an attack shape

Nothing to do with the platform. These are real human actions that happen to look like something else.

Reorganising files

• What you would see: "Deleted 63 files".
• What actually happened: a folder reorganisation, or SharePoint's Move operation, which registers as a delete plus an upload for every file involved.
• What Burrow does: demoted where the deletes are closely matched by uploads or moves in the same site. The ransomware rule still evaluates the same raw activity independently, so this gate cannot blind ransomware detection.

Downloading one big file

• What you would see: a "40x baseline" byte spike on the exfiltration or behavioural-deviation rules.
• What actually happened: somebody downloaded a single large file - a CAD model, a training video, a meeting recording - accounting for 80% or more of the day's bytes. One big file is not the shape of exfiltration.
• What Burrow does: demoted, with the file named in the alert. A genuine bulk pull, where the volume is spread across many files, is unaffected.

Reading documents out of hours

• What you would see: "Unusual-hour activity".
• What actually happened: an early or late sign-in that only read things - nothing downloaded, edited, deleted or shared.
• What Burrow does: demoted. An out-of-hours session that touches data still fires at full severity.

Sign-in failures with an ordinary explanation

Colleagues sharing an office connection

• What you would see: "5 users failing sign-in from one IP" - the shape of a password spray.
• What actually happened: people in the same office share one outbound IP address. Several of them mistyped a password, or are working with an expired one.
• What Burrow does: demoted when the same users who failed also sign in successfully from that address, or when the address belongs to a network already learned as office or VPN egress on Known Networks. An address that is neither still fires at full severity, so an outside attacker is not covered by this.

A device retrying with an expired token

• What you would see: "7 failed sign-ins in one second" - the shape of enumeration or a spray.
• What actually happened: a device whose sign-in token expired, retrying automatically. Microsoft reports it with a distinct expired-token error code.
• What Burrow does: excluded from enumeration and spray counters entirely.

Automation doing its job

Service accounts legitimately do things that would be alarming if a person did them.

Microsoft's own provisioning accounts

• What you would see: "CRITICAL: site collection admin granted".
• What actually happened: automatic Teams or site provisioning. Microsoft's service accounts grant themselves the role they need during setup. No human is behind it, and neither account can be impersonated from outside your tenant.
• What Burrow does: demoted when those specific accounts grant site admin or set site policy. Any other identity doing the same thing still fires at full severity.

Your own service accounts, behaving normally

• What you would see: "CRITICAL: ransomware signature" or "mass deletion" against your document-pipeline automation.
• What actually happened: the automation doing its usual bulk download, delete and replace work - which genuinely does match the shape of ransomware and mass deletion.
• What Burrow does: demoted, with an explanation, when the account is operating within its own established baseline. Burrow identifies service accounts by the shape of the identity rather than from a list of names, so a new one needs no configuration. An account operating far outside its own norm still fires at full severity, and these accounts are kept out of the human risk ranking in the weekly briefing entirely.

Why this matters

Without these gates, the Burrow inbox would be dominated by rendering, provisioning and viewer traffic. All of it is real in the audit log; none of it is a person doing anything. Each gate is a translation of one specific way the platform manufactures activity, so that what reaches you reflects human intent.

When a gate gets it wrong

If a gate lowered an alert that should have paged you:

1. Open the alert on the Alerts page - demoted alerts are still there, at Low.
2. Read the Trigger Why text to see which gate applied.
3. Raise a support ticket with the alert key, the gate named in Trigger Why, and one line on why the pattern is not what the gate assumed.

If a whole rule is noisy in your tenant rather than one pattern within it, that is a different fix - see postures, overrides, and disabled rules.

See also

• Rule catalog - the rules these gates modify.
• Investigation digest - where "the platform did it" gets labelled in plain English.
• Reading the evidence box - where the Trigger Why text lives in the drawer.
• Postures, overrides, and disabled rules - for whole-rule tuning.

---

Need help? support@smikar.com.