AI security & operations for MSPs

Built for MSPs from day one

Microsoft and Google each raise alerts inside their own tenants. Hal brings every client’s signals, and the raw events behind them, into one place, isolated per client and kept for a year.

Why most MSPs run without a SIEM

The SIEMs on the market were built for an enterprise with a security team to run them: priced by the gigabyte, weeks to stand up, and a console that assumes one organisation. So most MSPs have never had one. Until recently that was fine. It is not any more: cyber-insurance carriers now ask what you collect, how long you keep it, and whether you can prove it, for every client you cover. What the SIEM keeps, and for how long →

One place instead of a login per tenant

Microsoft and Google each raise their own security alerts and risk signals, and they raise them inside the tenant they belong to. For an MSP that means one console per client, checked in turn, with nothing joined across clients or across sources, and nothing kept past the vendor’s window.

Hal ingests those signals, and the raw events behind them, from every client’s tenants into one instance. One portal shows every client’s source health, open alerts and this month’s cost. One search crosses clients, so the same compromised sender turning up in three tenants is a pattern rather than three tickets. The events are held for a year, and every escalation is written up against the client it belongs to, under an identifier that survives a rename. Each client’s logs stay walled off from the next, on an instance that is yours alone.

Isolation
Every client gets a permanent identifier that everything else keys on, and one client’s logs stay walled off from the next.
Instance
A dedicated instance per customer. Your data never touches another customer’s infrastructure.
One portal
Every client’s alerts, source health and reports in one place, instead of signing in to each client’s Microsoft and Google consoles in turn.
Pricing
Per identity: predictable, with no surprise per-event bill when one client has a noisy day. Pricing →
Onboarding
Measured in hours, not a six-week services engagement. Getting started →
Reports
Hal writes the analyst summary and the fix as specific steps, clear enough for a junior help-desk technician to carry out. If you want the client to see it, the same report is a signed PDF you can hand over.
The Hal portal platform status view: every connected source reporting on schedule, and the silenced sources listed across eleven client prefixes in one place
Every client’s feeds, in one view. Which sources are reporting, and which are deliberately silenced, across the whole book rather than one tenant at a time.
The Hal portal clients list: fourteen clients with their short code and display name, how many tenants each has authorized, how many sources are delivering events, how many domains route to it, and a client UID per row
Fourteen clients, one list, and a permanent ID on every row. Every tenant, source, note and report keys on that ID rather than the name, so you can rename a client, or its short code, and nothing underneath moves.

Questions this raises

Microsoft and Google already alert us. What does Hal add?

Their alerts live inside each client’s tenant, one console per client, kept only as long as the vendor keeps them, and joined to nothing outside that tenant. Hal takes those signals and the raw events behind them from every client into one instance, keeps them for a year, reads them alongside the client’s endpoints, network devices and EDR, and writes the escalation up with the fix. You look in one place, not eighty.

Why does every client have an ID as well as a name?

So you can rename one. Clients get acquired, rebrand, or start out as a short code typed in a hurry. Every tenant, source, note and report in Hal keys on the permanent ID, never the name, so a rename is a label change and nothing underneath breaks.

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.