ARBITER: root on the ARBITER server, against the gate A real run on production (sovereignarbiter.com) and the live gate, 16 October 2026, 06:00 UTC ================================================================================ WHAT THIS IS Every earlier run log ended the same way: a shell in the database or the broker, or root on the host, is outside this test. That was the honest limit. Who may approve a payment was a record on the ARBITER server, confirmed there by its operator, and the credentials lived there too; whoever held the server could write the records and use the credentials. This run is that adversary: a script run as root on the production server, holding the database as its owner, every container, and the broker's own key. Since 16 October an action can be paid through the gate instead: a small service on Cloudflare, in an account the ARBITER server holds no credential for. The gate holds the only credential that pays (here: a Slack channel only it can post to, where it posts a payment instruction). It pays only when ARBITER asks, with a key the gate's owner granted, for a payee the owner listed, AND a person the owner granted approves the exact terms with a passkey on their own device, on the gate's own page, up to the limit the owner set. The owner is a passkey on the owner's phone, made once when the gate was set up; every change of authority since is a signature of that passkey over the exact change. None of these records is on the ARBITER server. RESULT: 21 outcomes as the design predicts, 1 payment formed, 0 unexpected. Root could lie to ARBITER's own records: a forged "paid" receipt, a rewritten amount. The gate never heard of the first and still held the signed amount. It refused every attempt to make it pay: setup again, a forged session, root's own passkey, the owner's passkey with root's signature, a real signature of the owner's copied from the public log, an approval made on ARBITER's own site, and the broker's own key used for root's account, over the limit, for another company, to rewrite the request, or with a note for the approver. Root could do one thing: ask, for 49,999.99 to the listed payee. The owner saw exactly that on the gate's page and rejected it. The one payment is the one the owner approved on their phone, USD 48,000.00 to the test payee, and exactly one payment instruction arrived in the channel. WHAT CHANGED SINCE THE 13 OCTOBER RUN A reader of that run pointed out that a compromised executor could still write approval records, register a passkey and store a forged signature, which the broker then refused; that a broker refusing forged records is not the same as authority established outside the compromised environment; and that the record excluded broker, database and host-root compromise. All three were true. So the authority moved off the server, and this run attacks from where the earlier ones stopped. The 13 October log stays published: 2026-10-13-executor-compromise.txt CHECK IT YOURSELF The gate's log is public: https://arbiter-gate.jerrymcclintock1.workers.dev/v1/log Its receipt key: https://arbiter-gate.jerrymcclintock1.workers.dev/.well-known/arbiter-gate Each entry's hash is sha256(prev + "\n" + seq + "\n" + at + "\n" + kind + "\n" + body), and names the entry before it. The owner's passkey and every passkey registered are in the log (owner_established, passkey_registered), so every signature in it can be checked with the log alone: each owner change (owner_op: the exact terms and the owner's WebAuthn assertion over them), each request (ARBITER's Ed25519 signature over its exact text, under a key an owner granted), each approval or rejection (the person's assertion over the exact terms: the request, its text's hash, the company, account, amount and currency), and each receipt (the gate's Ed25519 key). Section 7 below is that check, by a tool that reads nothing else. The tool, one file: https://consequenceaisystems.ai/runs/verify_gate_log.py (sha256 5cf33bb32dbb8ca7eb7f3dde6b27c449093b5ad62ed098846d3da2d1a6e81f6d; its examples were corrected after this run, its checks are the ones section 7 ran) It needs Python 3.10+ and the cryptography package: pip install cryptography python3 verify_gate_log.py https://arbiter-gate.jerrymcclintock1.workers.dev Read it first; it is about 330 lines. The log has grown since this run (the owner later revoked root's passkey, entry 27), so it will count more than section 7 did. WHAT IS STILL TRUSTED - Cloudflare, and the gate owner's Cloudflare login: whoever holds it can replace the gate's code. The code is one file, run as written with no build step, deployed once by Cloudflare's own build from our repository, which was then disconnected. - The owner's phone. Here the owner and the one approver are the same person, the founder, with one passkey. - The approver's judgement. The gate shows exactly what it will pay; a person can still approve a bad request, but only to a payee the owner listed, under the limit. - Root on the ARBITER server can still ask (as it did), delay, or never ask, and it can make ARBITER's own dashboard say anything. It could not make the gate pay. - The payment is a payment instruction posted to a channel only the gate can post to, standing in for a bank. No real money moves. No customer uses ARBITER yet. ONE LINE, EXPLAINED Step 1 printed "a Cloudflare credential: none found (... .env: 1 matches)". The match was a folder of logs left on the server by local dry runs of Cloudflare's deploy tool while the gate was built: no login, no token in it. It was removed after this run, and the script now names what it finds instead of counting. THE RUN, AS IT PRINTED -------------------------------------------------------------------------------- ARBITER: root on the ARBITER server, against the gate Run 20261016T060029Z, code ab0a67d, on ubuntu-8gb-ash-1 ================================================================================ The gate: https://arbiter-gate.jerrymcclintock1.workers.dev (gate id consequence-gate-1), on Cloudflare. owners: 1; receipt key d0c54208de7a1516; its public log has 8 entries before this run. It pays only when ARBITER's granted key asks, for a listed payee, AND a passkey the owner granted approves the exact terms on the gate's own page, up to the owner's limit. 1 WHAT ROOT HOLDS HERE the database, as its owner (sal): sal the broker's own gate key: on the volume arbiter-v110_broker_state, fingerprint a99bf7485cafd3d1 (granted at the gate) a Cloudflare credential: none found (environment, ~/.wrangler, .env: 1 matches) the gate's payment credential: not here (no EFFECT_SLACK_URL in .env or any container: 0) 2 ROOT WRITES A REQUEST STRAIGHT INTO ARBITER'S DATABASE, MARKED COMPLETED request a8678001: USD 48,000.00 to PROOF-PAYEE-001, company boundary-proof, no rule, review or model behind it ARBITER asks the gate, as it would for any completed bound request: request ba308f82, pending 3 ROOT REWRITES ARBITER'S OWN RECORDS as predicted 3.1 a forged 'executed' gate receipt in ARBITER's tables: ARBITER's record says paid; the gate never heard of it observed: ARBITER: executed; the gate: HTTP 404 for that request as predicted 3.2 the real request rewritten to 1.00 in ARBITER's table (trigger disabled; rolled back): the gate holds what was signed observed: ARBITER's row read 1.00 inside the transaction; the gate holds 48000.00 4 ROOT AGAINST THE GATE: its doors, passkeys, the broker's own key, a key of its own as predicted 1.1 make itself the gate's owner through setup observed: 410 this gate already has an owner: setup is closed for good as predicted 1.2 read the owner's page with a made-up session observed: 401 sign in with your passkey first as predicted 2.1 register a passkey of its own at the gate observed: 200 pending as predicted 2.2 approve the proof's payment with it observed: 403 the passkey 917647476461f68d is pending, not active as predicted 2.3 make that passkey an owner, signing with itself observed: 403 the passkey 917647476461f68d is pending, not active as predicted 3.1 approve under the owner's passkey id, with a signature of its own observed: 403 the passkey's signature does not verify as predicted 3.2 replay a real signature of the owner's, copied from the public log observed: 403 the passkey signed other terms than these as predicted 3.3 present an approval made on the ARBITER server's own site observed: 403 the passkey signed for https://sovereignarbiter.com, not for this gate as predicted 4.1 with the broker's own key: pay an account of root's observed: 403 account ROOT-ACCOUNT-666 is not a payee an owner listed for that company as predicted 4.2 with the broker's own key: 50,000.01 to the listed payee observed: 403 no approver of that company may approve this amount as predicted 4.3 with the broker's own key: for another company observed: 403 this ARBITER key may not ask for that company as predicted 4.4 with the broker's own key: rewrite the proof's request (same id, 1.00) observed: 409 another request already has this id as predicted 4.5 with the broker's own key: a request carrying a note for the approver observed: 400 the request must have exactly these fields: account, amount, currency, expires_at, gate, id, intent, issued_at, kind, tenant, v as predicted 5.1 with a key of root's own, named like ARBITER's observed: 403 the request is not signed by an ARBITER key an owner granted as predicted 6.1 with the broker's own key: ask for 49,999.99 to the listed payee observed: 200 pending 5 NOTHING HAS BEEN PAID as predicted 5.1 after all of that, the gate has paid nothing and the request still waits for a person observed: payments in the gate's log since the run began: 0; request ba308f82: pending; log entries this run: 15 6 THE PERSON, ON THEIR PHONE At the gate (sign in, then 'Requests waiting', or the links): APPROVE USD 48,000.00 to PROOF-PAYEE-001 https://arbiter-gate.jerrymcclintock1.workers.dev/a/ba308f82-8f1d-56df-9160-9ae9e056b45b REJECT USD 49,999.99 to PROOF-PAYEE-001 https://arbiter-gate.jerrymcclintock1.workers.dev/a/96e453ad-14ea-4e25-9972-e3a7ac090473 (root asked for this one) Waiting up to 20 minutes... 48,000.00: executed 49,999.99 (root's): rejected formed 6.1 the person approved 48,000.00 with their passkey: the gate posted ONE payment instruction as predicted 6.2 the person rejected the 49,999.99 root asked for: nothing paid for it observed: rejected as predicted 6.3 ARBITER records the gate's receipt, signed by the gate's key it pinned observed: broker: {"bound":true,"request":"ba308f82-8f1d-56df-9160-9ae9e056b45b","outcome":"executed","recorded":true}; ARBITER shows: executed 7 THE GATE'S PUBLIC LOG, CHECKED BY A TOOL THAT TRUSTS ONLY THE LOG AND THE GATE'S KEY Gate consequence-gate-1 at https://arbiter-gate.jerrymcclintock1.workers.dev: 26 log entries, head c7296ad5b6ed8de3 owners now: Jerry (70273a3a671fa771) owner changes: 4 requests: 2 approvals: 1 rejections: 1 payments made: 1 failed payments: 0 receipts: 1 refusals logged: 12 paid: #26 USD 48000.00 to PROOF-PAYEE-001 (company Boundary proof (test)), approved by Jerry (70273a3a671fa771) Everything holds: the chain, every owner change, every request, every approval and every receipt. Every payment this gate made was approved, over its exact terms, by a passkey an owner granted. as predicted 7.1 tools/verify_gate_log.py: everything holds, and the gate has made exactly one payment observed: exit 0 ================================================================================ RESULT: 21 outcomes as the design predicts (each a refusal, or a lie told only to ARBITER's own records), 1 payment formed (the person's approval at the gate), 0 unexpected. Exactly one payment instruction should now be in #arbiter-gate. The log: reports/host-compromise-run-log-20261016T060029Z.txt