---
title: Anomalies
description: Every policy, user, application and AI agent learns its own baseline, and today's activity is measured against it - with a sensitivity dial you can move and see the answer to immediately, on your real data, with no tuning period.
icon: Activity
---

# 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

<Cards>
  <Card
    title="Catch what no rule anticipated"
    description="Rules catch what you predicted. Baselines catch what you didn't: something that quietly matched ~12 resources a day suddenly matching 2,000 is an anomaly, whatever the cause - exfiltration, a misfired automation, a permission change gone wide."
  />
  <Card
    title="Set your own bar - and see the answer now"
    description="Move the Alert sensitivity dial and the queue re-answers instantly, against your real history. No tuning period, no shadow mode, no waiting a quarter to find out whether the setting was right."
  />
  <Card
    title="Look below the alert line"
    description="Other tools decide a threshold for you and silently discard everything under it. 1Security keeps every meaningful deviation down to 2 sigma as Info - so when something slips past alerting, the evidence is already there."
  />
  <Card
    title="Triage like an incident queue"
    description="Anomalies are episodes with a lifecycle and a triage state - open, acknowledged, dismissed. A one-day spike that normalizes overnight stays in your queue until a human has looked at it."
  />
</Cards>

## 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.

<Callout type="info">
  Detection stays silent for the first **14 days** of history on anything it
  watches. Fourteen days is the point at which a median and its spread mean
  something; before that, 1Security collects and says nothing rather than
  inventing alerts out of a week of data.
</Callout>

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.

<Callout type="info">
  Because the baseline is learned per policy and per entity, "anomalous" always
  means *anomalous for this one, in this tenant*. Five hundred file shares might
  be an ordinary Tuesday for one organization and a five-alarm incident for
  another - the same screen handles both without configuration.
</Callout>

## 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.

<Callout type="info">
  The investigative move this enables: *"we think we missed something last
  week."* Lower the line, filter to that week, and look at what was already
  recorded below your old threshold. Raise it back afterwards - moving the dial
  never destroys data, in either direction.
</Callout>

## 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.

<Callout type="info">
  An investigative pattern worth keeping: after any incident elsewhere in the
  tenant, switch to **Info**, filter to the affected resource type and the
  incident's date range - the weak signals recorded around that time are the
  cheapest forensic evidence you own. If they deserve promotion, lower the alert
  line and they become Alerted, history included.
</Callout>