A routine claim goes straight through, with a signed certificate.
Two tenants. Complete isolation. A real AI request flowing through the full governance pipeline — enforced by the database, not a promise in application code.
Every stage records a verdict. Block, allow, or route to a human — the decision and the reason are both in the audit trail afterward.
A cross-tenant read or write is refused by the database itself — not caught by a query filter that could be missed.
Policy stops an agent that asks for permission. The consequence boundary stops one that doesn't.
In the call, a tool with no policy path and no human reviewer tries to cause a real effect — an outbound notification — every way it can. The only attempt that forms is the one carrying a capability it could not have made for itself.
Seven presentations to the broker, one consequence formed; messages lightly trimmed. The admitted one is written down twice: as pending the moment its capability is claimed, before anything goes out, and as admitted once the destination answers, so a call cut off midway still leaves its receipt and cannot be replayed. Step 01 never appears here — it never reached the broker, or anything else.
The same test runs against the database. A tool whose role holds no INSERT tries to append to a ledger directly, and Postgres answers permission denied for table cb_ledger — not a policy decision, but a statement it will not run.
Scope: this holds against anything holding the tool's credentials, and against a shell inside ARBITER's executor. In a real run on 13 October 2026, 38 attempts from inside it were refused, a forged approval among them, which got no permit at all, and one consequence formed, through a capability. Four limits remain: the executor serves the page where a person approves, so it could show them one amount while their device signs another; a new passkey is trusted once the operator confirms it; its traffic to the AI provider is not inspected; and it words the notices sent to the company's own review channel. On ARBITER's own server, a shell inside the database or the broker is the trusted base. An action paid through the gate goes further: 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, on their own device, to payees and up to limits its owner set. In a real run on 16 October 2026, root on ARBITER's server, with 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 gate trusts Cloudflare and its owner's login, the people's devices, and an approver's judgement of terms it shows exactly.
A real copy of ARBITER on its own server, with two made-up companies. Each button sends a real request and shows you what ARBITER answered.
A routine claim goes straight through, with a signed certificate.
A $48,000 wire waits for a person, and you decide it as the bank's reviewer.
Edit that certificate and the check fails.
One company asks for another's record and is told it does not exist.
The AI's payment tool, holding the real database credential, cannot move the money on its own.
The AI there is a stand-in with canned answers, so the demo is free and repeatable; the governance around it is the real thing. It resets every night.
With the real AI models: in a full dress rehearsal on 13 October 2026, six made-up companies, each with its own rules, ran on a copy of production against the models production uses. 88 checks passed and 1 failed, a check that expected too little; every step is in the log, the failure and why included.
A company of your own on the demo server, until the nightly reset: an admin sign-in to the real dashboard (your password, then your own authenticator app, the two factors production uses), an API key, and the rules a new install starts with. Write your own rules, send your own requests, decide the held ones, and try to reach another company's data. Anonymous: no name, no email.
A real intent submitted through the API — not a script recording.
Two tenants, side by side — one cannot read or write the other's data.
Policy evaluation blocking, allowing, or routing to human review — live.
The full audit trail for that one request, tenant-scoped.
A signed execution certificate you can verify yourself afterward.
The consequence boundary holding: a tool handed the real credential that still can't cause the effect, and the receipt showing what formed and what didn't.
This is a live demo of a working prototype, not finished enterprise software. I'll tell you exactly what's built and what's still ahead — no slides standing in for the real thing.
You'll leave knowing exactly what ARBITER does today, what it doesn't, and whether it fits what you're trying to govern.