> For the complete documentation index, see [llms.txt](https://help.nightfall.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.nightfall.ai/data-exfiltration-prevention/user-risk-agents.md).

# User Risk Agents

AI agents that hunt for insider risk across your workforce, investigate the evidence, and deliver cases your team can act on.

{% hint style="info" %}
User Risk Agents are available in **Early Access** starting October 14, 2026.
{% endhint %}

User Risk Agents bring automated threat hunting and investigation to insider risk. They identify employees whose activity warrants attention, investigate the underlying evidence, and deliver a written case explaining what happened, why it matters, and what to do next.

Seeing data move is not the same as understanding a threat. An analyst still has to connect downloads to uploads, inspect sensitive content, trace personal-account activity, and decide whether a pattern deserves investigation. User Risk Agents take on that work, so your team can move from searching for risk to acting on it.

In the console, open **Discovery → User Risk**.

<figure><img src="https://3764378997-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZeqNSdo8J8cLJPU3Gs5M%2Fuploads%2FENvNrvncDRchifnqTpl3%2Fuser-risk-overview.png?alt=media&amp;token=4aeb2532-ab4f-4219-b7c3-31d33aa53ffb" alt=""><figcaption></figcaption></figure>

## How User Risk Agents work

Insider risk often emerges across a sequence of actions. A download, a repository clone, or an upload to a personal account may reveal little in isolation. Together, their timing, destination, and content can tell a different story. User Risk Agents bring those signals together in two stages: **Discover** and **Investigate**.

### Discover

A triage agent evaluates employee activity daily. It looks for signals such as:

* Sensitive data moving to untrusted destinations
* Downloads followed by uploads
* Personal-account activity
* Unsanctioned AI use
* After-hours activity
* Job-search activity

It weighs those signals against each employee's own history and your organization's norms, and produces a **risk score from 0 to 100** and a **risk level** (Critical, High, Medium or Low). The score prioritizes investigation. It is a starting point, not a conclusion.

### Investigate

An investigation agent examines every **High** and **Critical** finding. The initial risk score starts the investigation, and the agent tests whether it holds up. It:

* **Reconstructs the timeline** — what happened, in what order, and how close together.
* **Inspects the underlying content** — what the data is, and whose data it is.
* **Checks whether the activity came from a person or an automated process**, such as a sync client or service account.
* **Compares behavior with individual and peer baselines** — whether this is new for the employee, and how they compare with their team.
* **Considers alternative explanations** — a sanctioned workflow, an unconfirmed business process, a whole team that works the same way.
* **Documents what the evidence supports.**

The investigation agent uses large language models together with Nightfall's own detection tools to pull and examine the events behind each signal. Each report explains which concerns are supported, which were ruled out, and what still requires human review.

Each completed investigation becomes a case in the **Needs Review** queue.

### What the data is — and whose it is

Knowing that a file moved is only the beginning. Understanding what it contains, and whose data it is, can change the entire assessment.

User Risk Agents are built on Nightfall's AI-native content detection, so every finding connects behavior with the sensitive data involved — from identity documents and financial records to source code and employee information. The investigation agent also considers whether personal information belongs to the employee moving it. Uploading your own tax return is different from uploading a coworker's, or an entire payroll file. That distinction reduces false positives and focuses investigations on meaningful exposure.

## The review queue

The left side of the page is your queue of cases. When you open User Risk, the **Needs Review** tab opens and the first case loads automatically. If nothing needs review, you land on **Escalated**; if nothing is escalated, you land on **All**.

| Tab              | What it shows                                                              |
| ---------------- | -------------------------------------------------------------------------- |
| **All**          | Every case, whatever its status.                                           |
| **Needs Review** | New and reopened cases no one has acted on yet.                            |
| **Escalated**    | Cases someone has escalated.                                               |
| **Closed**       | Cases that have been resolved. Closed cases are muted and their tags gray. |

Each case in the queue shows:

* The employee's **name** and **job title**
* The **date** the report was generated
* A **concise summary** of the most significant finding
* The **risk level** (Critical, High, Medium or Low)
* An **Intent** tag when the investigation found suspicious activity
* The case's **status** (Needs Review, Escalated or Closed)

### Search and filter

Use **Search users** to find an employee by name. Use the filter button next to it to narrow the queue by:

* **Risk** — any combination of Critical, High, Medium and Low.
* **Report generated date** — Last 7, 30, 60, 90 or 180 days, or a custom date or date range.

When filters are applied, the filter button shows how many filter types are active. Choose **Clear filters** to remove them all.

<div align="left"><figure><img src="https://3764378997-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZeqNSdo8J8cLJPU3Gs5M%2Fuploads%2F1hNKFWwRg34gD0rHoZ8l%2Fuser-risk-filter-menu.png?alt=media&amp;token=d26458ae-63b7-4e33-bf44-569d96d67aeb" alt="" width="375"><figcaption></figcaption></figure></div>

## Reading a case

Select a case in the queue to open it on the right.

### Header

The header identifies the employee and the report:

* **Name, job title and department.** The badge next to the name shows how many devices Nightfall sees for this employee.
* **When the report was generated.**
* **Risk level** and **status**.
* **Workforce context** — manager, workforce type, join date and departure date, from your identity provider. Any field your identity provider does not supply shows as **N/A**.

{% hint style="info" %}
Workforce context can change the assessment. Activity from an employee with an upcoming departure date reads differently from the same activity by someone who joined last week.
{% endhint %}

### Past reports

If User Risk Agents have investigated this employee before, **Past reports** lists each earlier report with its date, summary, risk level and final status. Use it to see whether this is a first occurrence or part of a pattern.

<figure><img src="https://3764378997-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZeqNSdo8J8cLJPU3Gs5M%2Fuploads%2FE7Hu106AOg6LH28HCoVT%2Fuser-risk-past-reports.png?alt=media&amp;token=9ecf406f-2978-48f5-9b77-4d3c4aad22fa" alt=""><figcaption></figcaption></figure>

### Analysis

The Analysis card is the investigation agent's written case. Its subtitle shows what the investigation covered: the **analysis period**, the **number of events** reviewed, the **number of sources** they came from, and the agent's **confidence** in its assessment.

Findings are grouped into two sections:

* **Intent** — suspicious activity: findings that may indicate an attempt to move data where it should not go, and that may warrant escalation or containment.
* **Habit** — persistent poor data hygiene: risky but established behavior, such as a personal-account workflow, that can expose substantial sensitive data without establishing malicious intent.

Each section opens with a short summary, followed by its individual findings. Every finding includes:

* A **title** stating what happened
* The finding's **risk level**
* The **kinds of sensitive data** involved — for example PII, PHI, Fin (financial), Sec (secrets and credentials) or IP (intellectual property)
* The **device** it happened on
* A **narrative** explaining the evidence, how it compares with the employee's own history and their peers, and any alternative explanation that has not been confirmed or ruled out

Select **View events** — on the Analysis card or on an individual finding — to trace the evidence to the underlying events in Nightfall Forensic Search.

{% hint style="warning" %}
Read the narrative, not just the risk level. Reports separate observed facts from interpretation and name the gaps a human needs to resolve. A finding can warrant escalation while still leaving questions about its purpose — and a Critical risk level can come from persistent poor data hygiene alone. Your team retains control of the decision.
{% endhint %}

### Risk breakdown

The Risk Breakdown explains the score: the total out of 100, and each signal that contributed to it along with the points it added.

### Devices

Lists every device Nightfall has seen for the employee, with its device ID, connection status, agent version, Stealth Mode status, and the browser extensions and AI monitoring installed on it.

### Audit log

Every review action on the case — generated, escalated, resolved, reopened — is recorded with who took it, when, and the note or rationale they left. Nothing is overwritten; the log is the case's complete history.

## Responding to a case

Findings guide the response. Depending on what the evidence supports, a case may warrant deeper investigation, immediate containment, a policy change, or employee coaching. Record your disposition with the two actions in the case header: **Escalate** and **Resolve**.

### Escalate

Escalate a case when it needs further action from someone else — your security lead, HR, legal, or an incident response process.

1. Select **Escalate**.
2. Optionally, add a note giving context for whoever picks it up.
3. Select **Submit escalation**.

The case moves to the **Escalated** queue, and the escalation and your note are recorded in the audit log.

<figure><img src="https://3764378997-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZeqNSdo8J8cLJPU3Gs5M%2Fuploads%2FN1Ec48t8HjqTRKuKGcJF%2Fuser-risk-escalate.png?alt=media&amp;token=e16ca8bc-015e-48a7-a63d-fd8e8c0763c2" alt=""><figcaption></figcaption></figure>

### Resolve

Resolve a case when no further action is needed, and record the rationale:

| Disposition                       | Use it when                                                                                   |
| --------------------------------- | --------------------------------------------------------------------------------------------- |
| **Expected Behavior**             | It happened, and it is fine — approved, sanctioned, or just how work gets done here.          |
| **Incorrect Assessment**          | Nightfall got it wrong — the wrong person, the wrong data, or it did not happen as described. |
| **Correct Assessment. Resolved.** | The issue was genuine and has been handled internally. No further action is needed.           |

Add an optional note — an approval reference or supporting context — and select **Submit**. The case moves to **Closed**.

<figure><img src="https://3764378997-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZeqNSdo8J8cLJPU3Gs5M%2Fuploads%2Fmx4uZOFBfnEf6Ej9OU4S%2Fuser-risk-resolve.png?alt=media&amp;token=eb0d22e4-459c-459c-8088-9604917c38da" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
Your disposition is feedback. **Incorrect Assessment** in particular tells Nightfall where an investigation went wrong, so leave a note explaining what it missed.
{% endhint %}

A closed case can be reopened for review if new information comes to light. Reopening is recorded in the audit log with the reviewer's note.

### Share a case file

The **⋯** menu in the case header offers:

* **Download as PDF** — a shareable case file for HR, legal and other stakeholders who do not use Nightfall.
* **Email** the employee, or **email their manager**.
* **View Devices** — jump to the employee's devices.

{% hint style="warning" %}
Think before you contact the employee or their manager. If a case may involve deliberate data theft, contacting either one can alert the employee before your security or HR team is ready. Escalate first when in doubt.
{% endhint %}

## Connected workflows

Use **Manage Alerts** at the top of the page to bring User Risk findings into the tools your team already uses. Notifications go to your team only — **nothing is ever sent to the employees being reviewed.**

<figure><img src="https://3764378997-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZeqNSdo8J8cLJPU3Gs5M%2Fuploads%2FQZfdRYki0AJynI24Grty%2Fuser-risk-actions-menu.png?alt=media&amp;token=178e24a1-306a-43af-b5ac-4ebbfa845e5a" alt=""><figcaption></figcaption></figure>

**Send alert for** — choose which events trigger a notification:

* **New User Risk report** — one message as soon as each report is produced.
* **Report status change** — when a case is escalated, resolved or reopened, including who changed it and why.
* **Digest of all new reports** — one message covering every report produced since the last digest, whatever its risk level.

**Send it to** — turn on one or more destinations: **Email**, **Slack** (choose a channel), **Microsoft Teams**, **Jira**, or your **SIEM or SOAR** platform. These use the same destinations configured in Admin Alerting.

Select **Save** to apply your changes.

<figure><img src="https://3764378997-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZeqNSdo8J8cLJPU3Gs5M%2Fuploads%2F23UEzJktQ7oQ0JL7kGHD%2Fuser-risk-manage-alerts.png?alt=media&amp;token=64e8b118-0a7f-49aa-8f1b-87a409ff6f54" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
Sending findings to your SIEM or SOAR places User Risk cases alongside your other security signals, so they can be correlated and can trigger your existing response playbooks.
{% endhint %}

## Risk levels

| Level        | Meaning                                                                     | Investigated by the investigation agent?  |
| ------------ | --------------------------------------------------------------------------- | ----------------------------------------- |
| **Critical** | Strong, corroborated signals of significant data exposure. Review promptly. | Yes                                       |
| **High**     | Significant risk that warrants a human decision.                            | Yes                                       |
| **Medium**   | Elevated activity worth tracking.                                           | No — prioritized by the triage agent only |
| **Low**      | Minor deviations from normal behavior.                                      | No — prioritized by the triage agent only |

## FAQ

<details>

<summary>Why don't I see a case for every employee?</summary>

The triage agent evaluates every employee daily, but only High and Critical findings go to the investigation agent and become cases. This keeps your queue focused on the people who most need a human decision.

</details>

<details>

<summary>Can I run an ad-hoc investigation of a user?</summary>

Not yet. On-demand investigations of a specific user are coming soon. Today, investigations run automatically on High and Critical findings from the daily triage.

</details>

<details>

<summary>Does a Critical case mean the employee is acting maliciously?</summary>

No. The risk level measures how much data exposure the activity creates, not the employee's motive. Read the **Intent** and **Habit** sections: persistent poor data hygiene can expose substantial sensitive data without any sign of malicious intent.

</details>

<details>

<summary>Do User Risk Agents replace my analysts?</summary>

No. User Risk Agents do the evidence gathering — connecting events, inspecting content, comparing against baselines and testing the initial assessment — which expands your team's investigative reach and gives analysts more time for the cases that need their expertise. Your team retains control of every decision.

</details>

<details>

<summary>Why does a field in the header say N/A?</summary>

Manager, workforce type, join date and departure date come from your identity provider. If your identity provider does not supply a field, User Risk shows N/A rather than guessing.

</details>

<details>

<summary>Will the employee know they are being reviewed?</summary>

Not from Nightfall. Notifications go only to the destinations your team configures, and nothing is sent to the employees being reviewed. The only way an employee hears about a case is if someone on your team contacts them.

</details>

<details>

<summary>I disagree with a case. What should I do?</summary>

Resolve it as **Incorrect Assessment** and add a note saying what the investigation got wrong. That disposition is recorded in the audit log and helps improve future investigations.

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.nightfall.ai/data-exfiltration-prevention/user-risk-agents.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
