Automatic Triage
Triage is the automatic, AI-driven first pass CloudPeek runs on every new incident, no human action required. By the time an analyst opens an incident, the alert has been read, structured, enriched, scored, matched to a runbook, summarised, and given a suggested investigation plan. This page walks through exactly what happens.
From alert to analysed incident
Here's the whole journey, from a tool raising an alert to an analyst-ready incident.
Stage 1, Intake
The Incident Sync worker polls each connected alert source on its schedule and, for each new alert:
- Fetches the raw alerts from the tool.
- Normalises them into a common shape.
- Deduplicates: alerts already seen (by their dedup key) are skipped.
- Applies silencing and cooldown checks: alerts matching a silencing rule, or that match something investigated very recently (a cooldown window, by default 60 minutes), are suppressed so you don't get repeat noise.
- Creates an incident (status _Pending_) for each surviving alert and queues it for triage.
Stage 2, AI triage pipeline
The Triage worker picks up pending incidents (highest priority first) and runs each through a fixed sequence of steps. The incident moves to status _Triaging_. The AI model used is the one your tenant configured (see Model Providers), with an automatic fallback if the primary model is unavailable.
The steps:
- Normalise. The AI turns the messy, vendor-specific raw alert into structured data: basic information, indicators, a timeline, and suggested next steps.
- Validate. The structured output is checked against a strict schema. If key fields are missing, the AI is asked to correct itself (a few times) with the errors fed back in.
- Classify the mode. The incident is classified as a threat (the default) or a vulnerability, which tailors the rest of the analysis.
- Enrich (vulnerabilities). For vulnerabilities, a further step fills in blast radius (what's affected) and a patching guide (CVEs, fixed versions, remediation).
- Select a runbook. The AI looks at your runbook library (pre-filtered by tags) and may pick a relevant one to guide the investigation.
- Generate the plan. The AI produces the investigation plan: the list of follow-up actions, guided by the runbook if one was selected.
- Complete. A readable Markdown triage summary (overview, key details, plan) and a set of recommendations are assembled.
The incident moves to _Triage Complete_.
Built-in prompt-injection defence. Raw alert content is treated as untrusted: it's wrapped and escaped before being shown to the AI, and oversized alerts are rejected. This stops a malicious alert from trying to manipulate the AI's analysis.
Stage 3, What's waiting for the analyst
On success, the triage worker, in one pass, populates the incident so a human opens something already worked:
- A written triage summary and recommendations.
- Structured IOCs, a timeline, and MITRE technique mapping.
- For vulnerabilities, blast radius and a patching guide.
- A queued (and soon-to-run) investigation plan of follow-up actions.
- The incident is recorded in the cooldown cache (so identical alerts are suppressed for a while), and a memory of the summary is stored for future retrieval.
- The entities seen (IPs, hosts, users, hashes, CVEs) are queued for the Wiki auto-indexer, so your knowledge base grows.
Classification, dedup and escalation
- Classification: threat vs. vulnerability (set by the AI), plus severity/priority.
- Deduplication: at intake via a dedup key, and again via the cooldown cache that suppresses repeat triage of the same trigger.
- Escalation: triage does not escalate or take action on its own. It analyses and recommends; a human decides via Review Outcome (Close / Escalate / Reject) on the incident.
Where humans fit
Automatic triage is read-and-reason only, it never changes a system. The follow-up actions its queues are likewise restricted to read-only tools. Anything that would alter your environment happens only in an interactive investigation where a person approved it under Human-in-the-Loop.
Why it's reliable
- Incidents are processed highest-priority-first, and locked so two workers never analyse the same one.
- Failed triage is retried with backoff; if a model times out, a fallback model is tried.
- A Triage Requeue safety-net worker re-queues anything that somehow got stuck.
Tuning triage
You influence triage mainly through:
- Runbooks: better runbooks produce better, more consistent plans (see Runbooks).
- Silencing rules and cooldowns: to cut known noise (see Admin & Settings).
- The AI model your tenant uses (see Model Providers).
Related
- Follow-up Actions: how the plan gets executed.
- Incident Management: working a triaged incident.
- Background Workers: the machinery behind triage.