Microsoft 365 anomaly detection
One account downloaded 340 files today. Its normal is 12. We flag it in minutes.
In a tenant of a few thousand people, something unusual happens every day - a user, an app or an AI agent doing 10x, 30x, 100x what it did last month. 1Security learns a baseline for every account, application, agent and policy from its own last 30 days, scores today against it as events arrive, and keeps every deviation, so the queue holds what is unusual for your tenant - not what somebody else's threshold happened to catch.
- 30 daysof each account's own history behind every verdict - today measured against the median of the previous thirty days
- 10 minfrom a new audit event to an updated score - an anomaly that starts this morning is on the screen this morning
- 0thresholds to configure - one alert sensitivity dial, moved in the open, re-scores your real history the moment you release it
The problem
A rule catches what you predicted. Most incidents were not predicted.
Fixed thresholds fit one team and misfire for every other; baselines learned per account fit each of them.
Every mass download, misfired automation and over-broad permission change looks the same from a distance: a number that used to be small and suddenly is not. A finance clerk downloading 40 files is routine when their baseline is 38 and an incident when it is 3. A rule with one threshold for the whole tenant cannot tell those two apart, so it either fires all day or misses the one that mattered.
The typical outcome is a queue nobody reads or a queue that stays quiet with no way to know what it decided not to say. Tuning helps only going forward - a new threshold is a bet on the next quarter, run in shadow mode until someone finds the time. In practice that means the threshold is set once and never touched again.
1Security splits the decision in two. What is unusual is measured for every account, app, agent and policy against its own history and always recorded, down to two sigma, whether or not it clears your bar. What deserves an alert is a line you move, in the open, at the top of the screen - and moving it re-scores history you already have, so you see the effect immediately.
What you get
A baseline for every account, app, agent and policy
Anomalous means anomalous for this one, in this tenant. Five hundred file shares is an ordinary Tuesday for one team and a five-alarm incident for another.
Today vs the last 30 days
Today's count against the median of the previous thirty daily values, today excluded, so a spike can never raise the bar it is judged against.
Robust statistics, not averages
Median and median absolute deviation: one freak day in the past never poisons what "normal" means, and the spread is your own variability, not a number someone picked.
Scored as events arrive
Today's number is recomputed within minutes of a new audit event, not once a night. The 340 downloads show up as an anomaly while they are still happening.
Per-entity baselines
One specific user, one third-party application, one AI agent, one policy - each measured against its own history rather than against the population.
Everything below the line is kept
Between two sigma and your alert line, deviations are stored as Info. When something slips past alerting, the evidence already exists - filter to last week and read it.
Episodes, not rows
An anomaly opens, tracks its peak, and records when the metric normalised. A three-day spike is one episode with one notification, and it stays in the open queue until a human acknowledges or dismisses it.
How deep it goes
One dial, two very different organizations
Move the alert sensitivity control and classification re-runs at read time, against your real history. Release the slider and the alerted and info counts beside it re-answer on the spot.
A bank, a hospital or a law firm drags the line down toward two sigma. Everything the detector ever considered noteworthy becomes alerted, retroactively, and the audit question - would we have seen it - is answered by looking rather than by hoping.
A marketing agency or a thirty-person startup pushes the line toward the relaxed end. The queue shrinks to the handful of episodes worth a human's attention, and nothing is lost: everything under the line still sits in Info the day it becomes relevant.
Both are the same tenant, the same data and the same detector, with the dial in a different place. It also enables the investigative move that matters most after an incident: "we think we missed something last week" - lower the line, filter to that week, and read what was already recorded below your old bar. In a typical tenant that first look surfaces a handful of episodes worth a second glance.
In practice
A spike, from first event to closed episode
What an admin actually does in Anomalies when a number goes wrong.
- 01
Open the queue, filtered to Alerted
Anomalies opens on the open episodes above your alert line, newest first: "Downloads by user - 340 today, baseline 12, peak 09:40". Severity, a thirty-day sparkline and the baseline-to-current jump sit on every row.
- 02
Read the account, not just the number
One click opens the user, app or agent behind the episode: what it can reach, the device and location of today's activity, and the full trend behind the detector. "4x its usual number of files" arrives with the files listed.
- 03
Decide, and the queue remembers
Acknowledge or dismiss the episode; escalate with the events attached, or stage a fix - expire links, remove access, disable - behind the review window. A spike that ended overnight still waits until someone has looked.
- 04
Move the dial when your appetite changes
New regulator, new auditor, new quarter: drag the sensitivity control and the counts re-answer immediately against history that was already scored. No shadow mode, no waiting to see what a new setting would have caught.
What sets it apart
Why AI agents make this the right design
An agent's blast radius is its permissions, not its prompt. Watching that needs three things in one place.
- The AI agent inventory, so the entity being baselined is a real, governed object
- The permission graph, so what an agent or account can reach is resolved rather than guessed
- The activity baseline, so "four times its usual number of files" is a statement with a number behind it
- Per-entity anomalies for users, third-party apps and AI agents alike, on one comparable scale
- A statistically equivalent score for flat histories and rare events, so one dial governs all of them
- Severity, a thirty-day sparkline and the baseline-to-current jump on every row
- Filters by tier, triage state, severity, resource type and detection date, each with live counts
- The full trend behind a detector, and the account's activity log, one click from the anomaly
Method
One scale, every kind of history
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 the same scale and one dial can govern all of them. Detection is one-sided on purpose: only spikes are flagged, because activity drops constantly for benign reasons and a queue full of dips would bury the spike that matters.
- 2.0 sigmathe floor below which nothing is stored - everything above it is kept as Info or Alerted
- 3.5the out-of-the-box alert line, and it is yours to move at any time
- 14 daysof history before detection says anything - a median and a spread need that much to mean something
Related
Where this fits
Anomalies measure deviation from a baseline. Activities rank absolute extremes - the top downloader this hour, the sites untouched for a year. Alerts carry the result to a human. The three are one system, not three products.
Activity analytics
The absolute rankings: who downloaded 4,000 files this week, which sites nobody has opened in a year - with 1, 12 and 24-hour windows.
See activities →Alerts
One alert model across policies, activities and anomalies: an email at 14:07 for the spike that started at 14:02, with account and device attached.
See alerts →AI agent inventory
The governed population that per-agent baselines are computed for - every agent with what it can read.
See agents →
FAQ
Questions teams ask first
Do I have to configure thresholds per policy or per user?
No. Each policy and each entity learns its own baseline from its last thirty days, so there is nothing to anticipate. The only global control is the alert sensitivity line, and its default of 3.5 is usable from day one.
What happens when I move the sensitivity dial?
Classification re-runs at read time against history that was already scored. The alerted and info counts re-answer as soon as you release the slider, and the queues repopulate to match. Nothing is deleted in either direction.
How long before it starts detecting?
Fourteen days for anything it watches - the point at which a median and a spread mean something. Before that 1Security collects quietly rather than inventing alerts from a week of data. Everything else on the platform is live from the first scan.
Why are drops not flagged?
Because activity falls constantly for benign reasons - quiet days, cleanups, resolved findings - and a queue full of dips buries the spike that matters. Detection is one-sided by design; dormancy is answered properly on the Activities screen and by the lifecycle filters instead.
Can an anomaly be about one AI agent?
Yes. Per-entity baselines cover users, third-party applications and AI agents. "The finance agent read four times its usual number of files today" is exactly the signal the agent inventory, the permission graph and the activity baseline make possible together.
See what was unusual in your tenant this week.
Connect read-only and baselines start building the same day. Two weeks later the queue is real, the sensitivity dial is the first thing on the screen, and the 340-download morning is an episode with an owner - not a line in an export.
Or keep guessing which spike was the one that mattered.