AI security & operations for MSPs

02 AI SOC

Every alert ships with a remediation report

Hal isn’t a noise machine. When something fires you get the analyst summary, the identity it affected and the specific remediation steps, not a raw log line and a severity guess.

Why the second opinion is the whole design

The failure mode of AI security tooling is confident nonsense delivered at volume. The fix is not a better prompt, it is structure: run the cheap deterministic layer first, use small models to discard what obviously does not matter, and require two independent judgments before anything claims your attention.

That is why the thing that lands in your inbox is a conclusion rather than an alert to triage. It has already survived the review a tier-one analyst would have given it.

What the remediation actually looks like

Not “investigate suspicious sign-in.” The affected identity, what happened, what it means for that specific client, and the steps in the order you would take them. Written so a tech can act on it, and written so the client can read it if you forward it.

In every alert
Severity, the affected identity, the source events behind it, and the exact remediation steps.
Coverage
24×7, across every connected tenant. No SOC analyst to hire and no follow-the-sun rota to staff.
Sentry
Put a client’s higher-risk people, executives, finance staff, administrators, under a standing read: every event that names them, every cycle. Sentry →
What stops at tier two
Is still recorded and still searchable. Suppressed is not discarded, so a pattern nobody escalated is still there when someone goes looking six months later.
Deterministic first
Sigma rules run before any model does, so the cheap and repeatable layer catches what it can and no model is asked a question a rule already answered.
Signed reports
Written for your team to act on, and signed so a client or their auditor can verify one when you need to show your work. Verify a report →
Tuning
Silence and threshold controls per source and per client. Noise tuning →

How an event becomes a conclusion

01 Collection every few minutes Cloud APIs and shipped endpoint logs land in the client's isolated store.
02 Sigma detection rules Deterministic rules fire first. Cheap, explainable, and the same every time.
03 Tier 1 triage Haiku One cheap pass over the summary. Most of what fires stops here and is logged, not sent.
04 Second-opinion gate Sonnet An investigation opens only if a second, independent model agrees, or the gate cannot answer.
05 Investigation and conclusion Opus by default, your choice in Settings Hal works the evidence with tools and writes the report: severity, affected identity, and the remediation steps, sized to how sure he is.

Every stage is recorded: the disposition each cycle reached, the reasoning, and the model that wrote the report. Stage-by-stage detail, including how the second-opinion gate works, is in the Detection Pipeline reference.

A morning check-in in the Hal portal: 38 alerts investigated overnight across 14 clients, 36 auto-resolved as known-benign, two worth a look and neither critical, zero escalations
What a night of tier-one work looks like by morning. 38 alerts across 14 clients, 36 closed as known-benign against documented context, two summarized, none needing anyone at 3am.

Questions this raises

How is this different from an MDR service?

An MDR is people plus a platform, and you pay for the people: a provider’s price tracks the analysts it employs, shared across every customer it has. Hal is the platform doing the tier-one and tier-two work, priced per identity. And the escalation goes to your team, who already know the client, rather than to a stranger reading a runbook.

So he replaces my analysts?

He replaces the part of the job that is reading and dismissing alerts, which is most of the hours and none of the value. Judgment calls, client relationships and the actual remediation stay with your team. Hal hands them a conclusion instead of a queue.

What if he escalates something that turns out to be nothing?

You will see exactly why: which rule fired, which model judged it, on what evidence, and what it concluded. That is what makes it tunable. A false positive you can read is a tuning input; a false positive you cannot read is just noise.

Does he act on his own?

No. Hal never changes anything in a client environment to act on a finding. He tells you what to do; the doing stays with you.

See what Hal surfaces on your own clients.

No deck. Ask us anything first. When you want to see Hal on your own tenants, we sign a short evaluation agreement and stand up your instance; you connect one tenant, Hal watches it for 14 days, and we walk you through what he found.

  1. 01You ask us your questions. No deck, no demo dataset.
  2. 02You sign a short evaluation agreement, and we stand up your own instance.
  3. 03You connect one tenant from your own admin console. Hal watches it for 14 days.
  4. 04We walk through what he found. Keep going month to month, or revoke the scopes yourself and stop.