How the Rule Engine Works

Every managed agent runs a behavioral rule engine against its live kernel event stream. Windows ETW events and Linux eBPF events are normalized to a common event shape before the rules see them, so a single rule definition fires on either OS. When a rule matches, the agent attaches the detection to its next heartbeat; the cloud persists it and pushes a live event to every open dashboard in the organization.

Each detection carries:

• Severity — info, low, medium, high, or critical. Rules are heuristics; severity reflects how strongly the matched pattern indicates malicious activity.
• Title and description — what the rule looks for and what was actually observed (process names, PIDs, paths).
• Evidence — up to 10 hand-picked events that caused the match (not a time-window dump), so you can see exactly why it fired.
• Tags — rule-specific annotations such as file counts or window lengths.

The Rule Catalog

Rule ID	What it detects
suspicious-exec-chain	Shell → downloader → shell process chains within a tight window — the classic curl http://... | bash downloader-runner pattern (PowerShell/cmd analogues on Windows).
mass-file-access	A single process reading an unusually large number of files in a short window — ransomware-enumeration / data-harvesting heuristic.
reverse-shell-heuristic	A shell whose standard input/output is bound to a network socket.
privilege-escalation-noninteractive-parent	Privilege escalation launched from a non-interactive parent process (no terminal or logged-in session behind it).
unusual-outbound-from-system-daemon	A system daemon or service making outbound network connections it has no business making.
mass-file-rename	Bulk renames to extensions like .locked or .encrypted — active file-encryption behavior.
ransom-note-pattern	Creation of ransom-note-style files (HOW_TO_DECRYPT* and similar).
shadow-copy-deletion	Backup sabotage: vssadmin shadow-copy deletion on Windows, btrfs subvolume delete and similar on Linux.
crypto-miner-heuristic	Known miner binaries and protocols (xmrig, stratum+tcp, etc.).
ransomware-kill-chain	Meta-rule: fires when two or more of the component rules above fire on the same host within 5 minutes — a very-high-confidence "ransomware in progress" signal.

Rules can be toggled per organization or per agent, and response actions (host isolation, alerting, kill-chain sensitivity) configured, under Systems → Security.

Two additional rules run cloud-side rather than on the agent: fleet-baseline-deviation (a process deviates from the per-application behavioral baseline built from your own fleet) and approved-app-hash-mismatch (an approved application's primary binary hash diverges from your organization's reference hash). Both are off by default and support a shadow mode that records what would have fired without raising alerts.

Where Detections Appear

• Live toasts — each new detection raises a severity-colored toast in the top-right of the dashboard (auto-dismisses after 8 seconds). Click a toast to open the detections panel for that agent.
• Detections panel — a right-side drawer listing the agent's detections from the last 72 hours (including acknowledged ones), each with its severity chip, evidence, and actions.
• Alerts — detections can feed your alert rules and channels like any other signal, depending on the response actions configured under Systems → Security.

Acknowledging

Use Acknowledge on a row once it has been reviewed, or Acknowledge all in the panel footer to clear the backlog for one agent. Acknowledging records that a human looked at the detection — it does not suppress future firings.

Triaging False Positives: the Allowlist

Legitimate tools trip behavioral heuristics — backup software renames thousands of files, performance toolkits read entire directory trees. The Behavioral Detection Allowlist exempts a specific (process, rule) pair, optionally narrowed to a file-path pattern, so a known-good app stops generating noise without disabling the rule fleet-wide.

The fast path: "Allow this process"

1. Open the detection in the detections panel. Rows with a known process and rule show an Allow this process button next to Acknowledge.
2. The dialog pre-fills the process and rule. Optionally add a path pattern glob (e.g. *Windows Performance Toolkit*) to scope the exemption — suggested patterns from the detection's evidence appear as one-click chips.
3. Add a note explaining why the exemption is safe, then click Add to Allowlist. The detection is acknowledged automatically.

Managing entries

The full list lives on the Integrations → Security tab. Each entry shows process, rule, scope (path pattern or any path), notes, and date added. Only organization admins can add or remove entries; duplicates are rejected. Allowlisted detections are dropped server-side before they are stored or trigger alerts.

Scope as narrowly as you can. Prefer process + rule + path pattern over process + rule alone, and never allowlist a broad interpreter (e.g. bash or powershell.exe) against an execution rule — that is exactly the cover an attacker wants.

Approved Applications (Related, but Different)

The Approved Applications list (Integrations page) is a software-inventory whitelist used by Smart Reports to surface unapproved installs across the fleet. It does not suppress behavioral detections — use the Behavioral Detection Allowlist for that. Keeping the two separate is deliberate: an app can be approved for installation and still warrant a look when it starts mass-renaming files.

See Integrations & Tickets for the Approved Applications workflow, and Security for the wider security model including host isolation and operator elevation.