Alert triage is not alert scoring. ARIA runs enrichment queries before AI sees the event, requires the model to cite its evidence sources in the verdict, verifies that verdict with a second model, and checks that the evidence base is complete before closing anything automatically.
The most common AI triage approach in security tools is alert scoring: a model receives an alert and outputs a score. High score → investigate. Low score → close. The approach is operationally simple but has a structural problem: the score is only as good as the model's training data. An alert type the model has not seen reliably, an unusual combination of fields, an emerging technique not yet in the training set — all of these produce scores that may not reflect the actual risk.
ARIA's triage approach is different. Rather than scoring, it investigates: gathering evidence from external sources, reasoning over that evidence explicitly, and producing a verdict where each stated conclusion is grounded in specific data. The distinction is not just architectural — it changes what you can do with the output. A score is opaque. A cited verdict can be reviewed, challenged, and audited.
Before enrichment or AI triage, the alert is checked against a set of deterministic bypass rules. These rules match on specific Wazuh rule ID and process signature combinations that have been confirmed as reliably benign in context. If the alert matches a bypass rule, it closes immediately with the rule match recorded in the trace. No enrichment, no AI.
Bypass rules are narrow. They cover known false positive patterns — specific software installers, scheduled tasks from named applications, process parent chains that fire a Wazuh rule but represent legitimate behavior in this environment. They are reviewed before deployment and do not use probabilistic reasoning.
Alerts that pass the bypass check enter the enrichment stage. Enrichment is deterministic: structured queries to specific sources, with structured outputs. The stage does not use AI.
What enrichment collects depends on the alert type. For alerts with IP indicators: threat intelligence lookups against OTX, CISA KEV, and other configured feeds. For all alerts: alert history for the involved entity — what has this endpoint or user account generated in recent history. For cloud events (Microsoft 365, Google Workspace): identity context including MFA status, assigned roles, and recent login events.
Every query result — including failures and empty responses — is recorded in the enrichment log. The triage model will see not just what enrichment found but what it tried to find and could not. Absent evidence is not the same as no relevant information.
The LLM receives the enriched alert package and produces a structured verdict. The verdict format enforces citation: each factual claim must reference the specific enrichment result that supports it. A claim about an IP's reputation must cite the threat intel lookup output. A claim about the user's recent activity must cite the alert history query result. Claims without citations do not pass validation and trigger a fallback path.
The verdict also carries a confidence level and a disposition recommendation: benign, investigate, or escalate. The confidence level is calibrated to the evidence: an alert with strong corroborating signals in multiple enrichment sources warrants high confidence. An alert with a single weak signal and no corroboration warrants low confidence. Low-confidence verdicts do not auto-close.
The triage verdict goes to a second LLM from a different vendor. The verifier checks whether citations match their sources, whether confidence is consistent with the evidence, and whether any required enrichment was not consulted. If the verifier identifies a gap, the verdict is disputed and the alert routes to a security engineer regardless of the triage conclusion.
The verifier runs even for high-confidence, clearly benign verdicts. The verification step is not optional for well-scoring alerts — it applies universally. This is the property that prevents systematic model failures from producing a batch of incorrect auto-closes: the second model checks the work on every alert.
Before auto-close is permitted, the sufficiency check runs: were all required enrichment sources successfully queried, and did the verdict's claims actually rely on their outputs? If a required source failed and the verdict depends on its data, auto-close is blocked. The alert routes to a security engineer with the enrichment failure noted.
Routing after the sufficiency check: benign verdict with no verifier dispute and complete evidence → auto-close with full trace preserved. Uncertain verdict, verifier dispute, or insufficient evidence → engineer queue with full context. High-confidence threat → immediate escalation with full evidence package.
Every alert exits the pipeline with a complete trace: the original Wazuh event, enrichment results, triage verdict with citations, verifier assessment, sufficiency check outcome, and routing decision. The trace is the record of how the alert was handled.
What every auto-closed Wazuh alert has on record:
Book a free assessment to see how the pipeline handles your actual alert environment.
Book Free Assessment