Insider risk triage, 83 seconds. A real, unscripted run in a lab with synthetic employees and activity. Captions are burned in. Waits are cut out, not sped up. Wazuh, Grafana with Loki, DFIR-IRIS, and Splunk stand in for the alerting, activity, case, and SIEM tools a security team already runs.
Read the transcript

This is the message your agent never sent. Here’s why.

6:43 PM. The office has emptied out, and someone starts pulling sales and finance files they’ve never touched before.

Your on-call analyst gets the alert. By the time they open it, the triage agent has pulled the alert, the last six hours, and two weeks of normal from the tools you already run, and put it all on one screen: exactly what changed.

It’s ready to open a case. But insider cases are delicate, so it sends what it prepared to an authorized person to review.

The analyst sees the exact call it wants to make, and approves that one call. Nothing more.

The case lands in your case system, ready to work.

Then the analyst asks it to give the manager a heads-up. But that could tip off the person you’re investigating. Policy keeps it inside the security team, and the message never leaves.

And when the case is reviewed, every attempt, every approval, every block is already on the record, in your own SIEM.

Agents that do the work. Controls that hold. That’s governed autonomy. That’s Decision Terrain.

What happens in the demo?

The run follows one alert from detection to a case, with two controls on the agent: a person approves the one write it may make, and a rule blocks contact outside the security team.

  1. The alert fires. At 6:43 PM, a Wazuh rule flags 15 or more after-hours downloads by one employee within 10 minutes.
  2. The agent gathers the evidence. While the on-call analyst is notified, the triage agent reads the alert, the employee’s last six hours of activity, and a 14-day baseline from Loki, the store behind the Grafana dashboard. The activity includes sales pricing and finance forecast files outside the employee’s normal pattern. These reads are allowed without review.
  3. The case waits for a person. The agent prepares a case and calls the case tool. An Organization security rule, Analyst approval for new cases, holds that call before it runs.
  4. An analyst approves that one call. The analyst reviews the exact call the agent wants to make and approves it once. The approval covers that call only.
  5. The case opens. Case #7 opens in DFIR-IRIS with the triage summary: 160 after-hours downloads (9.3 GB) in six hours, about 17 times the normal download count and 482 times the normal volume.
  6. The tip-off is blocked. The analyst asks the agent to let the employee’s manager know. A Block rule, No contact outside the security team, stops the notify call. No message is sent.
  7. The record reaches the SIEM. The approval request, the held call, the approval and its use, and the denied notification appear as audit events in Splunk.

Why put the controls there?

Insider-risk work is time-sensitive and discreet. Gathering the alert, recent activity, and baseline is repetitive reading across several tools, so the agent can do it before the analyst opens the case. Opening a case is a consequential write, so a person reviews the exact call first.

Notifying a manager is different. In an insider investigation, a well-meant heads-up can warn the person under review or someone close to them. The demo’s Block rule keeps the agent’s outgoing contact inside the security team. The analyst still decides who to involve and how, outside the agent’s authority.

What the demo shows, and what it does not

  • The employees, files, and activity are synthetic. No real person or organization is shown.
  • The agent reaches the lab tools through an MCP server written for the demo. It exposes five operations: three reads, one case write, and one manager notification. It is not a packaged product connector.
  • The approval and Block behavior come from Organization security rules that cover these MCP tool calls in this deployment. Evaluate each tool path and rule in your own environment.
  • The approval applies to one exact call. It does not grant the agent standing authority to open cases.
  • The Block rule stops the agent’s notify call. It does not control what people do through other channels.
  • The run used a hosted model through the Organization’s own cloud account. It is not a disconnected or air-gapped run.
  • Splunk receives the audit events through the deployment’s forwarding route. A local Splunk instance stands in for the team’s SIEM.