Hal can watch everything and break nothing

The specific thing this prevents

In July 2024 a faulty CrowdStrike kernel-driver update crashed an estimated 8.5 million Windows machines worldwide. Flights were grounded. Hospitals stopped. The mechanism was not a security failure: it was a content update to software running in ring 0, where a fault takes the machine with it.

Every MSP that had deployed it spent the next several days doing manual recovery on every affected endpoint, client by client.

Why that can’t happen here

Everything Hal puts on an endpoint runs in userspace: the log shipper, and the installer that keeps it current. Neither has a kernel driver, so neither can fault in ring 0 and take the machine down with it the way the 2024 update did. A bad collector build stops log collection, which raises a silence flag, because Hal watches for sources that go quiet.

That is not a promise about our release process. It is a consequence of where the software runs, and it does not depend on us being careful.

What you are actually accepting when you deploy this

You are granting read access to your clients’ audit logs and directory, and optionally running a log forwarder on Windows endpoints, with the installer that updates it when you or your RMM run it. That is the entire footprint. There is no kernel component and no command channel, and nothing reaches an endpoint until you or your RMM run the installer.

Three qualifiers, because they are the things a careful reader will find in the documentation, and we would rather say them here.

Hal writes to a client’s Microsoft tenant in five ways and no others. Four are steps on the app registration he creates with Hal-assisted onboarding: creating it, and later repairing, resetting or rotating it. Each happens under your own admin sign-in, with delegated Microsoft Graph scopes that can write, and that write access is used for the one step and never stored. What setup creates is the read-only collector that does the actual work, and between those steps its credential is all Hal holds. You can also build the registration yourself and paste its credential on Settings, and then Hal creates nothing in the tenant: the registration is yours, and so is giving it a new secret, which you paste the same way. The fifth is the collector’s own, on either path: Microsoft serves a tenant’s audit log only while its audit-log subscription is on, so Hal turns it on at first connect, and again whenever he finds it stopped, a change Microsoft lets the read-only credential make. The manual setup guide is the reference for exactly what Hal creates, and the steps for building it yourself.

Google’s Alert Center has a single scope, and it permits changing alerts as well as reading them. Hal holds it to read Google’s own security alerts, and he only reads with it: he never deletes or restores an alert, leaves feedback on one, or changes Alert Center’s settings, and he never writes to a Workspace. Every other scope he holds there is read-only, and the privacy policy lists them all.

If you connect Zendesk, Hal writes to it: an internal note on your own tickets, visible to your agents and never to the requester, when a ticket leads to a report or an agent asks him a question on one. He does it as a Contributor user you create, a role Zendesk itself limits to private comments, so he cannot create a ticket, reply publicly or change a field even by mistake. Zendesk is your helpdesk, not a client environment, and nothing Hal does there reaches a client.

Almost every other security tool you deploy across your fleet asks for more than that.