Security & Compliance

Hal is built so he can watch everything and break nothing. He reads your clients’ environments, judges what he finds, and tells you what to do; he never makes the change himself. That isn’t a setting you trust him to honor. It’s how the system is built.

Read-only by architecture

Cloud sources are read through their own APIs over connections you grant and can revoke yourself, and no software is installed in a tenant. Every credential Hal keeps into a client’s systems is read-only, except Google’s Alert Center scope, which Google offers only in a form that can also change alerts; Hal only reads with it. In Microsoft 365, when Hal creates his app registration, the write access that creates it, and later repairs, resets or rotates it, is your own admin’s sign-in, used for the step at hand and never stored; when you build the registration yourself and paste its credential, Hal creates nothing in the tenant. The collector’s read-only credential makes one change of its own: it turns on the tenant’s audit-log subscription, which Microsoft needs on before it serves the log.

On a Windows endpoint Hal puts a userspace log shipper (a Fluent Bit forwarder) that ships logs out, and the installer that keeps it current. Neither is an EDR or carries a kernel driver, and the forwarder has no command channel. The installer updates it only when you or your RMM run it, with a build from your own instance that it checks before running, as Windows Endpoints describes.

Beyond those Microsoft writes, Hal writes only to your own systems, such as his messages in Slack, his alerts in Microsoft Teams and, if you connect Zendesk, internal notes on your tickets. Because nothing Hal deploys runs in the kernel, the mechanism behind the CrowdStrike outage does not exist here. The full story, with the customer-facing framing, is on Read-only architecture.

Per-client isolation

Each client’s logs are kept separate on the instance. One client’s logs never commingle with another’s there, and every client is keyed by a permanent identifier rather than its name, so a rename changes nothing underneath. An MSP running dozens of clients through Hal gets dozens of isolated stores, not one shared pool.

Retention and deletion

Ingested log data is searchable for 365 days. When a contract ends, HAL AI deletes the customer’s instance and the data on it. HAL AI’s operational records, what the instance reports about its operation and the records of HAL AI’s own work on the service, may keep excerpts of it for as long as HAL AI needs them to run, support, secure and improve the service. Even while the data lives in Hal, your own Microsoft 365, Google Workspace, and other source systems stay the system of record, Hal’s copy is a searchable cache with a retention window, not your archive.

Signed, verifiable reports

Every PDF Hal generates is cryptographically signed. You, your client, or an outside auditor can confirm a report is genuine and unaltered without taking our word for it. Drop the file at Verify a report: the check runs entirely in your browser, and a modified or forged report fails it. For the steps, see Report Verification.

Audit logging

Hal keeps every report he writes, numbered and dated, with the severity, the model that judged it and its reasoning, for the life of the deployment. Every triage cycle is recorded for 90 days. Those records hold what happened, when, and against which client, rather than a copy of the raw log data. For what’s recorded and how long it is kept, see Audit logging.