"Agentic" is not a synonym for AI-powered. ARIA collects structured evidence deterministically before the AI agent runs, requires every verdict claim to cite that evidence, and verifies citations with code — not a second model guess — before any alert can be auto-closed.
Most security tools marketed as "AI-powered" apply a model to each alert independently — scoring it against a feature vector or pattern set and returning a number. That is AI applied to a security problem. An agentic system is different: it takes sequences of reasoning steps, uses tools to gather additional evidence, and adapts its investigation based on what it finds. The distinction is meaningful, not just terminological.
ARIA's pipeline is agentic in a specific sense. When an alert arrives, it does not immediately go to a language model for scoring. A deterministic enrichment stage runs first, querying multiple sources to build context: what MITRE technique the sensor tagged, whether the indicator appears in threat intelligence feeds, what this entity's recent alert history looks like, and — for cloud events — what identity context exists (MFA status, roles, recent login history). Only then does the LLM receive the alert, along with all gathered evidence.
The LLM produces a structured verdict. Crucially, each claim in the verdict must cite the specific query result that supports it — not infer from training data alone. A verdict that says "this IP appears in threat intelligence" must be supported by the threat intel lookup output in the enrichment trace. This citation requirement is enforced structurally, not by instruction alone.
A key weakness of open-ended AI investigation is that the model decides what to look for. It may overlook a question that would change the verdict, not because the data is unavailable, but because it never occurred to ask. ARIA addresses this with a pre-collection phase that runs before the investigation agent gets the alert.
For each alert family, a defined set of investigation questions is answered deterministically using batched tool calls — without the AI. For an OAuth token event, for example, this covers whether the authorizing application has been seen before for this tenant, whether the authorizing user has seen this app, whether suspicious logins occurred in the same window, and whether co-occurring alerts suggest a broader pattern. These questions are answered before the agent's first turn, and the results are handed to the agent as pre-collected evidence.
Each evidence item carries an explicit status that distinguishes between meaningfully different outcomes. Confirmed means a search returned supporting data. No data means the search ran and returned zero results — absence of evidence, not evidence of absence. Tool error means data collection failed and the question is genuinely unanswered. Policy denied means the data source is disabled by the customer's own configuration. These distinctions matter: a verdict that says "no suspicious logins were observed" is only valid when the login search ran and returned zero results — not when the search failed or was blocked.
When the investigation agent receives the alert, it already has structured answers to the most important questions. Its tool budget is spent on investigation-specific queries, not re-asking questions the pre-collection phase already answered.
After the agent produces a verdict, a deterministic code check runs before auto-close is permitted. Every factual claim in the verdict that cites a pre-collected evidence reference is checked mechanically: does the cited evidence ID exist in this investigation's evidence set? Does it belong to the same tenant? Does its status actually permit the claim being made?
A verdict that says "the app was seen before by this user" and cites a pre-collected evidence object with status no data fails the grounding check — the cited evidence contradicts the claim, it does not support it. A verdict that cites a tool error evidence object as proof of absence also fails. These failures are caught by code before any auto-close decision, with no LLM judgment involved.
This is separate from the semantic verifier, which checks whether the verdict's reasoning is logically consistent. The grounding verifier checks a more basic question: are the citations real? An alert where the grounding check fails is routed to a security engineer regardless of how confident the triage model was.
Single-model AI systems have a correlated failure mode: if the model has a blind spot, it will fail consistently on the same class of input. ARIA addresses this by routing every verdict through a second model from a different vendor for independent semantic verification. The two models do not share weights, training data, or vendor infrastructure.
The verifier is explicitly adversarial: its task is to find reasons the verdict is wrong, not to confirm it. A verdict that the verifier cannot refute passes. A verdict where the verifier identifies a gap — missing evidence, a cited fact that does not match the source, a claim that exceeds what the data shows — is flagged as disputed. Disputed verdicts are blocked from both auto-close and client notification. They go to a security engineer.
This design means the system fails conservative rather than optimistic. When the two models disagree, a human sees the alert. When required enrichment data was not available, auto-close is blocked by the evidence-sufficiency check. The system's errors tend to create more work for the engineer, not fewer escalations — which is the right tradeoff for security.
Agentic architecture does not imply autonomous action. ARIA's response capabilities are approval-gated: any action that would affect a client system — isolating a device, blocking an account, modifying a firewall rule — requires explicit sign-off from a security engineer before it executes. The agentic part of the pipeline stops at the routing decision.
This is a deliberate constraint, not a limitation of the technology. Autonomous containment actions can have operational consequences — blocking a legitimate account, isolating a production server — that are sometimes worse than the threat they respond to. Until the confidence bar for fully autonomous response is higher than current AI systems can reliably clear, requiring human approval before response is the correct architecture.
The agentic layer handles the part of security work that doesn't require operational judgment: gathering evidence, correlating context, reasoning about whether an alert represents a real threat, and routing appropriately. The human handles the part that does: deciding whether to contain, what to contain, and when.
What the agentic pipeline covers:
Book a free assessment to see how the pipeline handles your actual alert environment.
Book Free Assessment