The foundation · version 1 · superseded

ARBITER: the foundation, stated to be checked

Superseded the same day by version 2, which closes the gap section 4 shows; the latest version is here. Kept here as it was published.

Version 1, 18 October 2026. Code 8b66202 (production and the demo). The gate runs gate/worker.js as committed there, unchanged since it was deployed on 16 October (version gate-1, SHA-256 e5f9ebbfe64c33bc0e50e29e05060159aa0a5dd8b0e7a07eeb7d014013b0ed4d).

Consequence AI Systems · jerrymcclintock@sovereignarbiter.com

1What this is

Our run logs show how ARBITER behaved when it was attacked. A passing test shows that the routes it tried were closed. It does not show that no other route exists, and it does not say which rules the system is built to keep.

This document says that first. It states:

who ARBITER must hold against (section 2);
the rules it keeps, the things that must never happen, each with what enforces it and the evidence (section 3), and the gate's rule written out exactly (section 4);
every route by which the protected effect, a payment, could form, and what closes each one (section 5);
what is trusted, and what is not claimed (sections 6 and 7);
the evidence, frozen with hashes, and how anyone can re-check it (section 8);
what is not done yet (section 9).

If a rule here is wrong, if a route is missing from section 5, or if the evidence does not say what we say it says, that is a finding, and we want it: jerrymcclintock@sovereignarbiter.com.

2Who it must hold against

	Adversary	What they hold
A1	An outsider	Nothing: the public internet
A2	Another company on the same ARBITER	Its own users and API keys
A3	The AI model, what it is fed, and the agent's tools	Whatever text it returns; the tool's own database login
A4	Code running inside ARBITER's executor	The executor's environment, database login and signing keys: the part that reads untrusted input and calls the model, so the part most likely to be made to run an attacker's code
A5	Root on the ARBITER server	Everything on that server: the database as its owner, every container, every key and credential kept there

What is trusted, against all five, is in section 6.

3The rules

Each rule says what must never happen, who it holds against, what enforces it, and where the evidence is. Rules G1 to G4 are kept by the gate, off the ARBITER server. Rules S1 to S5 are kept on the server.

Kept by the gateoff the ARBITER server

No payment without the whole chain of authority

A payment forms only when ARBITER asks, under a key an owner granted for that company, to pay a payee an owner listed for that company, AND a person whose passkey an owner activated and granted for that company approves the exact terms on the gate's own page, within the limit the owner set for that passkey.

Holds against: A1 to A5
Enforced by: The gate, a Cloudflare Worker in an account the ARBITER server holds no credential for (gate/worker.js: intakeChecked, decideChecked, verifyAssertion). It holds the only credential that pays.
Evidence: The 16 October run (section 8). Root on the server, holding the database and the broker's own key, made 15 attempts on the gate: 13 were refused outright, the passkey it registered stayed pending and could do nothing, and the $49,999.99 it asked for waited for a person, who rejected it. One payment formed: the one the owner approved on their phone. 21 outcomes as predicted, 0 unexpected. The gate's own tests (113 checks) and the end-to-end test (32 checks) run on every change.
Exactly: Written out in section 4.

At most once

A request pays at most once, and a failed payment is never retried: ARBITER must ask again, and a person must approve again.

Holds against: A1 to A5
Enforced by: An approval moves the request from pending to executing in the same transaction that records the approval, before the payment is attempted; a second approval finds it no longer pending (decideChecked).
Evidence: The gate's tests send ten approvals of one request at once: one executes, nine are refused.

Authority changes only by an owner's signature

Who may approve, for which company, up to what limit, which payees, and which ARBITER keys may ask: each of these changes only by an owner's passkey signature over the exact change, made within the last five minutes, applied once.

Holds against: A1 to A5
Enforced by: opStart, opFinish, applyOp. The first owner was made once, with a setup code that only the Cloudflare account can set; setup then closed for good, even if that owner is later revoked. The last active owner cannot be revoked. A passkey anyone registers is pending and can do nothing until an owner activates it.
Evidence: The 16 October run: root tried to make itself owner through setup (refused: closed for good) and to make its own passkey an owner, signing with that passkey (refused: pending, not active).

The gate's record is public, and anyone can check every signature in it

Every event at the gate (setup, registrations, owner changes with their signatures, requests with ARBITER's signature, approvals and rejections with the person's signature, refusals, payments) is appended to a hash chain that anyone can read. Every final outcome is a receipt signed by the gate's own Ed25519 key.

Holds against: A1 to A5. Nothing on the ARBITER server can write to it.
Enforced by: append (each entry's hash covers the one before it) and receipt.
Evidence: verify_gate_log.py, one file of about 330 lines that needs only Python and the cryptography package, replays the whole log from its first entry: the chain, every owner change, request, approval and receipt. Section 8 freezes the log's head as of this version.

Kept on the serverARBITER's own layers

The company's rules decide before the AI acts

No model is called for a request until the company's rules have decided it. A block stops it. A review holds it until a person decides. Only "proceed" reaches the model. A rule the evaluator cannot read, or a payload value of the wrong shape, sends the request to a person, never through. Every model answer is checked against the platform's and the company's principles before it is released; one that fails is blocked or held for review, and a check that runs out of time counts as a failure.

Holds against: A1 to A3
Does not hold: A4 and A5, which control the code that applies the rules.
Enforced by: The executor's pipeline (executor/main.py: the decision commits before any model call), executor/jsonlogic.py (strict mode), executor/cle_engine.py.
Evidence: The 13 October dress rehearsal (88 of 89 checks; the one failure is explained in its log); the sandbox, where anyone can write a rule and test it.

Companies are walled off by the database

A request authenticated for one company can neither read nor write another company's records.

Holds against: A1 to A3
Does not hold: A4 and A5. The executor can take the database role that crosses companies, which it needs for background work.
Enforced by: PostgreSQL row-level security, enabled and forced, on every table that holds a company's records. The schema contract fails if a new such table lacks it. Three tables are exempt, each named with its reason in test_arbiter.sh check 1: the sign-in accounts, which a super-admin lists across companies by design; usage counts, read only with the company named in the query; and one table nothing reads. Request connections use a role that cannot bypass it; the role that can is reached only through one function, which requires a reason and logs it. A static check fails the build if any other way to the database appears.
Evidence: The guided demo's step 4 and every sandbox: one company's key asks for another's record and gets "not found". The dress rehearsal's isolation checks.

Records are add-only, chained, and copied off the server

The audit log, the execution certificates and the effect receipts are add-only for every application role. Each is a hash chain. Within about five minutes, each chain's head is copied to write-once storage (S3 Object Lock in compliance mode, which not even that storage account's own root can shorten) in a separate cloud account. The copies are checked hourly on the server, and every six hours from GitHub with read-only access and no stored key.

Holds against: A1 to A4. The executor's login cannot rewrite any of it.
Against A5: Detected, not prevented. Root can rewrite the database. It cannot change the copies already made, so a rewrite of anything already copied shows up in the next check. A record is unprotected for the seconds before it is sealed.
Enforced by: Migrations 30 and 47, the anchor sidecar, verify_receipts, .github/workflows/receipt-anchors.yml.

A certificate cannot be changed without its check failing

Each execution gets one certificate, issued once and never reissued, signed with Ed25519. It records who asked (as a role), what was asked (a hash), which rule decided and the hash of the whole rule set, the model and the hash of its instructions, the principles checked, the reviewer's role if a person decided, and what became of it. Anyone can check one with the public key at /.well-known/arbiter-certificate-keys: any change to any field makes the signature fail.

Holds against: A1 to A3
Does not hold: A4 and A5, which hold the signing key and can sign a false certificate. Whether a certificate is the instance's own record is answered by POST /certificates/verify (on_record) and by S3. Against the server itself, the evidence is the gate's receipts (G4), not ARBITER's certificates.

Inside the server, neither the tool nor the executor can pay on its own

This is the server's own layer for payments made through it rather than through the gate (the demonstration ledger). The tool's database login cannot write the ledger or create a permit. A permit comes only from the effect broker, after it has verified a person's passkey signature over the exact terms, by a passkey the operator confirmed; each permit pays once.

Holds against: A1 to A4
Does not hold: A5, or a shell in the database or the broker. That is why the gate (G1 to G4) exists. A payment bound to the gate does not rely on S5.
Evidence: The 13 October run from inside the executor: 38 attempts refused, 1 effect formed (the sanctioned one), 0 outcomes other than predicted.

Who each rule holds against

A1 outsider · A2 other company · A3 model, tool · A4 executor code · A5 root on server

Rule	A1outsider	A2other company	A3model, tool	A4executor code	A5root on server
G1authority to pay	holds	holds	holds	holds	holds
G2at most once	holds	holds	holds	holds	holds
G3owner-signed changes	holds	holds	holds	holds	holds
G4public, checkable record	holds	holds	holds	holds	holds
S1rules before the AI	holds	holds	holds	no	no
S2company walls	holds	holds	holds	no	no
S3add-only, copied off	holds	holds	holds	holds	detected
S4certificates	holds	holds	holds	no	no
S5no payment alone, on the server	holds	holds	holds	holds	no

4G1 written out exactly

For every payment instruction the gate's credential sends, there is exactly one request r and one approval a such that:

When the gate received r:
- its text has exactly the fields account, amount, currency, expires_at, gate, id, intent, issued_at, kind, tenant, v, names this gate, and is signed (Ed25519) by an ARBITER key whose status is active and whose companies include tenant(r);
- account(r) is a payee listed for tenant(r);
- amount(r) is greater than zero, issued_at is within five minutes of the gate's clock, and expires_at is in the future and at most 24 hours after issued_at.
When a was recorded:
- r was pending and had not expired;
- a is a WebAuthn signature by a passkey p whose status is active and which is granted for tenant(r) with a limit at least amount(r);
- the signature is over SHA-256 of the exact terms {v, kind: "approve", gate, request: id(r), request_sha256: SHA-256 of r's text, tenant, account, amount, currency};
- it was made for the gate's own origin, not from inside another site, by an authenticator that reports the person present and verified (PIN or biometric), with a signature counter that did not go backwards;
- in the same transaction, r became executing.
The sets in 1 and 2 (active ARBITER keys and their companies, payees, active passkeys, grants and limits) change only by an owner operation (G3).

The credential that pays (EFFECT_SLACK_URL) is read in one place in the gate's code, the function effect, and that function is called in one place, after the transaction in 2.

That is the whole claim for G1, and it is the one a reviewer should try to break.

A gap this statement shows

Item 1 is checked when the request arrives, not again at approval. If an owner unlists a payee, or revokes ARBITER's key, a request already waiting can still be approved until it expires (24 hours at most). It still needs a person with a granted passkey to approve it, within that passkey's limit. The fix, re-checking item 1 inside the approval's transaction, is planned for the next gate release.

5Every route to a payment, and what closes it

The protected effect is a payment instruction sent with the gate's credential. Today that credential is a Slack webhook address, standing in for a bank, and the instruction is a message posted to a channel kept for it. These are all the ways we know for such an instruction to form:

#	Route	What closes it	What remains
R1	Use the credential directly	It exists only in the gate's Cloudflare settings. It is not on the ARBITER server or in any of its containers (checked in the 16 October run), and the server holds no Cloudflare credential.	Whoever holds the Cloudflare login, or can read the webhook's settings in Slack (section 6)
R2	Change the gate's code	Only through the Cloudflare account. The code is one file, run as written with no build step. The automatic build that deployed it was disconnected, and the branch it built from deleted, so nothing pushed to our repository reaches it.	The Cloudflare login (section 6)
R3	Ask without ARBITER's key	Refused: the request must be signed by an active ARBITER key granted for that company. A key root makes for itself stays pending until an owner grants it.
R4	Ask with ARBITER's real key (root holds it)	Allowed: asking is not paying. Every request still needs R5 to R8. Root asked in the 16 October run; nothing paid until a person approved, and the person rejected root's request.	Root can ask, delay or withhold requests
R5	Pay an account of the attacker's	Refused: the payee must be listed for that company, which only an owner can change (G3)	Section 4's gap: a payee unlisted after a request arrives
R6	Approve without a granted person	Refused: the passkey must be active and granted for that company. A passkey root registers stays pending. A signature made with another key, or for another site, does not verify.
R7	Replay a real approval	Refused: an approval signs the exact terms, including the request's id and the hash of its text, so it fits one request, and that request is no longer pending once used
R8	Exceed the limit	Refused: the amount must be within the limit the owner set for that passkey and company. A request above every approver's limit is refused on arrival.
R9	Change the authority (add a passkey, raise a limit, add a payee)	Refused: only by an owner's signature over the exact change (G3). Setup is closed for good.	The owner's device (section 6)
R10	Pay twice	Refused: G2
R11	Trick the approver	The terms are shown by the gate's own page, from the gate's own records, not by the ARBITER server.	The approver's judgement, bounded by listed payees and the limit
R12	Break the gate's code itself	Its input checks; its tests (113 checks)	A bug we have not found. This is what an outside review is for (section 9).
R13	Compromise Cloudflare, or the owner's or an approver's device	Not closed: trusted (section 6)

6What is trusted

Cloudflare, and the gate's Cloudflare login. Whoever holds that login can replace the gate's code. As of 16 October 2026 the account has one member, no API tokens, and two-factor sign-in. The same account holds the DNS for our domains.
The owner's device. One owner today: a passkey on the founder's phone.
The approvers' devices and judgement. Today the owner is also the only approver.
The payment rail's own access control. Today that is Slack: whoever manages the Slack app can see its webhook address, and anyone in the workspace can type in the channel by hand; a message from the webhook shows it came from the app. A real bank would accept the gate's credential alone.
The cryptography and the platforms: Ed25519, ECDSA P-256 and RSA signatures, SHA-256, WebAuthn as browsers and authenticators implement it, PostgreSQL's row-level security, Docker's network isolation.

7What is not claimed

That the AI's answers are correct. ARBITER governs what a model may do and records what it did; it does not make the model right.
That ARBITER stays available. Root on the server can stop it, and can stop it asking the gate. Nothing here claims availability.
That ARBITER's own dashboard tells the truth when root holds the server. Root can write any record there, including a forged "paid" receipt (done in the 16 October run). The gate's log is the truth about payments.
Anything about effects other than payments bound to the gate. Review notices, for example, are sent by the server's own broker.
What the executor sends to the AI provider. It is encrypted end to end, so it is not inspected.
Real money, or customers. The payment is an instruction standing in for a bank. No customer uses ARBITER yet.

8The evidence, frozen

Each run log states where it started (the code and the setup), what was changed (the attacks), the protected effect, the receipts, the routes tried, and the results. It is published as it printed. A file's SHA-256 here lets anyone confirm they have the same bytes.

12 Oct, from inside the executorsuperseded, kept

code 1366ca637 refused, 1 formed, 0 failures

sha256 8b835c1501ef35667ec9a328480948842772c1cf0c7a88c3a456eb796749d748
13 Oct, from inside the executor

code 4ad364738 refused, 1 formed, 0 other than predicted

sha256 aed031ca02191ea73cfb0fba4dafc8c2fa6c8d8965555e9535a600fecd8c4205
13 Oct, full dress rehearsal, real AI models

code 615c73888 passed, 1 failed (explained)

sha256 89cb11d6877c67d8ac3d44830fdc3299b8e86263f42b6bc99553b7d51bfaf40e
16 Oct, root on the server, against the gate

code ab0a67d21 as predicted, 1 formed, 0 unexpected

sha256 6d4b8202017f02bf3fb785a126c07db3274454845971f9ee8381be048d6f4c4b
The checker, verify_gate_log.py

sha256 5cf33bb32dbb8ca7eb7f3dde6b27c449093b5ad62ed098846d3da2d1a6e81f6d

The gate's log, frozen at this version

Entry 27, head hash

60ac6b5b51a2397159c135b545a1988acf5062b4d847f38b07329d5725a89803

The log only grows. Run the checker against it and confirm that entry 27 still has this hash: then entries 1 to 27 are the ones this document describes.

Loghttps://arbiter-gate.jerrymcclintock1.workers.dev/v1/log
The gate's receipt key (kid d0c54208de7a1516)https://arbiter-gate.jerrymcclintock1.workers.dev/.well-known/arbiter-gate
ARBITER's certificate key (kid a77bb4db5aef3e4d)https://sovereignarbiter.com/.well-known/arbiter-certificate-keys

What anyone can reproduce today, without trusting us:

Every signature in the gate's log, with the checker.
The bytes of every run log, with the hashes above.
Any ARBITER certificate, with the public key.
S1, S2 and S4 by hand, in a sandbox of your own: demo.sovereignarbiter.com/#sandbox (the gate is not connected to the demo).

What needs our code: re-running the attack scripts themselves. The source is private today. No change reaches production until all 11 of its CI jobs pass on that exact commit.

9Not done yet

A machine-checked model of the gate's rules. Section 4 is written by hand. Next is a formal model of the gate's states and owner operations, checked by a model checker against G1 to G3 for every order of events up to a bound. It will check the design, not that the code matches it.
An outside review of the gate's code and of this document.
A second owner. With one owner passkey, losing the phone would freeze the gate's authority: nothing could be changed and nothing could be approved. Two hardware security keys are on order as backup owners.
Section 4's gap, closed in the next gate release.
A real payment rail, and customers.

10Where it is in the code

For a reviewer with access.

The gate: gate/worker.js (one file). Its tests: gate/test/gate.test.mjs, tests/gate.sh, tests/gate_test.py.
ARBITER's side of the gate: broker/gate_client.py, migration db-nexus/56-gate.sql.
Rules before the AI: executor/main.py (atomic_execute), executor/jsonlogic.py, executor/cle_engine.py.
Company walls: executor/tenancy.py, db-nexus/10-v110-isolation.sql, tests/schema_assertions.sql section 2, tests/test_no_bare_acquire.py.
Records and their copies: db-nexus/30-receipt-chain.sql, 47-record-receipts.sql, anchor/, .github/workflows/receipt-anchors.yml.
Certificates: executor/certificates.py, tools/verify_certificate.py.
The server's own payment layer: broker/broker.py, broker/approval_check.py, migrations 45 to 51.
The longer account of each mechanism and its limits: docs/SECURITY-MODEL-v1.10.md.