Detection Pipeline

Every minute, your tenants generate far more log activity than any team could read. Most of it is routine. The job of the detection pipeline is to find the handful of events that actually matter and to hand them to you as a conclusion, not as one more alert to triage.

Hal does this in layers. Cheap, deterministic checks run first and clear out the overwhelming majority of the noise. The expensive reasoning runs only on what’s left. By the time something reaches you, it has passed two independent judgments and been written up with the affected scope and the recommended fix.

Why layering

A single large model reading every event would be slow and expensive. So the pipeline is ordered cheapest-first: most of the noise is cleared before any model runs, and each stage hands a smaller pile to the next. The costly investigation only ever sees events that earlier stages couldn’t dismiss.

The order matters: a deterministic rule that costs nothing should never sit behind a model that costs money.

Enrichment before triage

Before an event reaches the pipeline, Hal checks every IP address in it against known-bad threat-intelligence feeds and tags it. This happens at ingestion, so the tag travels with the event everywhere it goes: into storage, into searches, and into every later stage of triage.

The tag does real work. A login that would normally be dismissed as routine is treated very differently when the address it came from is a known-bad source.

The pipeline, stage by stage

Two deterministic filters clear the noise first, then three AI tiers do the reasoning, the fast pass, the second-opinion gate, and the investigation.

Blacklist (deterministic)

A set of rules drops the obvious routine traffic: service-account chatter, expected sync activity, ordinary page views, and similar known-benign patterns. No model is involved, so it costs nothing.

The blacklist is deliberately conservative: it only suppresses what is genuinely safe to ignore. Suppression also only affects what reaches AI triage; the raw events are still stored and remain searchable.

Sigma rules (deterministic)

What survives the blacklist is checked against a curated set of community detection rules (Sigma), about 600 of them, covering known attack patterns across Microsoft 365, Google Workspace, Microsoft Entra, and Windows servers. These are deterministic pattern matches: a rule either fires or it doesn’t. When one fires, the event carries that context forward so the next stage knows the community considers the pattern significant.

Deterministic escalations (the other direction)

Not all of the deterministic work filters noise out. A few signals are treated as serious on their face and travel the opposite way: they skip the filters and the fast pass and go straight to the second opinion and, if it holds, investigation:

• The vendor’s own security engine flagged it, a Microsoft or Google risk signal, like a risky sign-in or an account disabled for spamming.
• A successful sign-in from a high-risk country that this customer base has no legitimate sign-in pattern from.
• A risky OAuth consent, a user granting a third-party app access to sensitive scopes such as mail, files, or admin.

When one of them genuinely is expected in a client’s environment, the answer is a client note or approved exemption that states the fact, not a suppression.

Tier 1, Fast triage (Claude Haiku)

Now a model enters the picture, but the cheapest one. Hal’s fast model looks at each batch of activity and makes a single call: benign, or worth a closer look. This runs constantly across every client. Each call is cheap; how often the loop runs is what decides the daily total, and that cadence is a setting you control, see Controlling AI spend.

Most of what reaches this stage is dismissed here. Only the genuinely questionable activity moves on.

Tier 2, Second-opinion gate (Claude Sonnet)

Anything the fast model wants to escalate doesn’t go straight to a full investigation. It first passes through a second, more capable model that takes a fresh, independent look, to catch the fast model’s false positives before the expensive step. Only when both models independently agree that something warrants investigation does it proceed.

This is the heart of why a Hal escalation is trustworthy. Two separate judgments have to line up before any deep work begins.

Tier 3, Agentic investigation (the model you choose)

Finally, the investigation model runs. Tier 1 and Tier 2 are fixed; this one is yours to choose under Settings → General → AI Models: Sonnet, Opus or Fable, with Opus the default (see Controlling AI spend). Unlike the earlier stages, this one has tools: it searches your logs, pulls related events, aggregates across time, and follows the thread until it can describe what happened. The output is a structured report with a severity, the affected identity or scope, and specific remediation steps.

That report is what lands in your portal, and, for high-severity findings, in your email. It is a conclusion you can act on, not an alert you have to chase down.

If Anthropic declines the investigation on the model you chose, a backup model completes it where there is one, and the report says which model did. If every model declines, nothing unrated is filed as low: the report is marked UNASSESSED, emailed whatever your threshold, and left for a person to review. What an UNASSESSED report contains →

Watches

After the tiers, each cycle checks any watches that are due: the post-incident searches you opened in chat for a named account or pattern. A hit files a report through the same path as a Tier 3 escalation, so it reaches the Events page and your email like any other alert.

Sentry

Alongside the tiers, a person under sentry has every event that names them read each cycle against what is known about them. An escalation takes the same second opinion and investigation as any other alert, and the report says which read raised it.

Signed reports

Every report Hal produces is cryptographically signed so a recipient can confirm it’s genuine and unaltered. See Report Verification.

Tuning

The pipeline is configurable per deployment. Stages can be made stricter or more permissive, and individual sources can be muted from the portal when a tenant is undergoing planned work, without losing the underlying log history.

For the product-level overview, see AI SOC. For a step-by-step walkthrough of a single escalation, see How triage works.