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 ruinously expensive. So the pipeline is ordered cheapest-first. Between 60% and 80% of incoming noise is filtered out before any model runs at all, 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. Threat-flagged events bypass the noise filters and are pushed toward escalation rather than away from it.

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 static, hand-maintained rules drops the obvious routine traffic: service-account chatter, expected sync activity, ordinary page views, and similar known-benign patterns. This runs in plain code with no external calls and no model, so it costs nothing and is the single biggest reduction in volume.

The blacklist is deliberately conservative. It only suppresses things that are genuinely safe to ignore, and it never hides indicators of data movement such as downloads or file access. 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.

Tier 1 — Fast triage (Claude Haiku)

Now a model enters the picture, but the cheapest one. Hal’s fast model reads a condensed summary of each batch of activity, not the raw events, and makes a single binary call: benign, or worth a closer look. It also sees recent escalation history so it doesn’t keep flagging the same known-good pattern twice. This runs constantly across every client and costs very little per day.

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. This gate exists to catch the fast model’s false positives before they cost anything: if the second opinion disagrees, the item is dropped. 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 (Claude Opus)

Finally, the most capable model investigates. 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.

How an event becomes a conclusion

1. The event is ingested and its IP is checked against threat-intel feeds, then tagged.
2. The blacklist drops it if it matches a known-benign pattern. Most noise stops here.
3. Sigma rules annotate it if it matches a known attack pattern.
4. The fast model reads a summary and decides: benign or worth a look.
5. The second-opinion model independently re-checks anything flagged. Disagreement drops it.
6. When both agree, the investigation model digs in and writes a signed report.

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.