ARIA's triage engine cuts through the noise, enriches every alert with OSINT context and behavioral history, and delivers a confidence-scored verdict with reasoning — not a raw alert dump.
Enterprise SIEMs generate thousands of alerts daily. The overwhelming majority are noise — known-benign Windows processes, routine software update activity, expected user behavior that trips a broad rule. SOC analysts burn out fast working through raw alert queues that are 95% false positives.
SMBs without full-time analysts have no chance of staying on top of raw event streams. A single Wazuh deployment generates thousands of events per day across a modest endpoint fleet. Without a triage layer that separates signal from noise, monitoring is theater — the alerts exist, but nobody can act on them.
The IBM 2023 Cost of a Data Breach report found that organizations using AI in security see 108 days faster breach containment. AI triage isn't about replacing analysts — it's about letting analysts focus where human judgment adds value, and automating the classification work that doesn't require it.
Every alert from the Wazuh monitoring layer passes through a five-stage pipeline before it reaches a human.
Raw Wazuh alert arrives with agent context (hostname, IP, OS), rule ID, severity score, and the raw event log that triggered the rule. This is the starting point — unfiltered, unanalyzed.
Before any AI call, the alert runs through deterministic bypass rules — a curated list of known-benign patterns: specific Windows Update installers by PID signature, background task host processes with verified signatures, scheduled maintenance tasks with known behavioral fingerprints. Matching alerts close instantly. Zero AI calls, zero cost, zero analyst time. This gate handles the systematic false positive classes that would otherwise flood the pipeline.
For alerts that pass the bypass gate, ARIA assembles a full context bundle. A neighbor pull queries the Wazuh indexer for all events from the same agent within ±1 hour — giving temporal context that a standalone alert never has. OSINT enrichment runs in parallel: CISA Known Exploited Vulnerabilities (KEV) check, AlienVault OTX threat intel correlation, VirusTotal hash lookup for process hashes, AbuseIPDB scoring for external IPs. Google Workspace alerts get an oauth_client_id lookup against the token table to identify the application behind the grant. All results merge into a structured context bundle.
The context bundle goes to Claude Haiku for standard-severity alerts and Claude Sonnet for high and critical severity. Groq Llama 70B is the fallback model if the primary AI tier is unavailable, ensuring the pipeline never stalls. The model receives the full context bundle — alert details, neighbor events, OSINT results, agent history — and returns a structured verdict: benign, suspicious, or malicious. The output includes a reasoning narrative explaining the conclusion and a list of specific claims that the downstream verifier will check.
A separate verifier model — from a different AI family than the one that triaged — reviews the verdict. Cross-family verification is a hard rule: if Claude triaged, Groq verifies. This prevents systematic errors from one model's blind spots propagating through the pipeline. The sufficiency gate checks first: did the neighbor pull return enough log context to support the verdict? Alerts with thin evidence are held for re-check rather than closed on weak grounds. After sufficiency confirmation, the gate routes to: close (benign confirmed), escalate to human analyst (suspicious or malicious), or hold pending additional context.
The division of labor is explicit and deliberate. Automation handles the high-volume, low-judgment work. Humans handle the consequential decisions.
The goal is zero alert fatigue for the client. Analysts see only verified, contextualized incidents with a reasoning narrative — not a queue of raw events to investigate from scratch.
These are operational metrics from ARIA's production pipeline, evaluated against an internally labeled gold set. They are not independently audited figures.
The 90% accuracy figure reflects performance against ARIA's labeled gold set — a curated collection of real alerts with ground-truth verdicts. All seven false negatives identified during gold-set evaluation corresponded to bugs that were subsequently fixed before the evaluation concluded.
Book a free 30-minute assessment. We'll walk through the triage pipeline with real alert examples from environments like yours.
Book Free Assessment View PricingThe cross-family verifier catches AI errors at step five of the pipeline. If the verifier disagrees with the primary verdict, the alert escalates to a human analyst rather than closing automatically. The pipeline is fail-open: when uncertain, escalate rather than close. Human analysts review all escalations before any notification or action reaches the client. A false negative that passes all automated checks would still require a real behavioral indicator to trigger a Wazuh alert in the first place — the monitoring layer is the first line of defense.
No. Cross-family verification is a hard architectural rule. If Claude triages an alert, Groq verifies it. If the primary model tier is unavailable and Groq handles triage, a different verification path applies. The goal is to prevent systematic errors from one model's blind spots — things a particular model consistently misclassifies — from propagating through both the triage and verification stages. Two different model families with different training approaches provide independent judgment.
Yes. Every verdict includes a reasoning narrative and the specific events that drove the conclusion. The SOC board shows the full trace: which alert triggered triage, what neighbor events were pulled, what OSINT results came back, what the primary model concluded and why, what the verifier found, and how the final routing decision was made. You can inspect the complete decision chain for any alert.
Systematic false positives — alert classes that are reliably benign — are handled by the bypass gate at step two of the pipeline. When a new false positive class is identified, it's analyzed to determine whether it fits a deterministic pattern (specific process, specific signature, specific parent-child relationship) and converted into a bypass rule. The bypass gate currently handles known Windows Update installer patterns and background task host processes with verified signatures. Novel false positives that don't fit existing bypass rules escalate to a human analyst, who can initiate a bypass rule creation request after reviewing the pattern.
No. ARIA uses AI model APIs as inference endpoints only. The raw alert data, enriched context bundles, and verdicts generated by the pipeline are stored in ARIA's own infrastructure for operational purposes (audit trail, reporting, gold-set refinement). Client telemetry is never sent to AI providers for model training. API usage follows the data processing terms of Claude and Groq's commercial API agreements, which prohibit use of API input/output for training without explicit consent.