Alert Triage

Alert triage is one of the easiest Flocks scenarios to deploy and one of the most frequently used. Its core question is: after alerts are collected from security devices, how can each alert quickly receive a structured, evidence-backed triage conclusion and be pushed automatically to the right operations touchpoint?

Flocks has the main Agent Rex pull raw alerts, persist intermediate data, delegate per-alert triage to a dedicated analysis Agent, send structured results through channels, and finally convert the full chain into a scheduled task that runs every hour.

Scenario Overview

Alert triage directly leverages Flocks' key capabilities:

Clear input: a single alert, a batch of alerts, or alerts within a time window
Clear output: structured triage results, JSON reports, channel notifications
Multi-step process: fetch data -> enrich context -> triage -> output
Results must be sent or persisted: they should not remain only in the conversation

This scenario does not replace the high-volume real-time detection capabilities of traditional NDR / TDP. It focuses on in-depth analysis after an initial security signal is detected. Any action that an analyst would perform to write a triage report based on alert evidence can become an assisted analysis chain in Flocks.

Sub-scenario

Batch NDR Triage Workflow: Based on the built-in Workflow stream_alert_triage, this periodically reads denoising result files produced by the real-time NDR alert denoising Workflow and generates triage reports using intelligence, AI triage, discovery, and asset vulnerability analysis.

Inputs and Outputs

Typical Inputs

ID or raw text of a single alert, as the minimum unit
A batch of alerts awaiting triage, usually from same-day unresolved tickets
Alerts within a specific time window, by hour or by day
Alert sources can be TDP, NDR, XDR, HIDS, EDR, WAF, or any device with an API or web console

Typical Outputs

Structured triage result: alert ID, attack type, confidence, involved assets, recommended action
Triage conclusion summary: short text that can be pasted directly into a ticket or group chat
JSON report: convenient for downstream storage or batch verification
Channel notification: pushed through WeCom / DingTalk / Feishu bots

Prerequisites

Dependency	Requirement
Model	A default model is configured; reasoning models perform better for complex triage. See Model Configuration
Alert source integration	Either the alert platform API or its web console is available. See Internal Security Product Integration
Tools	Intelligence tools (ThreatBook / VT / GreyNoise) are preferred for adding IOC context
Channels	At least one of WeCom / DingTalk / Feishu is connected. See Messaging & Alerting Integrations
Expert Agent	Optional. The project includes alert analysis sub-agents; if none are available, Rex analyzes directly with its own toolchain

Steps (WebUI)

Step 1: Create a Session

Go to Session Management -> + New Session and describe a one-off triage goal in natural language:

"Fetch the latest 5 alerts from the TDP page, triage them one by one, write the results as JSON, and send the summary to WeCom."

Step 2: Let Rex Fetch Raw Data

Rex automatically selects the integration method:

With API: call the API directly to pull alerts
Web only: use the browser tool to log in and extract page data; first use may require assisted manual login

The fetched raw alerts are written into the Workspace date directory, such as 3-28/alerts.json, instead of being kept only in the conversation. This is the basis for reuse by scheduled tasks later.

Step 3: Delegate an Analysis Agent for Per-alert Triage

Rex delegates to a dedicated alert analysis sub-agent. This is essentially a multi-Agent architecture:

Rex handles slicing, dispatching, and summarization
The analysis sub-agent receives a single alert plus its own system prompt and focuses on single-alert triage
Each triage result is produced independently, without contaminating the shared context

Step 4: Output JSON + Channel Notification

After per-alert triage completes:

JSON persisted: structured results return to the same Workspace directory for downstream systems
Channel notification: the configured WeCom / DingTalk / Feishu channel sends out the summary

In multi-group / multi-session environments, explicitly specify the Session ID to avoid sending messages to the wrong session. See WeCom Integration § Multiple Groups and Session ID.

Step 5: Convert to a Scheduled Task

Continue in the same session and tell Rex:

"Turn this inspection and triage process into a scheduled task that runs every hour and sends results to WeCom."

Rex automatically creates a task in Task Center:

Trigger: run once per hour
Task description: reuse the natural-language description from this session
channel: wecom / dingtalk / feishu
Session ID: specified session

After configuration, the chain runs hourly and sends results to the specified channel on schedule.

Real Case Walkthrough: Triage 5 NDR Alerts

Key points from an NDR alert triage demo:

Time	Rex action	Output / notes
0:00	Prepare channel: confirm WeCom bot and target Session ID are configured	One channel to one group does not require a Session ID; multiple groups require explicit selection
0:36	Fetch 5 alerts from the TDP page	Small demo volume; real runs can process dozens or hundreds
1:03	Write full raw data to Workspace, in the `3-28` directory	Raw data is persisted and reusable by scheduled tasks
1:33	Delegate a dedicated alert analysis sub-agent for per-alert analysis	Multi-Agent architecture; the sub-agent has its own system prompt
2:04	Analysis results take shape	Structured fields + conclusions
2:22	Push notification to WeCom	Five alert triage results delivered successfully
2:42	Identify conclusions such as "file upload attack x4", "IP 109.x appears repeatedly", and "WebShell + internal lateral movement"	Triage conclusions are formed from the evidence chain
3:42	Convert the whole chain into a scheduled task: run hourly + WeCom notification	Transitioning from ad-hoc analysis to continuous execution.

Output Example

Typical JSON structure, shown schematically:

json

[
  {
    "alert_id": "20260328-001",
    "source": "TDP",
    "attack_type": "webshell_upload",
    "src_ip": "109.x.x.x",
    "dst_asset": "10.10.x.x",
    "confidence": 0.85,
    "conclusion": "Confirmed file upload attack; a WebShell may have been planted",
    "related_alerts": ["20260328-003"],
    "recommended_action": "isolate the asset and collect forensic evidence"
  }
]

WeCom / DingTalk / Feishu notifications are packaged as text summaries so the duty team can review them quickly.

Continuous Operation: From One-off to Routine

This is the key step that moves alert triage from single-run processing to continuous operations. Task Center can turn the one-off chain above into:

Automatic execution every hour / day / week
Results sent to the group on schedule
Outputs persisted for weekly review

Advanced: You can further abstract this chain into a Workflow, allowing Rex to turn "fetch alerts -> persist -> delegate triage -> send out" into an editable, testable, versioned playbook. See Workflow.

Boundaries and FAQ

Question	Handling
Want Flocks to replace NDR / TDP for real-time detection	Not recommended. Flocks is suited to in-depth analysis after an initial security signal is detected; it is not a real-time traffic-layer engine
Extremely large alert volume, tens of thousands per hour	Batch processing: design the workflow to slice by time window and alert type
Model hallucinations make conclusions untrusted	In the Skill / Agent system prompt, explicitly require "evidence fields must be listed" and refuse to answer when evidence is absent
Multi-group push sends to the wrong group	Explicitly specify `Session ID`; look up the target ID in WeCom Integration
Alert source only has web pages and no API	Use the browser tool approach. See Browser Automation and Web Login

3.3 Messaging & Alerting Integrations

4.7 Workflow

4.8 Devices

5.3 Alert Denoising

5.4 Alert Triage