Self-hosted deployment
Runs entirely on infrastructure you control.
Consequence AI Systems builds governance infrastructure for AI systems operating in regulated environments — starting with ARBITER, a self-hosted control layer for financial and insurance workflows.
Cloud and AI spend has become a governance problem, not just a cost problem. AI workloads are dynamic, distributed, and tied to engineering decisions made every day — after-the-fact approvals no longer keep up. Security and compliance are now the top-cited concern for organizations scaling AI.
We build for exactly that intersection: control, auditability, and cost governance for AI, enforced where it can be proven rather than promised.
Every execution ARBITER governs gets a signed certificate — proof that it was authorised. But a certificate is a receipt. Nothing requires one in order to act, so an agent that skips the policy path is not stopped by it.
The consequence boundary is the other half. For a specific effect, it is a capability the agent cannot create, cannot forge, and cannot route around.
The question is asked at a gate. Call the tool directly, bypass the application, or wait out an unavailable reviewer, and the check never runs.
There is no statement it can execute and no network path it can take. The effect is not refused — it is unexpressible. The only route consumes a capability the actor could never have minted for itself.
Enforced by database privileges and network position, not by application code. There is no code to skip, because there is no path.
A capability is not a bearer token. It is re-checked against current conditions every time it is presented. If an account freezes or a release window closes after issue, it stops working — while still being authentic.
Every presentation is recorded, admitted or refused, with its reason. That a consequence did not form is as provable as that one did.
The tool's database role holds no INSERT on the ledger, or on the table that issues capabilities. There is no SQL it can write that appends a row. Postgres enforces that regardless of application code, the same way it enforces tenant isolation.
The tool is handed the real webhook credential and still cannot send it: it sits on a network with no route off the host. Only the broker, presented with a valid capability, makes the call.
Both are proven by a harness that tries to cause the effect every way it could go wrong: no capability, one nobody signed, a changed condition, a replay, an expired capability, a request beyond its bounds — and going around the broker entirely, by writing to the ledger directly or calling the destination with the real credential. Every run ends the same way: every attempt refused but one, and exactly one consequence formed. A third harness makes the same attempts from inside ARBITER's own executor, with everything it holds, its signing key included: on 13 October 2026, 38 attempts refused and one consequence formed, through a capability. Among them, a forged approval: the executor records an approval no person gave and signs it with a passkey of its own, and no permit is issued for it, because the broker checks the signature before it issues one. A fourth makes them as root on ARBITER's own server, against the gate: on 16 October 2026, every attempt failed to make it pay, and one payment formed, the one a person approved on their phone.
Watch the proof run in a live demo →This holds against anything holding the tool's own credentials, and against someone with a shell inside ARBITER's executor, the part that reads untrusted input and calls the AI model. Handed the real credentials, it has no route to use them, and its database login can write no ledger row, permit or receipt. An approval that moves money is signed with a passkey on the approving person's own device, and the broker checks that signature before it issues any permit, so an approval the executor fakes gets none. Four limits remain, and we state them: the executor serves the page where a person approves, so it could show them one amount while their device signs another, though it cannot sign without them; a new passkey signs only once the operator confirms it, and that confirmation is a moment of trust; what the executor sends to the AI provider is not inspected; and it words the review notices sent to the company's own review channel. On ARBITER's own server, a shell inside the database or inside the broker is the trusted base. An action paid through the gate does not rest on it: the gate is a separate service on Cloudflare, in an account ARBITER's server holds no credential for, and it holds the only credential that pays. It pays only what a person its owner chose approves there, with a passkey on their own device, to payees and up to limits its owner set. On 16 October 2026 root on ARBITER's server, holding the database, the broker and its key, rewrote ARBITER's own records and was refused at the gate 15 ways; the one payment was the one a person approved on their phone (the run log). The gate trusts Cloudflare and its owner's login, the people's devices, and an approver's judgement of terms it shows exactly. Today its payment is an instruction posted to a channel only the gate can post to, standing in for a bank; connecting a real payment rail is work still ahead.
What's working today in ARBITER, demonstrated live — not a roadmap slide.
Runs entirely on infrastructure you control.
Proven in both directions, at the database layer — demonstrated live.
Every AI call produces a tamper-resistant, tenant-scoped audit record.
Block, allow, or require human review, based on your rules.
AI spend governed per call, before it happens.
Every result scored against your rules, verdict recorded.
ARBITER is a working prototype built by one person. It is not certified, production-hardened enterprise software today. The path to that — SOC 2, third-party penetration testing, BAA capability, the full audited control set — is deliberate work ahead, not something we'll pretend is finished. What exists is the hard architectural core, working and demonstrable. The rest is a roadmap.
Self-hosted AI governance for regulated financial and insurance workflows — tenant isolation enforced at the database, policy and constitutional checks before and after every model call, and signed execution certificates as proof of what happened.
Future governance products for regulated industries will follow the same architecture: enforced where it can be proven, not promised.
Independent founder. ARBITER started from a simple frustration: trying to find real work in a marketplace flooded with scams and spam, and realizing the hard problem wasn't the work — it was separating what's real and trustworthy from what isn't. That question pulled me into the deeper one underneath today's AI boom: when a machine does the work, how do you trust it, govern it, and prove what it did?
I built ARBITER to answer that for the people who can least afford to get it wrong — regulated financial and insurance firms. I build the careful way: nothing is called done until it has been run and verified.
I'll show you the working demo live — two tenants, complete isolation, a real AI request flowing through the full governance pipeline — and I'll be straight about exactly what's built and what isn't.