AI security & operations for MSPs

1Password

A password manager is where every other credential lives. Hal reads who signed in to it, who revealed or exported a secret, and what changed in the account, and judges each next to the same person’s sign-ins elsewhere.

The vault’s sign-in log is the one that matters most

A password manager holds every other credential a client has, so who signed in to it, and who failed to, is the one log that says whether the keys were touched. Hal reads it the way he reads Entra’s sign-ins, with one difference 1Password makes possible: an MFA failure there means the account password and the Secret Key were both right and only the second factor was not, which deserves a closer look than a wrong password. A failure that turns into a success from the same address, a vault exported, an item shared outside the account: each lands in that client’s triage beside the same person’s Microsoft or Google sign-ins from the same window.

Your own technicians, on the record

Your own 1Password account is read the same way, as a client of your Hal. Every technician sign-in, every launch into a managed company, every reveal or export from a shared vault is on the record and read with the same eye as any client’s activity. An admin sign-in on a client’s server and, a minute earlier, a technician revealing an item from that client’s vault now read as one story rather than two. When a client asks who was in their vault and when, the answer is already in the record, searchable for a year like every other source.

What Hal reads
Three feeds from each 1Password account: sign-in attempts (success, credentials failed, MFA failed, firewall blocked, with the exact reason, app and location), item usages in shared vaults (fill, reveal, copy, edit, export, share, by vault and item), and audit events (recoveries, password and Secret Key changes, MFA and device changes, vault exports and shares, service-account tokens, access grants, and launches into managed companies).
What it enables
A credential failure that turns into a success, an MFA failure where the password was right, a vault export, an external share, a recovery or an MFA change land in Hal’s triage with the same person’s Microsoft or Google sign-ins beside them. Your own company’s account is read the same way: your technicians’ sign-ins and their launches into each client’s vault are the accountability trail.
How it connects
An Events Reporting token you issue in each account (Integrations → Events Reporting), one per managed company and one for your own. It reads events and can read no secret and change nothing. Read-only by architecture →
Setup
Console steps and the hand-off to Hal: in the docs →

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 read-only, 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 grant read-only scopes on one tenant in 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.