Burrow FAQs and Answers

Common questions about the Burrow security and audit layer of Squirrel. Each section is a question with a short, practical answer. For deeper detail follow the cross-links.

Why didn't I get an email for an alert I can see in the dashboard?

Email is the loud channel; the dashboard is the complete one, so not every alert emails. An alert stays dashboard-only when any of these apply: it is below your minimum severity; its rule is filtered out by your Email which rules? selection (both on the Settings page); it was held at Low because it was a lone behavioural blip with nothing corroborating it (deliberately not page-worthy, still recorded); skip auto-downgraded is on and Burrow's pre-filter (or the AI, for ordinary behavioural alerts) had already classified it as not-real; or - for the high-stakes categories only - the AI marked it routine and you have set the "When the AI marks a high-stakes alert routine" policy to suppress at that confidence. The alert's detail panel states which reason applied.

Why does an alert say its severity was "reduced" or "lowered"?

Burrow lowers severity when context says the behaviour is expected - the external recipients are all on your External Partners list, the "new" country is one your organisation already works from, the search burst was retrieval of specific documents rather than browsing, or the activity was Microsoft's own platform machinery. The alert text always states the reason. Reduced is not hidden: the alert stays on the dashboard.

Is it normal for the first week or two to be noisy (or quiet)?

Yes. Burrow's behavioural rules compare each person against their own history, which takes roughly two weeks to mature. Early on you see more generic alerts and fewer personalised ones - the Baseline maturity setting suppresses the worst of the cold-start noise. Both volume and precision improve as history accumulates. The absolute rules - mass deletion, malware, DLP overrides - are at full strength from day one.

A colleague shows up in the External Sharing report - why?

Their email domain is not on your Internal Domains list, so Burrow treats them as an outsider. Add the domain and they - and every other colleague on it - reclassify as internal. This is the single most common setup gap.

We share with an auditor or partner constantly - how do I stop the alerts?

Add their domain to External Partners (bottom of the Internal Domains page). Sharing to them still appears on the External Sharing report - with a green partner badge - but sharing alerts where every recipient is a partner are automatically lowered. Do not add them to Internal Domains; they are not you.

A user got a new-country alert, but it's a real office or their home country.

If someone else in your tenant already works from that country, set Settings - New-country sign-in sensitivity to Tenant-aware and these arrive as Low instead of High. A country nobody in your organisation has ever used still alerts loudly - that is the case worth verifying with the user. See Known Networks.

Since 2026-08-05 Tenant-aware is not the default, so if you have not changed this setting you are getting the louder behaviour: a country new for that one user fires High even when it is an established office. Switching to Tenant-aware is the fix if that is more email than you want.

Does Burrow monitor OneDrive?

Not for behaviour, and that is on purpose. Baselines, volume rules, activity profiles and Hunt cover team and group SharePoint sites. Personal OneDrive sync traffic is high-volume and personal, and folding it in would swamp every per-user baseline without adding signal - a laptop re-syncing thousands of files looks the same as a person taking them.

Labelled files are the exception. A sensitivity label protects the file wherever it goes, so a Confidential-labelled document shared externally from someone's OneDrive still alerts, and its evidence is kept so you can investigate it. Staging a labelled file through a personal OneDrive is a well-known exfiltration route, and Burrow follows the label rather than the location.

Does Burrow ever change, block, or delete anything in our tenant?

No. Burrow is read-only by design: it watches audit data, alerts, and recommends. Every remediation - revoking a share, disabling an account - is carried out by your own admin in Microsoft 365, so your existing change-control process stays intact.

Where does our data go - is any of it sent to a public AI?

Your audit data lives in your own Azure storage, which you own and control - Burrow does not hold your data hostage. The AI that triages and narrates alerts runs privately within the Burrow service; alert content is not sent to any public or third-party AI service. Emails go only to the recipients you configure.

My test email never arrived.

Check junk / quarantine first - the very first send from a new address is often filtered. If it is not there, confirm the recipient list saved (Settings - Email notifications) and send another test. Still nothing? Raise a support ticket.

How do I jump from an alert email to the exact alert?

Click View in Burrow in the email - it deep-links to that specific alert on the dashboard, with the full evidence, the user's history, and the AI Q&A panel.

Who do I call when something looks like a real incident?

Follow your own incident-response process first - Burrow's job is early, evidenced warning. Your SmiKar contact can help interpret the evidence, but the containment actions (password reset, sign-out, revoke) are yours to take in Microsoft 365.

If I dismiss an alert, does the system stop alerting on it?

Yes, eventually. The Suggestions page proposes an exception once a named operator has dismissed the same (user, category) pair on three or more separate days; clicking Apply makes the alerts stop. If you opt in to the Dismissal auto-suppress feature (off by default), Burrow applies the pattern itself once the threshold is met without waiting for you to click Apply.

The first dismissal on its own does not silence anything. Use it as your vote - Burrow watches for the pattern across multiple dismissals before proposing (or applying) the silencing.

Clearing your queue is not a vote. Bulk sweeps - Dismiss ALL, Suppress matching, or a multi-select you marked as a sweep - are recorded but never count toward that pattern. And if you reopen an alert, its earlier dismissal stops counting too. Only dismissals you actually judged will quieten anything.

I bulk-dismissed a pile of alerts by mistake. Can I get them back?

Yes. Open History → Recent bulk actions and click Undo on that batch: every alert it dismissed reopens, apart from any that someone has since re-judged. Individual alerts can be reopened at any time from their History row or from the alert's status select. Reopening also cancels those dismissals' contribution to learned quieting, so nothing has been trained in the meantime.

Where did my AI-dismissed alerts go?

The Active tab now excludes alerts the AI judged as not real, to keep your work queue focused on what actually needs attention. They are still fully queryable - switch to the Dismissed tab to see them alongside the alerts you have manually dismissed.

The two kinds are visually distinct on the row:

• AI-dismissed - empty status select plus the AI · NO verdict badge.
• Operator-dismissed - "Dismissed" shown in the status select.

The operator override always wins. If you set Acknowledged / Investigating / Escalated on an AI-dismissed alert, it leaves the Dismissed tab and stays visible under the tab matching that disposition until you close it yourself.

If you'd rather see them mixed in to your Active queue for a spot-audit, the severity filter row has two audit chips: + AI-dismissed (silent) for AI dismissals you were never emailed about, and + AI-dismissed (emailed) for ones the AI marked "not real" after you already got the email. Each toggles its own bucket independently and resets on browser refresh. See Auditing the AI's dismissed alerts for the recommended cadence.

I added an exception but still got an email - why?

Entity exceptions take effect on the next detection pass after you save them, typically within a minute. If you saved the exception just before an alert fired, the alert may have been in the pipeline before the exception was loaded.

For alerts that arrived after the exception was saved and STILL emailed:

1. Check the user pattern. Wildcards are case-insensitive but partial matches need a * on either side if the substring is anywhere other than at the start or end. For example, the pattern app@sharepoint* matches app@sharepoint-abc but sharepoint* alone does not match app@sharepoint-abc because the substring is not at the start of the UPN.
2. Check the category. If your exception specified one specific category, only that category is suppressed. To silence all alerts from the user, set Category to *.
3. Check the action. If the action is Downgrade rather than Suppress, the alert is still emitted with reduced severity - and emails for the reduced severity may still pass your Minimum severity gate.
4. Check the System Activity page and filter to Suppressed. If the alert was suppressed by something other than the exception, the entry shows why. If it shows the exception fired but you still got the email, raise a support ticket.

Top MITRE shows "No data" - is that broken?

Probably not. Two common reasons:

• No MITRE-tagged alerts have fired in the current lookback window. The default window is 24 hours; widen it (e.g. to 7 days) to see longer-range data. The home page lookback selector is at the top of the tile.
• The lookback window is correct but your tenant has been genuinely quiet. No data on Top MITRE in a quiet week is a healthy signal - it means no adversary techniques are currently active.

If the Top MITRE tab shows "No data" but the Severity donut shows alert counts in the same window, the absence is unexpected - raise a support ticket.

Cold storage rehydrate is stuck in FETCHING - what now?

Most rehydrates complete within 30 seconds to 5 minutes depending on the entity's activity volume. A job stuck in FETCHING for longer than 30 minutes usually means one of:

• The cold-storage worker is busy with a larger job ahead of yours. Check the All jobs list on the Cold Storage panel for other in-progress rehydrates. The worker processes jobs one at a time.
• Network or storage transient issue. Wait 10 more minutes. If the state has not changed, click delete on the stuck row and resubmit the job.
• The entity has more historical data than expected. A single user with months of high activity can take 15+ minutes for a multi-month rehydrate. Patience for this case.

If a resubmitted job also gets stuck, raise a support ticket with the entity, the month range, and the job state.

How long does Burrow keep audit data?

Two retention horizons:

• On-disk (queryable instantly in Hunt): the last 14 days.
• Cold storage (in your Azure Blob, rehydratable on demand): essentially indefinite - bounded only by your Azure storage budget.

Audit data is auto-moved from on-disk to cold storage after 14 days. The on-disk copy is removed at that point. To search older data, rehydrate the relevant months from cold storage first.

The full picture - what is kept hot, what is archived, what is never deleted, and who owns it - is on Data retention and storage.

For practical purposes, Burrow keeps your audit history forever unless you choose to delete cold-storage data manually. The retention is governed by your storage account - Burrow does not enforce any deletion policy of its own.

Does Burrow log when I dismiss an alert?

Yes. Every disposition click (Real / Not real / Maybe) is recorded in two places:

1. The History page - append-only, shows your analyst identity, timestamp, the alert key, and the before / after disposition.
2. The suppression journal - records every per-alert email Burrow then suppressed as a result of dismissal-driven exceptions (whether applied via Suggestion or auto-suppress).

Together these answer "did SOC analyst X actually triage that alert and what did they decide?" with a defensible audit trail.

Can I get the weekly briefing without alert emails?

Yes. On the Settings page, in the Email notifications card, set:

• Minimum severity = Critical (so per-alert emails are heavily restricted to only the highest tier).
• Weekly briefing = on.

The recipient will get the Monday morning executive briefing every week plus any Critical-severity per-alert emails (which are rare). For zero per-alert emails entirely, the Min severity gate would need to be above Critical - which is not a setting - but in practice setting it to Critical filters out essentially everything routine.

The Weekly briefing toggle is independent of the per-alert gate, so this configuration works as expected for management / compliance leads who want the weekly summary but do not want the day-to-day noise.

---

Need help? support@smikar.com.