**Lidar** is Authdog's native identity threat detection. It watches the authentication event stream for each environment, correlates related activity, and surfaces **Signals** operators can triage in the console.

Lidar is not the same as SIEM log forwarding. Lidar *detects* threats inside Authdog. [SIEM channels](/docs/events-webhooks) *stream* the raw event trail to Datadog, Splunk, Sentinel, and similar tools. Most teams use both: Lidar for identity-aware detections, SIEM for long-term correlation outside Authdog.

For the operator walkthrough, see [Lidar in the console](/docs/console/lidar).

## How it works

Lidar runs as parallel correlating slices over auth events:

1. **Monitors** define which detectors run and how they are tuned (query, severity, enabled).
2. Auth events are **classified** into classes such as `authn.failure` or `authn.success`.
3. Events are **grouped** by IP, subject (user), or environment, depending on the detector.
4. Matching detectors produce a **finding** when the analysis marks the group suspicious.
5. Findings appear in the console as **Signals**.

```
monitor.query  →  detector + thresholds (per environment)
events         →  classify
groupBy        →  correlate (subject | ip | environment)
finding        →  threats row (deduped)
console Signal →  SecOps UI over that row
```

Findings are environment-scoped and stored in the platform threats store, so the same detection is readable from Lidar Signals and from the threats API.

## Monitors and detectors

Every environment seeds a default monitor catalog. Operators can enable or disable monitors and edit the query string and severity. A monitor query always starts with `detection:<id>` and may add threshold tokens:

| Detector | Default query | Correlates by | Question it answers |
| --- | --- | --- | --- |
| Brute force | `detection:brute_force attempts:>100 window:5m` | IP | Credential attack from one source? |
| Impossible travel | `detection:impossible_travel distanceKm:>5000` | Subject | Physically impossible movement? |
| Bot | `detection:bot botScore:>0.9` | IP | Automated auth traffic? |
| Breached password | `detection:breached_password` | Subject | Known-bad password attributes present? |
| Rate limit | `detection:rate_limit observed:>limit` | IP | Auth volume spike? |
| Unrecognized device | `detection:unrecognized_device action:challenged` | Subject | New device or client for this user? |
| Stale account | `detection:stale_account dormantDays:>90` | Subject | Dormant account suddenly active? |
| Repeat signup | `detection:repeat_signup priorAccounts:>2` | IP | Registration abuse? |
| Credential stuffing | `detection:credential_stuffing attempts:>200 window:15m` | Environment | Env-wide list testing? |
| MFA fatigue | `detection:mfa_fatigue challenges:>4 window:30m` | Subject | MFA push bombing? |
| Privilege escalation | `detection:privilege_escalation` | Subject | Suspicious admin consolidation? |

Some tokens change analysis windows or minimum event floors in code (`window:`, `attempts:`, `priorAccounts:`, `dormantDays:`). Others are advisory text injected into the detector prompt (`botScore:`, `distanceKm:`, `observed:`, `action:`). Treat high numeric thresholds as guidance for the model, not a hard in-batch count gate.

## Findings and deduplication

When a detector returns a suspicious verdict, Authdog upserts a finding keyed by:

```
ai:<detectorId>:<subject>:<windowStart>
```

Redelivery of the same analysis window refreshes the verdict instead of creating a duplicate alert. Operator triage fields (status, assignee, resolution) survive re-analysis.

A single burst of auth traffic can produce multiple Signals when several detectors match different correlation keys. Triage joins on user, IP, and time — not a single combined row.

## Lidar vs audit logs vs SIEM

| Surface | Role |
| --- | --- |
| [Audit logs](/docs/audit-logs) | Immutable record of what happened (sign-ins, role changes, admin actions) |
| [Events & webhooks / SIEM](/docs/events-webhooks) | Forward that event stream to your log platform |
| **Lidar** | Detect suspicious patterns in the stream and raise Signals |

Audit data alone is not a threat decision. Lidar findings are derived detections; they can be wrong or incomplete if history or queue processing is degraded. Always correlate with neighboring audit events before remediating.

## Access and environment scope

Lidar is gated per environment. Until access is approved, the Overview shows a request flow rather than live protection. Monitors, Signals, and Dashboards require a selected environment and approved Lidar access to show meaningful data.

## Related

| Read | To learn how to |
| --- | --- |
| [Lidar in the console](/docs/console/lidar) | Enable access, tune monitors, and triage Signals |
| [Audit logs](/docs/audit-logs) | Inspect the underlying identity event trail |
| [Events & webhooks](/docs/events-webhooks) | Stream events to an external SIEM |
| [Security](/docs/security) | Platform security defaults and hardening |