The integration is not a connector — it is a pipeline. Wazuh generates events; ARIA enriches them deterministically, routes them through a cited LLM triage, verifies the verdict independently, and logs the full trace before any disposition is recorded.
Wazuh stores its alert data in the Wazuh Indexer (OpenSearch-based). ARIA ingests alerts from the Indexer's API, consuming events as they arrive. The raw alert fields — rule ID, rule description, MITRE technique and tactic, agent name, timestamp, and any extracted fields from the log source — are preserved verbatim and passed to the enrichment stage without modification.
Preserving the sensor-sourced fields without modification is deliberate. ARIA's triage pipeline does not reinterpret or re-tag Wazuh's output. The MITRE technique tag that appears in the triage verdict comes from Wazuh's rule set, not from the LLM's inference about the event content. This distinction matters for auditability: a sensor-sourced tag is evidence; an AI-inferred tag is a guess.
Before any alert reaches a language model, a deterministic enrichment pipeline runs a structured set of queries. The enrichment stage does not use AI — it issues specific queries to specific sources and collects structured responses.
For alerts with an IP indicator: threat intelligence lookups run against configured feeds (OTX, CISA KEV, and others as configured). For all alerts: the alert history database is queried for recent events involving the same entity. For cloud events (Microsoft 365, Google Workspace): identity context is collected — the user's MFA status, assigned roles, and recent login history. The enrichment results are assembled into a context package alongside the original alert.
The enrichment stage records both what it found and what it could not find. If a lookup failed or timed out, that is recorded. If no alert history exists for this entity, that is recorded. The absence of information is explicit in the context package, not invisible.
The LLM receives the enriched context package and produces a structured verdict. The verdict format enforces a citation requirement: each factual claim must reference the specific enrichment result that supports it. A claim that an IP address appears in threat intelligence must cite the lookup result that shows this. A claim about a user's typical login geography must cite the identity context query result.
This is enforced structurally, not through instruction. The output schema requires citations; a verdict that makes unsupported claims does not pass schema validation and triggers a retry or fallback path. This constraint prevents the model from reasoning from training data where the enrichment data should be the ground truth.
The structured verdict also captures confidence explicitly. When the evidence is sparse — a low-confidence threat intel hit, no corroborating alert history — the confidence field reflects this, and the routing logic accounts for it. Low-confidence verdicts do not auto-close; they go to a security engineer.
The triage verdict is passed to a second LLM from a different vendor for independent verification. The verifier's task is adversarial: find reasons the verdict is wrong. It checks whether citations actually match their sources, whether the confidence level is consistent with the evidence, and whether required enrichment data is present and was consulted.
After the verification stage, the evidence-sufficiency check runs: were all required enrichment sources successfully queried? If any required source failed and the verdict depends on its output, auto-close is blocked.
The full pipeline trace — ingested alert, enrichment results, triage verdict with citations, verifier assessment, sufficiency check outcome, routing decision — is logged for every alert. This trace is the persistent record of how the alert was handled and is accessible from the alert view in the SOC dashboard.
What the integration preserves from Wazuh:
Book a free assessment to see how the pipeline handles your actual alert environment.
Book Free Assessment