ARIA's AI analyst does not score alerts. It investigates them: gathering evidence from multiple sources, producing a verdict where each claim cites its source, and routing the result through independent verification before any automated action.
The most common failure mode in AI triage systems is asking the model to do two things at once: gather evidence and reason about it. When a model is given a raw alert and asked "is this a threat?", it is guessing based on what it has seen in training — not investigating based on actual evidence from this environment. ARIA separates these steps.
When an alert arrives, a deterministic enrichment pipeline runs first. This is not AI — it is a sequence of structured queries with specific outputs. The MITRE ATT&CK technique is taken directly from the Wazuh sensor's tag, not inferred. Threat intelligence lookups run against OTX, CISA KEV, and other configured feeds, and return specific results: whether the indicator appears, with what confidence and context. Alert history for the involved entity — recent events, similar patterns — is pulled from the alert database. For cloud alerts, identity context is collected: the user's MFA status, assigned roles, and recent login history.
Only when this enrichment is complete does the alert move to the AI triage stage. The model receives not just the raw alert but the full enrichment package — which changes what the model can say and what it can be held to.
The triage LLM receives the enriched alert and produces a structured verdict. The structure has a specific requirement: each factual claim in the verdict must cite the enrichment source that supports it. If the verdict states that an IP address has a known malicious reputation, that claim must be grounded in the threat intel lookup result — not inferred from training data about that IP.
This citation requirement serves two purposes. First, it makes the verdict verifiable: a human reviewing the alert can trace each claim to its source. Second, it constrains what the model can say: claims that would require the model to invent evidence are structurally disallowed. A verdict that tries to claim "this pattern is typical of ransomware staging" without a supporting enrichment result does not pass validation.
The structured output also captures uncertainty explicitly. When the evidence is genuinely ambiguous — an indicator that appears in threat intel at low confidence, a behavioral anomaly with no corroborating signals — the verdict records this and the confidence level drops accordingly. Low-confidence verdicts go to a security engineer rather than auto-closing.
The triage verdict goes to a second LLM from a different vendor. This model's task is adversarial: find reasons the verdict is wrong. The verifier checks whether cited evidence actually supports the claims made, whether required evidence was gathered, and whether the verdict's confidence level is consistent with what the enrichment data shows.
A verdict the verifier cannot refute passes. A verdict with a gap — a claim that exceeds its evidence, a cited result that does not say what the verdict claims it says, or a required enrichment source that failed — is flagged as disputed. Disputed verdicts go to a security engineer and are not auto-closed or surfaced to the client as resolved.
Using models from different vendors reduces correlated failure modes. If one model has a systematic blind spot for a particular class of alert — a pattern of false confidence on a specific MITRE technique, for example — the verifier from a different vendor is less likely to share that blind spot. This is not a guarantee, but it is materially better than single-model verification.
Before any alert can be auto-closed, the pipeline checks whether the required enrichment was actually collected. If a lookup failed, timed out, or returned no data, the sufficiency check blocks auto-close regardless of the triage verdict. An alert can only be closed automatically when the evidence the verdict rests on is confirmed to be present and intact.
After the sufficiency check, routing is deterministic. Alerts with benign verdicts, no verifier dispute, and complete evidence are auto-closed with the full trace preserved. Alerts where the verdict is uncertain, the evidence is borderline, or the verifier flagged a concern go to a security engineer's queue with the full enrichment package. High-confidence threat alerts escalate with immediate notification.
Every alert exits the pipeline with its full trace: enrichment results, triage verdict with citations, verifier assessment, sufficiency check outcome, and routing decision. This trace is the audit record for the alert's disposition and the starting point for any further investigation.
What the investigation trace contains:
Book a free assessment to see how the pipeline handles your actual alert environment.
Book Free Assessment