AnomaliesCopy Anchor Link

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 AchieveCopy Anchor Link

Today, Measured Against Your Last 30 DaysCopy Anchor Link

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 AgentCopy Anchor Link

The categories themselves are cut along how people actually behave, not along API names: mail deletion is measured apart from file destruction, because everyone empties a mailbox and almost nobody purges files past the recycle bin - one baseline for both would let inbox hygiene wear the severity of file destruction and drown the signal that matters. The same split shows up in the severities: abnormal mail deletion stamps low, unrecoverable file and site destruction medium, and the two corroborate each other when they move together.

One of those categories is deliberately baselined rather than alerted on every occurrence: an administrator removing someone else's MFA method. Stripping a second factor is what turns a password an attacker already holds into a working sign-in - and it is also what a helpdesk does every week for someone who changed phone. The same click either way, so it is counted per administrator against that administrator's own history, and a method someone removes from their own account is not counted at all.

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 did four times its usual volume of activity 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 newest per-entity baselines watch not just how much an identity does, but what its activity touches. Every file and email read is classified at ingestion for whether the content carried sensitive or restricted data at that moment - a read-time stamp that survives later deletions and rescans, so the record of what was actually reached stays trustworthy. On top of it:

• Abnormal sensitive-data access per user flags a person opening far more sensitive files and emails than their own norm - the staging pattern that precedes exfiltration and leaves no download trail when the data is read in place.
• Abnormal sensitive-data access through AI per user does the same for the content a user's AI assistant reads to build its answers; its twin on the agent side watches each AI agent's own reads.
• Sensitive-data share shift - on an AI agent, and in a user's AI usage - watches the percentage of AI interactions touching sensitive content against the entity's own history, and catches the day the AI's reading shifts toward sensitive material even when total volume looks perfectly normal. Worth knowing when you read these episodes: their numbers are percentage points, not event counts.

The sensitive-access detectors also know where the sensitive info came from. A read whose only sensitive carriers were received emails - sender outside your tenant - counts into its own received-mail detectors (for humans and for AI alike) at lower severity and a higher bar, instead of inflating the own-content ones: reading sensitive data that arrived from outside is a weaker claim than reaching your organization's own, and assistants and agents analyse incoming mail for summaries and reply drafts all day. One own-content carrier in the mix keeps the read in the stricter detector.

Incidents - When One Occurrence Is EnoughCopy Anchor Link

Not everything should wait for a baseline. Some events carry their verdict with them - the platform flagged the interaction, or your own admins had already declared the data off-limits - and scoring those statistically would only delay the alarm. These detections are incidents, a first-class kind of their own next to anomalies: they fire on any occurrence, need no history, always alert, and the sensitivity slider never applies to them - a verdict is not something a statistical dial should be able to silence. The queue's Incidents / Anomalies toggle splits the two, and an incident row shows what fired and how often instead of a score.

The incident detectors:

• Prompt injection attempts - per user and on each AI agent: an AI interaction flagged as a manipulation attempt, whether a jailbreak prompt someone typed or instructions hidden in content the assistant read. There is no innocent baseline for prompt injection.

• Inbox rule followed by deletion burst - a new inbox rule and, within 48 hours, an unusual burst of deleted mail or files: the classic mailbox-takeover sequence. Each signal alone is everyday noise; together they are a high-precision alarm.

• Restricted data reached through AI - per user and per AI agent: an AI assistant or agent builds an answer on content carrying a data type your admins explicitly restricted. The restriction already says this data must not reach AI, so every occurrence is a live gap between declared policy and what the AI can actually read.

• Restricted data accessed per user - a person opens a file or email carrying a data type declared fully off-limits (no access for anyone). The verdict comes from what the content carried at the moment it was read, so it stands even if the file is deleted or rescanned afterwards.

• Capability escalation on AI agent - the agent's first permission that can change content, or its first organization-wide grant: a read-only assistant becoming a writer, or a scoped one gaining tenant-wide reach. Each line is crossed once per agent, so every crossing is worth a look.

• Grounding escalation on AI agent - a site carrying restricted data joins the agent's knowledge sources, or its grounding widens to the whole organization. Caught between scans, before any interaction reads the data.

• High-risk sign-in flagged by Microsoft - Identity Protection rates a successful sign-in as high-risk while it happens: leaked credentials, an anonymous or malicious IP, impossible travel. The attacker is already in, so every flagged sign-in alerts - and any unusual downloads, sharing or deletions by the same account that day are the follow-through to check.

• Prompt injection payload planted in file - the content scan found an injection payload inside a document: instruction-override phrasing, text hidden from human readers but visible to AI models, or an exfiltration template waiting to be filled in. This is the staged half of the injection attack - the payload sits armed until Copilot or an agent reads the file - caught by the scan itself, before any AI interaction happens.

• Prompt injection payload in email - the same payload types found in a message: mail is the cheapest way to plant instructions where an AI assistant will read them, so every finding alerts before any assistant touches it.

• Poisoned content read through AI - per user and per AI agent: Copilot or an agent took a file or email that 1Security had already flagged as a payload carrier into an answer. The two halves are both verdicts - our classifier on the content, the read in the audit log - so it fires with no Microsoft flag at all, and it is the moment a staged payload becomes an attack in progress. The episode names the carriers it joined, and each carrier's own payload incident reads a step higher while such a read is open.

• Active access from an unlisted location - real work (a file read, a mailbox opened, a Copilot prompt, a completed sign-in) from a country, city or network your location allow list does not name, or your block list does. The first incident driven by an explicit list rather than a baseline: failed sign-ins, Microsoft relays and machine identities never count, and allowing the place on the Locations screen's Review tab resolves the incident on its own.

• Password spray against account - failed sign-ins from many IP addresses the account never signs in from, in one day. One guess per address and hundreds of addresses is the shape built to stay under per-address lockouts, and a volume baseline cannot see it: the longer the campaign runs, the more normal it looks. Failed guesses on their own are recorded as info and never alert: every internet-facing account collects them, and Microsoft already turned them away - the episode stays in the queue as the record that the account is under fire. It becomes a critical incident the moment a guess had the right password and was stopped only by MFA or Conditional Access: the password is known, so reset it. Accounts Microsoft already blocks from signing in raise nothing at all - no guess against them can succeed.

• Inbox rule forwards or deletes mail - a rule whose action sends incoming mail out of the organization or deletes it on arrival. Ordinary rules file messages into folders; these two are how someone who has taken over a mailbox reads it from outside and keeps the owner from noticing. Outlook desktop and Outlook on the web report rule creation differently, and both are read, so a rule created in either place counts.

• Mail-flow rule redirects or hides mail - an organization-wide transport rule that redirects or copies messages somewhere they were not addressed, or switches off its own audit records. It acts before delivery and needs access to no mailbox at all, which makes it the most powerful way to intercept mail in Microsoft 365; a rule that silences its own logging is hiding something whatever else it does.

• Phishing reached the mailbox - Microsoft Defender judged a message to be phishing or malware and it arrived anyway: either auto-forwarded straight back out of the organization, or let through because one of your own safe-sender or safe-domain entries outranked the verdict. Who set that entry decides the severity: a tenant-level allow entry is an admin's deliberate decision about a known sender and opens at medium; a user's own safe-sender entry, or an auto-forward, stays high. A known sender that Defender keeps flagging - a scheduled report relayed from outside your SPF, say - can be excluded with an exception on the detector (by sender, sender domain, subject or override type); everything else keeps being counted. The classification is Microsoft's own, so there is nothing to baseline - what matters is that the protection was bypassed.

• Sender added to a mailbox trusted list - an address or a whole domain added to a mailbox's trusted senders. Everything on that list skips spam and phishing filtering for that mailbox, so adding the sender you are about to phish from is the cheapest way past Microsoft - and it is usually the override behind a delivered phish. Exchange writes the whole list on every edit, so it is compared with that mailbox's previous edit and only genuine additions count.

• Conditional Access weakened - a change to the sign-in perimeter that removed protection instead of adding it: a policy switched off or deleted while still enabled, a user, group, role or application added to its exclusions, an MFA or compliant-device requirement dropped, legacy authentication allowed back in, or a network range marked trusted so it skips the policies that exempt trusted locations. The policy before and after are compared, so ordinary tightening and renaming never raise anything.

• App secret or certificate added - a new client secret or certificate attached to an app registration. That credential signs in as the application, so it keeps every permission the app holds and survives a password reset, an MFA re-enrolment and a device wipe - the usual way a single stolen session becomes permanent access. Microsoft reports adding and removing a key under one operation, so only edits that grew the key list count.

• Site opened to external sharing - a site collection whose sharing was widened: anonymous links switched on, guest sharing switched on, the restriction to already-invited guests lifted, or guests allowed to reshare. Microsoft also writes these settings every time it provisions a site, which is the bulk of the raw traffic; those are excluded, so what you see is a person changing an existing site.

• Data moved before the account closed - an account disabled or deleted after a fortnight of downloading or deleting far more than it normally did. It is the leaving-with-the-files shape, and it can only be seen backwards: while the person was still an employee the activity looked ordinary, and the offboarding is what says which fortnight to look at. The comparison is against that same account's earlier behaviour, so someone whose job is moving files does not qualify simply by leaving.

The two prompt-injection payload detectors are scan-driven: they come from 1Security's own content analysis rather than the activity stream, so they cover the attack before it fires - a poisoned document is an incident the moment it lands, not the moment an AI trips over it. The poisoned-read pair closes the loop from the other side: it joins the audit log's AI reads to those open payload incidents, so the moment any assistant or agent grounds on a flagged file or email, the reader gets its own incident and the carrier is lifted. A carrier Microsoft itself flagged as a cross-prompt-injection source opens the same payload incident from that verdict, whether or not the scan can see the payload.

Every detector's own episodes - the files, emails, users, agents or places it currently flags - are listed on the Findings tab of its drawer, and the Prompt injection chips above the queue show the whole family across entity types in one view.

The Anomaly Score and Your Alert LineCopy Anchor Link

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, if the tenant anomaly rule or an override says so, notifies its 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.

The line governs anomalies only. Incidents carry a verdict, not a measurement, so they alert wherever the line sits - relaxing the slider can quiet noisy volume detectors, but it can never reclassify a flagged prompt injection or a high-risk sign-in into the silent tier. To silence an incident detector deliberately, mute it with an alerting override.

Underneath the score sits a second, quieter calibration: each metric's minimum count - the bar below which a day cannot alert however flat the history - is re-solved per tenant from that tenant's own activity distribution, on an alert budget: roughly how many actor-days per month may clear the bar. A 40-person firm and a 40,000-person enterprise get the same sensitivity without anyone re-measuring thresholds as the customer grows, and a floor can only tighten within safe bounds - a runaway (or deliberately poisoned) baseline cannot calibrate the detector blind.

Tracked by Default - Logged Without the WorkloadCopy Anchor Link

Statistical anomalies create no work until you ask them to. Every anomaly episode opens in the Tracked state: recorded with its full history, visible under the Tracked chip, capped at severity Informational, and never notified - the withheld notification is still written to the notification log with tracked as its reason, so the record is complete. Your team can browse everything 1Security sees without owing a verdict on any of it.

Escalation is a deliberate act, at whichever granularity fits:

• Per detector. The queue's Defaults view has a Tracked / Managed switch on every detector. Setting a detector to Managed opens its episodes for triage - new ones arrive as Open, its currently tracked episodes move to Open with their computed severity and tier restored, and notifications apply. Switching back returns the open, untriaged ones to silent logging.
• Per episode. Any single row can be pulled into the queue by setting its status to Open - it escalates and notifies normally from then on, while its detector stays tracked. The same pill sends an episode back to Tracked.

Incidents are exempt. A verdict - a flagged prompt injection, a high-risk sign-in, the mailbox-takeover sequence - always opens in the queue and always alerts; "logged quietly by default" is a policy for deviations, not for confirmed events. Tracked episodes also keep counting as correlation signals: a tracked download spike still corroborates the same user's open risky sign-in, so the quiet tier sharpens the loud one instead of hiding from it.

Severity That Is Earned, Not StampedCopy Anchor Link

Most products type a severity next to each rule and every hit inherits it forever - which is how "critical" becomes wallpaper. Here the detector's typed severity is deliberately modest - with one deliberate exception, prompt injection, no built-in detector stamps critical - and it is only the starting point. What you see on an episode is its effective severity, computed live:

• A statistically extreme score escalates it. One step when the score crosses 6.0, two when it crosses 7.5 - the top of a scale most episodes never reach. A medium detector whose episode scores 7.6 reads critical, because that number is the evidence, not the label someone typed.
• Correlation escalates it. One step when another detector holds a strong open episode on the same entity, two steps when two or more do. A busy day and an account takeover look alike on one metric and nothing alike on three - so the download spike that coincides with a high-risk sign-in reads critical while the same spike alone reads medium.
• Event-driven detectors read exactly what they claim. Their episodes carry a marker score, not a measurement, so they never score-escalate: a high-risk sign-in is high on its own, and becomes critical the moment a second detector corroborates it. Prompt injection is the deliberate exception - a flagged manipulation of an AI session has no benign reading, so it is critical alone, no second signal required.
• Your overrides and verdicts win. A per-detector default severity (set from the queue's Defaults view), an alerting override scoped to one entity or cohort, or a manual per-episode verdict - the analyst's terminal call - each replace the computed value, and the row says which path produced what you see.

The result is a queue where critical means something: statistically extraordinary, corroborated by independent detectors, or confirmed by a human - never "a detector someone once labelled critical fired again". The same effective severity is what the REST API and MCP tools return in their severity field, with the raw stamp alongside as baseSeverity and the provenance as severitySource, so a SIEM keying on severity sees exactly what your analysts see.

Correlation - the Queue Reads Like a WatchlistCopy Anchor Link

Every episode carries two correlation numbers: how many other detectors currently hold an open episode on the same entity, and the entity's accumulated risk - the sum of its open episodes' scores. The default queue order puts correlated entities first: an account three detectors flag at once outranks any single higher score, because that is the row an analyst should open first. The same numbers ride the API (details.concurrentEpisodes, details.riskSum) so external tooling can rank the same way.

Correlation also gates the noisiest mail. Single-metric volume detectors - downloads, sharing, sign-in counts, AI usage - only notify while a second detector corroborates the entity; alone, their episodes stay in the queue and the withheld notification is logged with its reason. The decision-shaped detectors (deletions, privilege grants, the event-driven set) notify on their own.

From the Line to the Inbox - Effective Severity and OverridesCopy Anchor Link

Crossing the line opens an episode; whether anyone is told, and how loudly, is decided in three layers - and every layer is visible on the Alerting screen:

• The tenant anomaly rule - instant on or off, notify on alerted only or also on info, which shapes count (spike, drop, silence), recipients, cooldown, digest cadence.
• Overrides - a partial rule for one detector, or for one user, application, AI agent, device, site or group. Lower the line for a resigning employee for 30 days, mute a noisy service account for a week, let one detector notify on info tier - each with a reason and an expiry. Overrides are applied when the episode is scored, when the queue is read, and when a mail is decided, so this screen and the inbox never disagree.
• Effective severity - the number in the subject line is the same computed severity the queue shows (score escalation, correlation, overrides and verdicts included - see above), further lifted by what 1Security already knows about the subject: a privileged account, a guest identity, reach into files with sensitive information, anonymous links, no MFA; for apps and agents, tenant-wide file access, admin consent for all users, an unverified publisher, very broad reach. A toxic combination such as privilege and sensitive reach lifts two tiers, and an info-tier episode never mails above low. The reasons are printed in the mail and recorded in the notification log - the mail can read higher than the queue, never lower.

Every decision - sent, withheld with its reason, or failed - is written to the notification log, so "why didn't we get an email about this" is answered on the Sent tab rather than in a support ticket.

One Dial, Every Industry - and No Tuning PeriodCopy Anchor Link

Anomaly detection normally ships as a black box. Someone else picked the threshold, you cannot see it and you cannot move it, and everything below it is discarded rather than kept - so a critical anomaly can pass with no trace that it ever existed. You live with one of two outcomes: it fires so often that the team stops reading it, or it stays quiet and you have no way of knowing what it decided not to tell you. From the outside those two failures are indistinguishable - a screen with nothing on it. Tuning is no safer, because a new threshold only applies going forward: moving it is a bet on a quarter of your future, so in most tools nobody moves it at all.

1Security splits that single hidden decision in two. What is unusual is measured and always recorded, down to 2 sigma, whether or not it clears your bar. What deserves an alert is a line you move. Full visibility on one side, a queue you can actually read on the other - and nothing thrown away in between.

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 EventsCopy Anchor Link

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 a human gives it a verdict. Acknowledge says seen, being looked into and keeps it visible without counting as new. Remediate closes the loop on a real incident - confirmed and dealt with, by a response action or outside 1Security - and stays on the books as the incident record; if the behaviour recurs, that is a new episode, not a reopened old one. Dismiss says harmless - expected behaviour or a false alarm - and stops the episode counting as a corroborating signal for the entity’s other detections. Track sends an episode back to silent logging - the default state anomalies arrive in - without pretending a verdict was reached. 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 (the entity's activity for an anomaly, detections per day for a trend or an incident), 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.

History & CommentsCopy Anchor Link

Every episode's drawer has a History & Comments tab: who changed what, when, newest first, with a composer at the top (Enter sends, Shift+Enter adds a line). Recorded on its own: every status change (from → to, including bulk changes from the queue), every manual severity verdict and its clearing, and every response action requested from the drawer or the queue's Respond column - the action and the entity it was requested for, with the run itself in the Action Center. Comments are for what the verdict alone cannot say: what you checked, who you asked, why you dismissed. A location incident's history also carries its location's history - the allowance that resolved it is right there, with the name of the admin who gave it.

The tab badge and an Updates column on the queue show how many entries an episode has. Twenty updates on one anomaly means significant work was already done there - the column tells a reviewer which rows somebody has been living in and which nobody has touched, before a single drawer is opened.

Filtering In DepthCopy Anchor Link

The always-visible controls cut the queue by tier (Alerted / Info) and triage state (Open / Acknowledged / Remediated / Dismissed / Tracked); 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.