For agencies & MSPs

One control plane for
every client.

When you operate agents on behalf of multiple clients, the questions are always the same: can one client's run see another's? Whose key is this? What did the agent actually do? P1 Halo answers all three with one governance plane — per-client isolated sandboxes, a BYOK vault per client, and a signed audit trail each client can re-verify themselves.

Per-client sandboxes can't read each other A key vault per client One signed chain per client Re-verify offline
What every client gets

One plane. Every client governed.

The isolation, key custody, and evidence live at the platform layer — so you can take on the next client without taking on the next liability.

Per-client isolation

Each client's agents run in their own no-route sandbox, scoped so one client's run can't read another's files or keys. Isolation is enforced per tenant, not left to convention.

PER-TENANT · NO EGRESS

One governance plane

Hold a separate BYOK key for each client in a libsodium-encrypted vault. The sole-egress broker injects the right client's key at call time — it never enters the container, and every call is policy-checked.

BYOK VAULT · KEY PER CLIENT

Signed evidence per client

Every client gets their own Ed25519-signed, hash-chained audit trail. Hand them the export — they can re-verify every action offline, on their own machine. No "trust us," just proof.

TAMPER-EVIDENT · RE-VERIFY OFFLINE
Onboarding a client

A new client is a new isolated tenant.

Each client you take on stands up as its own tenant — its own sandbox boundary, its own key, its own chain. Not a shared workspace with labels; a separate isolation boundary.

01

Stand up the client's tenant OWN BOUNDARY

Create a tenant for the client and their runs execute in their own no-route sandbox. Data access is scoped to that tenant and fails closed — a cross-client request returns "not found", so one engagement can't even enumerate another's work.

02

Load that client's key BYOK · PER CLIENT

Hold each client's provider key in the libsodium-encrypted vault under their tenant. The sole-egress broker injects the right client's key at call time — it never enters a container, and a run for client A can't reach client B's key. Clients pay their own provider; you never mark up tokens.

03

Run agents under governance POLICY-CHECKED

Every model call is policy-checked at the broker — known model, budget cap, kill switch — per client. A runaway run on one engagement hits that client's budget cap and can be killed host-side, without touching anyone else's work.

04

Hand over the signed chain RE-VERIFY OFFLINE

When the client asks what an agent did on their behalf, export their tenant's Ed25519-signed chain. They re-verify every action offline on their own machine — your deliverable is proof they can check, not a status report they have to believe.

Your clients don’t have to trust your word for what an agent did on their behalf — they can verify it. One plane keeps every client’s runs isolated, every key vaulted, and every action signed into a chain they re-run offline themselves.
— Governance across your whole book of clients
The agency questions

What a client's security lead asks you first.

The three questions every client raises when an outside firm runs AI on their data — answered the way you'll want to answer them.

“Can another client of yours see our data?”

No. Each client is its own isolated tenant. Runs execute in a no-route sandbox scoped to that tenant, and data access fails closed across tenants — a request from one client's context can't read another's files or keys, and gets "not found" rather than a hint that anything exists. Isolation is enforced per tenant, not by you remembering to keep things in separate folders.

“Whose API key is being used, and can it leak?”

Each client's own provider key, held in a libsodium-encrypted vault under their tenant. The sole-egress broker injects it for exactly the call that needs it — it never enters the agent container, so there's nothing inside the workload to exfiltrate. One client's key is never reachable from another client's run, and you never mark up their token spend.

“How do we know what your agents actually did?”

You hand them their tenant's signed audit chain. Every prompt, tool call, output, routing decision, and kill is Ed25519-signed and hash-chained, and they re-verify it offline with a standalone tool — no connection to you or to us. It turns "we ran some agents for you" into evidence the client holds and can check independently. Note: each client is its own isolated tenant; we don't auto-provision nested sub-tenants under a client.

Govern every client
from one plane.

Stand up isolated sandboxes per client, and hand each one a signed audit trail they can re-verify offline. BYOK — you only ever pay your provider for tokens. Solo $29 · Team $544 · Business $1,779.