Anomalies

The Anomalies screen answers the question every security team quietly worries about: "Out of everything that happened today, what is actually unusual - and would I have noticed?" Every active policy in your tenant continuously learns its own normal, and when today's activity spikes above it, an anomaly opens - no thresholds to configure, no rules to anticipate.

What You Can Achieve

Today, Measured Against Your Last 30 Days

The comparison is deliberately simple to state:

Today's count, versus the median of the previous 30 days.

• Today is the current day's number, and it is live - recomputed as activity arrives (within minutes of a new audit event), not once a night. An anomaly that starts this morning is on this screen this morning, and its numbers keep updating while the spike continues.
• The baseline is the median of the trailing 30 daily values, today excluded - so the spike can never quietly raise the bar it is being judged against. The median, not the average: one freak day in the past never poisons what "normal" means.
• The spread is measured the same robust way (median absolute deviation), so "how far above normal" is expressed in your own day-to-day variability, not in a number someone picked.
• A daily floor pass re-checks every tenant once a day, so a quiet day is still recorded as a day - a baseline with holes in it is a baseline you can't trust.

Detection is one-sided on purpose: only spikes are flagged. Activity drops constantly for benign reasons - quiet days, cleanups, resolved findings - and a queue full of dips would bury the spike that matters.

A Baseline Per Policy, Per User, Per App, Per Agent

The same machinery runs at two levels. Policy-wide anomalies watch a detector's total result count - "this policy matched 12 things a day for a month, today it matched 2,000". Per-entity anomalies watch one principal against its own history - a specific user, a specific third-party application, or a specific AI agent.

That last one matters more every quarter. An agent's blast radius is its permissions, not its prompt, and "the finance agent read four times its usual number of files today" is exactly the signal nobody else is positioned to give you - it needs the agent inventory, the permission graph and the activity baseline in the same product.

The Anomaly Score and Your Alert Line

Every anomaly carries a single score - roughly, how many deviations today's count sits above that policy's or entity's own day-to-day variability. Flat histories get a statistically equivalent value (a Poisson tail test for rare events, a percentage jump for high-volume ones), so every episode lands on one comparable scale.

That one scale is what makes the alert line possible:

• At or above the line (default 3.5) - the anomaly is Alerted: it enters the queue and notifies the policy's recipients.
• Between 2.0 and the line - the anomaly is kept as Info: stored silently, never notified, one toggle away.
• Below 2.0 - ordinary variation; nothing is stored.

One Dial, Every Industry - and No Tuning Period

The Alert sensitivity control sits in the open at the top of this screen, not buried in a settings page, because it is the setting most tools never let you touch. Move it and classification re-runs at read time, against your real history: let go of the slider and the Alerted and Info counts beside it re-answer on the spot, with the queues re-populated to match.

That has a consequence worth naming plainly. Tuning detection normally costs a quarter: you pick a threshold, you run it in shadow mode, you wait to see what it catches and what it drowns you in, and you adjust. Here the waiting disappears, because the history is already scored - lowering the line doesn't start collecting differently, it re-classifies what was already caught.

• A bank, hospital or law firm drags the line down toward 2.0. Everything the detector ever considered noteworthy becomes Alerted, retroactively, and the audit question - "would we have seen it?" - is answered by looking, not by hoping.
• A marketing agency or a 30-person startup pushes it toward the relaxed end. The queue shrinks to the handful of episodes worth a human's attention, and nothing is deleted: everything below the line is still sitting in Info the day it becomes relevant.
• Both are the same tenant, the same data and the same detector. The regulated organization and the relaxed one are not running different products - they are running the same one with a dial in a different place.

Episodes, Not Events

An anomaly is an episode: it opens when the count breaks the line, tracks its peak while the spike is ongoing, and records when the metric returned to normal. Ending is a fact about the metric, not a verdict about the incident - an episode whose spike ended still sits in the Open queue until you acknowledge or dismiss it. One notification per episode, not per day.

Each row leads with the detector that fired, with the affected entity - the specific user, application or AI agent for per-entity anomalies, the resource type for policy-wide ones - underneath it. The rest of the row carries severity, a 30-day sparkline of the metric, the spike itself (baseline → current and the percentage jump), the score, and when it was last detected and when it ended. Click through to the trend behind the detector, or to the entity's own detail drawer.

Filtering In Depth

The always-visible controls cut the queue by tier (Alerted / Info) and triage state (Open / Acknowledged / Dismissed); the filter drawer narrows further by severity, status, resource type - files, sites, groups, users, email, applications and AI agents - and detection date range. Every option carries a live count badge for the tier you are currently viewing, so you see how much sits behind a cut before you make it.