How an Alert Flows Through Burrow

5 min read

The journey of one piece of suspicious activity, from the moment a user clicks Download in SharePoint to the moment the SOC analyst opens the alert email. Understanding the chain helps you read each alert with the right context and know where to look when something doesn't behave as expected.

The chain at a glance

A user does something in Microsoft 365 — Microsoft writes an audit event.
Burrow collects the event on its next detection pass (roughly every 10 minutes), aggregates events for the window, and evaluates rules.
If a rule fires, an alert is created.
Burrow's AI triage step reads the alert plus the user's profile, then writes a Real / Not real / Maybe verdict and a plain-language note.
Burrow's email step checks, in order: severity floor → entity exception → AI verdict → cooldown → Investigation card. If all clear, the email is sent. If any layer blocks the email, the skip is journaled in the suppression log (visible in Settings).
The operator opens the dashboard or the inbox.

In parallel, three things keep running:

The incident correlation engine watches for clusters of related alerts on the same user within a short window and writes one Investigation with an AI-written attack-chain narrative.
The daily pattern detector scores each user's day. If the cumulative score crosses a threshold, a single "this user had a bad day" summary is emitted in place of multiple per-alert emails.
The behavioural profile builder rebuilds the user's typical-behaviour baseline so future deviation rules have current ground truth.

Worked example: Shane downloads 1.2 GB at 14:08

14:08 — the act. Shane clicks Download All on a 1.2 GB folder in SharePoint. Microsoft generates around 150 audit events (one per file).

14:08 to ~14:18 — Microsoft publishes. There's an inherent publishing lag of anywhere from 30 seconds to an hour before the events are available to Burrow.

~14:18 — Burrow's next detection pass. Burrow reads the new events, aggregates Shane's row in its per-user counters for the window, and evaluates around 40 rules. Shane's row now reads: 150 manual downloads, 1.2 GB total, 150 distinct files. The data_exfiltration_high rule fires because the byte volume crosses the threshold for the Balanced detection posture. One alert is written for Shane.

~14:19 — AI triage. The AI reads the new alert plus Shane's behavioural profile and returns "Real" with a short note describing why this is unusual versus Shane's baseline. Burrow's AI safety check verifies that every number and name in the note appears in the source data; if anything had been invented, the note would be rejected and a plain template used instead.

~14:20 — email decision. Burrow's email step checks, in order:

Severity floor (your Minimum severity setting). High passes a Medium floor.
Entity exception. No exception for Shane → pass.
AI verdict. Real → pass.
Cooldown. First alert for Shane in this category today → pass.
Investigation card. If Shane's alert is part of a cluster the incident correlation engine has grouped into an Investigation, Burrow sends one consolidated card and skips this per-alert email. Otherwise it sends the per-alert email now.

~14:20 — the email lands. Subject: [HIGH] data_exfiltration_high — shane.quinnell@example.com. Body contains the AI "why this matters" paragraph, the key metrics, and a sample of the underlying events.

Later that day. The behavioural profile builder eventually rebuilds Shane's profile to reflect today's activity. The tuning advisor watches whether the SOC analyst dismissed the alert; if Shane gets dismissed repeatedly for the same category over a few weeks, the Suggestions panel surfaces a recommended threshold change. The daily pattern detector scores Shane's day at end of day; if the cumulative score crosses the threshold, a daily escalation summary email is sent.

What changes when you mark a disposition

When the analyst opens the alert and clicks Dispositions → Not real:

The disposition is recorded against the (user, category) pair and visible to the next SOC shift.
The change is logged on the History page with timestamp, analyst identity, and before / after state.
Future alerts on the same (user, category) pair for the same lookback window are suppressed from email, and each suppression is logged in the suppression journal (visible in Settings).
The tuning advisor sees the dismissal. If the pattern repeats, it surfaces a tuning suggestion at the top of the Rules page.

When something doesn't behave as expected

Symptom	Where to look
An alert you expected didn't email	The suppression journal in Settings — every skip is logged with a reason.
The alert fired but the narrative looks wrong	The AI safety check log in Settings — the AI's prose was rejected and you're seeing the plain template fallback. The deterministic numbers are still correct.
An alert should have fired but didn't	Check the cooldown for that (user, category) pair, the posture and per-rule overrides on the Rules page, and the Disabled rules list.
The same alert fires every detection pass	Either the cooldown is misconfigured, or the entity genuinely keeps doing the activity.
The AI verdict is missing on an alert	The AI triage step may be queued behind a backlog. Give it a few minutes; raise a support ticket if it persists.