**Lidar** is the console module for identity threat detection: _"Threat detection, monitoring, and security intelligence for your application."_ Open it from the sidebar under **Lidar** (`/dashboard/security`).

The module is scoped to the **currently selected environment**: pick a project and environment in the top bar before you expect live data.

![Lidar overview](/content/console/lidar.overview.png)

Lidar detects threats inside Authdog (monitors → findings → Signals). It is separate from [SIEM log streaming](/docs/events-webhooks), which forwards the raw event trail to external tools. For the detection model, see [Lidar concepts](/docs/concepts/lidar).

## Tabs

| Tab | Route | Purpose |
| --- | --- | --- |
| **Overview** | `?tab=overview` | Access status and detection category totals |
| **Signals** | `?tab=signals` | Live detections for the selected environment |
| **Scan Logs** | `?tab=scan-logs` | Analysis-run history for the environment |
| **Dashboards** | `?tab=dashboards` | Severity timeline over a time range |
| **Monitors** | `?tab=monitors` | Enable detectors and tune query and severity |

## Request Lidar access

Lidar is feature-gated. On **Overview**, a marketing panel headed _"Protect against bots, fraud, and abuse"_ carries a **"Request access"** button and lists what the product includes:

- Blocks common threats like impossible travel and brute force attacks
- Detections can be tailored to stop threats unique to your app
- Advanced device fingerprinting analyzes over 20 signals
- Combine signals with Restrictions for full control

The access badge reflects the environment's status for feature slug `lidar`:

| Status | What you see |
| --- | --- |
| No access | Prompt to **Request access** |
| Pending | Badge: access requested, pending review |
| Approved | Badge: **Protection active** |

Until access is approved, the detection panels stay blurred behind **"Detections are locked"**. An empty state reads as locked, not as "no threats." After approval, Signals, Scan Logs, Dashboards, and Monitors load from the threat-detection APIs for that environment.

Requests land in Authdog's sales review queue; track yours from the console.

## Overview

Beyond the access panel, Overview summarizes detections for the environment. Four counters (**Total Detections**, **Allowed**, **Challenged**, and **Blocked**) sit above a bar/line chart of detections over the last 30 days.

Below the chart, a per-category breakdown counts detections by type: **Bot detection**, **Brute force attack**, **Domain protections**, **Impossible travel**, **Repeat sign up**, **Stale account**, **Unrecognized device**, and **Restriction enforced**.

## Monitors

**Monitors** lists the detector catalog: _"Per-environment Lidar detection rules. Toggles persist to threat-detection and gate the AI analysis worker."_

The table columns are Monitor (name plus its query), Type, Status, Severity, Last triggered, and an Enabled toggle. Authdog seeds a default set the first time you open Monitors for an environment:

| Monitor | Type | Severity | Query |
| --- | --- | --- | --- |
| Brute force threshold | Threshold | Critical | `detection:brute_force attempts:>100 window:5m` |
| Impossible travel | Anomaly | High | `detection:impossible_travel distanceKm:>5000` |
| High bot score | Threshold | High | `detection:bot botScore:>0.9` |
| Breached password usage | Event | Critical | `detection:breached_password` |
| Auth rate limit spike | Metric | Medium | `detection:rate_limit observed:>limit` |
| Unrecognized device MFA | Event | Medium | `detection:unrecognized_device action:challenged` |
| Stale account reactivation | Anomaly | Medium | `detection:stale_account dormantDays:>90` |
| Repeat signup abuse | Threshold | Low | `detection:repeat_signup priorAccounts:>2` |
| Credential stuffing | Threshold | Critical | `detection:credential_stuffing attempts:>200 window:15m` |
| MFA fatigue / push bombing | Anomaly | High | `detection:mfa_fatigue challenges:>4 window:30m` |
| Suspicious privilege change | Event | Critical | `detection:privilege_escalation` |

A monitor that has never fired shows status **NODATA** and _"Never"_ as its last-triggered time.

For each monitor, **enable or disable** the detector, **edit the query** (it must start with `detection:<id>`), and **change severity** (`low`, `medium`, `high`, `critical`).

Useful query tokens:

| Token | Effect |
| --- | --- |
| `detection:<id>` | Required. Selects the catalog detector |
| `window:` | Sets the correlation window (for example `5m`) |
| `attempts:`, `priorAccounts:`, `challenges:` | Soft floors for minimum events; also passed to the model |
| `dormantDays:` | Stretches the analysis window for stale-account style detectors |
| `botScore:`, `distanceKm:`, `observed:`, `action:` | Advisory thresholds in the detector prompt |

Saving a monitor updates the per-environment row used by the analysis pipeline. Disabled monitors do not produce new Signals.

## Signals

**Signals** shows live detections: _"Live Lidar detections for the selected environment (AI analysis → threat-detection)."_

The header carries a time-range selector (default: Past 1 day), a **Live** indicator, and two development helpers, **"Generate events"** to produce synthetic traffic and **"Clear synthetics"** to remove it again.

A **Signal volume** chart sits above the table, and a **FACETS** rail on the left filters by **Severity**, **Detection type**, **Origin**, **Synthetic**, **Country**, **Client IP**, and **User**.

Table columns are Time, Severity, Signal, User, IP, and Rule (`lidar.<detectionType>`). Use the search bar with field tokens:

```
detection:brute_force
ip:52.94.236.248
user:eve
detection:impossible_travel status:critical
```

Open a Signal to inspect confidence, model, event count, and recommended action when present. The same burst of traffic can raise multiple Signals when several detectors match; correlate by user, IP, and time.

> **Tip**
>
> Use **Generate events** in a `dev` environment to see the whole pipeline work
> end to end before you have real traffic, then **Clear synthetics** so your
> counters go back to reflecting reality. The **Synthetic** facet keeps the two
> apart in the meantime.

## Scan Logs

**Scan Logs** records each analysis run over the environment's events, when it ran, what it examined, and what it produced. It is the place to check when Signals look emptier than expected: no runs means the analysis worker has nothing to chew on (or the monitors gating it are disabled).

## Dashboards

**Dashboards** charts Signal severity over the selected range (for example 1h, 4h, 24h, 7d). It uses the same Signals feed, bucketed for a timeline view. Empty charts usually mean no approved access, no selected environment, or no detections in range.

## Practical limits

- A **selected environment** is required for Signals, Scan Logs, Dashboards, and Monitors.
- **Access must be approved** before protection is considered active.
- Numeric monitor thresholds are often **soft** (prompt plus floor), not hard batch gates.
- Breached-password **policy** enforcement in [Authentication > Policies](/docs/console/authentication) is a separate control; Lidar can still raise breached-password Signals when those attributes appear on events.
- Overview counters may lag live Signals until traffic and analysis catch up.

## Related

| Read | To learn how to |
| --- | --- |
| [Lidar concepts](/docs/concepts/lidar) | How monitors become findings and Signals |
| [Authentication](/docs/console/authentication) | Set the policies that feed detections |
| [Audit](/docs/console/audit) | Inspect the underlying event trail |
| [Notifications](/docs/console/notifications) | Forward signals to Slack or a SIEM |
| [Bot protection](/docs/bot-protection) | Block automated traffic at the sign-in surface |
| [Security](/docs/security) | Platform security defaults |