ARBITER: a full dress rehearsal, six synthetic companies, the real AI model Run 13 October 2026, 9:36 pm US Eastern (2026-10-14 01:36 UTC), code 615c738, the code running on sovereignarbiter.com ================================================================================ WHAT THIS IS A dress rehearsal: all of ARBITER, run once end to end the way customers would use it. It runs on a disposable copy of production restored from that evening's backup (so every run is also a restore drill), never on production itself. Six made-up companies (two banks, a clinic, a billing firm, a law firm, a compliance team) are set up through the product, send requests to the real AI models production uses (xAI's grok-4.3 and grok-3), have people approve and reject what waits for review, and then the run attacks the system and audits its own evidence. Every step below is one line of the run's record, in order, with what was observed. Production has no customer data, and none of its records is written out here: only counts. RESULT: 88 checks passed, 1 failed. 10 steps are setup the product has no route for, done as the database's owner and marked so; 4 checks run only with the stand-in model and are skipped here. The one failure (R3.2) is a check that expected too little, not a fault. A $15,000 wire waited for a person; the person approved it; the AI model then answered, and a platform principle (P2-STRUCTURING-FLAG) flagged that answer, so it was held for a second review instead of going out. That is what ARBITER does with a flagged answer to an approved request: an approval clears the request, not whatever the model says next. The check assumed the answer would pass, as the stand-in model's always does. The executor's own record shows the hold. The check now accepts either outcome and says which it saw. WHAT IS NEW SINCE THE EARLIER 13 OCTOBER RUN LOG (2026-10-13-executor-compromise.txt) - Each company's own governance (R8). A company's admin can add principles (checks on what the AI says) and routing rules of its own, which apply to that company alone, on top of the platform's, which apply to everyone and which it cannot change. Here Billing B added a principle: it blocked Billing B's request, and Clinic A's identical request, on the same kind of work, went through. Clinic A could neither see Billing B's principle nor change it. Billing B's routing rule sent its requests to tier 1 and left Clinic A's on tier 2 (in this installation both tiers use the same model; the rule is the point). Each company's violation counts and answer cache are its own. Until today a principle applied to every company. - Certificates anyone can check (R7.2). Every certificate is now signed with a key pair. All 33 that this run produced were checked with the public key the system publishes, with no call to ARBITER and no secret, and each says what became of its request: 25 released, 3 rejected by a person, 2 blocked, 2 refused for budget, 1 review that expired. Until today only ARBITER itself could check one, and a refusal for budget could read like a pass. WHAT IT DOES NOT SHOW - It runs on a copy, with made-up companies and a few dozen requests: not a customer's traffic, and not a load test. No customer uses ARBITER yet. - Approvals here are by the made-up reviewers' accounts. A payment's approval signed with a passkey on the person's own device is shown in the earlier 13 October log. - Each company's own review channel (its own Slack and webhook) is covered by the test suite, not by this run. - A shell in the database or the broker, or root on the host, is outside it. EVERY STEP, IN ORDER pass / FAIL is a check the run makes. setup is a step the product has no route for, done as the table owner and said so. info is a measurement, not a check. Shown as recorded, except: ids are cut to 8 characters; R7.5 leaves out production's rule names; and R3.3 and R4.3 are worded as the scenario words them since this run (the record says 'model calls=0' where the real model's calls are not counted, and 'secret=' for the NAME of the tenant's key). R0 BUILD: a copy of production restored from its nightly backup pass R0.1 the nightly backup restores cleanly and every migration 11+ replays observed: restore errors: 0 | migrations replayed: 37, failed: 0 pass R0.2 the schema contract holds on the restored copy observed: ['== schema contract', 'NOTICE: schema contract holds'] pass R0.3 the executor starts (its startup check passes) and answers through Caddy observed: 200 R1 ONBOARDING: six synthetic companies set up through the product setup R1.0 platform account rh-root-1 (setup: the first super_admins need the owner) observed: 200 setup R1.0 platform account rh-root-2 (setup: the first super_admins need the owner) observed: 200 pass R1.0 the live model has a cost rate (budgets can only enforce a priced model) observed: ['llama-3.1-8b-instruct', 'llama-3.1-70b-instruct', 'grok-2', 'grok-3', 'grok-4', 'grok-4.3', 'gpt-4o', 'claude-3-5-sonnet', 'claude-sonnet-4-20250514'] pass R1.1 tenant demo-bank-a created through the API observed: 201 pass R1.1 tenant demo-bank-b created through the API observed: 201 pass R1.1 tenant demo-clinic-a created through the API observed: 201 pass R1.1 tenant demo-billing-b created through the API observed: 201 pass R1.1 tenant demo-law-a created through the API observed: 201 pass R1.1 tenant demo-compliance-a created through the API observed: 201 pass R1.1 demo-bank-a-admin created through a grant from the second super_admin observed: issue=201 exercise=200 pass R1.1 demo-bank-b-admin created through a grant from the second super_admin observed: issue=201 exercise=200 pass R1.1 demo-clinic-a-admin created through a grant from the second super_admin observed: issue=201 exercise=200 pass R1.1 demo-billing-b-admin created through a grant from the second super_admin observed: issue=201 exercise=200 pass R1.1 demo-law-a-admin created through a grant from the second super_admin observed: issue=201 exercise=200 pass R1.1 demo-compliance-a-admin created through a grant from the second super_admin observed: issue=201 exercise=200 pass R1.1 a grant a super_admin issues to itself cannot be used for 24 hours observed: issue=201 exercise=409 pass R1.2 demo-bank-a-reviewer (operator) created and signed in observed: create=201 login=200 pass R1.2 demo-bank-b-reviewer (operator) created and signed in observed: create=201 login=200 pass R1.2 demo-clinic-a-reviewer (operator) created and signed in observed: create=201 login=200 pass R1.2 demo-billing-b-reviewer (operator) created and signed in observed: create=201 login=200 pass R1.2 demo-law-a-reviewer (operator) created and signed in observed: create=201 login=200 pass R1.2 demo-compliance-a-reviewer (operator) created and signed in observed: create=201 login=200 pass R1.2 demo-bank-a-limited (operator) created and signed in observed: create=201 login=200 pass R1.2 demo-bank-a-compliance (compliance) created and signed in observed: create=201 login=200 pass R1.2 demo-bank-a's admin mints its agent and auditor keys observed: 201/201 pass R1.2 demo-bank-b's admin mints its agent and auditor keys observed: 201/201 pass R1.2 demo-clinic-a's admin mints its agent and auditor keys observed: 201/201 pass R1.2 demo-billing-b's admin mints its agent and auditor keys observed: 201/201 pass R1.2 demo-law-a's admin mints its agent and auditor keys observed: 201/201 pass R1.2 demo-compliance-a's admin mints its agent and auditor keys observed: 201/201 pass R1.3 a second tenant installs a pack: its own rules and drift baselines; the platform's parts are already there, so nothing waits for the operator observed: 200 rules=4+0 baselines=2 principles_skipped=4 requires_operator=0 errors=[] setup R1.3 demo-bank-a gets the live rule set for bfsi/sanctions (setup) observed: 10 rules setup R1.3 demo-bank-b gets the live rule set for bfsi/kyc (setup) observed: 6 rules setup R1.3 demo-clinic-a gets the live rule set for rcm (setup) observed: 8 rules setup R1.3 demo-billing-b gets the live rule set for rcm (setup) observed: 8 rules setup R1.3 demo-law-a gets the live rule set for legal (setup) observed: 6 rules setup R1.3 demo-compliance-a gets the live rule set for kyc/sanctions (setup) observed: 0 rules pass R1.4 demo-bank-a sets a blocking daily budget of $0.75 per domain observed: [200, 200] pass R1.4 demo-bank-b sets a blocking daily budget of $0.75 per domain observed: [200, 200] pass R1.4 demo-clinic-a sets a blocking daily budget of $0.75 per domain observed: [200] pass R1.4 demo-billing-b sets a blocking daily budget of $0.75 per domain observed: [200] pass R1.4 demo-law-a sets a blocking daily budget of $0.75 per domain observed: [200] pass R1.4 demo-compliance-a sets a blocking daily budget of $0.75 per domain observed: [200, 200] R2 ORDINARY TRAFFIC pass R2.1 14 ordinary intents across six tenants all complete observed: 14/14 completed; others: [] pass R2.1 an ordinary intent carries a certificate that verifies observed: {"valid":true,"on_record":true,"execution_id":"9316ec5d ","instance_id":"rehearsal","cle_verdict":"PASS","outcome":"relea sed","signature":"ed25519","ts":1791941668," skip R2.2 cache repeat (stub pass only) pass R2.3 an intent the tier rules send to Tier 1 (cpt_validation) completes observed: completed None R3 EVERY KIND OF DECISION pass R3.1 a wire to a sanctions hit is blocked and certified at the refusal observed: blocked cert=200 FAIL R3.2 a large wire waits for a person; approved, it completes and the certificate names the approver's role observed: force_hitl -> force_hitl approver=None pass R3.3 the same review approved twice at once: exactly one decision wins, one model call observed: codes=[200, 409] model calls=not counted with the real model pass R3.4 a value in the wrong shape ("true" for true) goes to a person, with a contract-violation record observed: force_hitl records=1 skip R3.5 held output released as approved (stub pass only) skip R3.6 P1 output block (stub pass only) pass R3.7 a review rejected: the intent does not run observed: blocked pass R3.7 a review left to lapse is closed by the sweep, and never certified as "not required" observed: review=expired certificate decisions=['expired'] skip R3.8 cache vs principle change (stub pass only) pass R3.9 past its budget, bank B's next intent is refused observed: {"intent_id": "8923ad66", "domain": "bfsi", "action": "wire_transfer", "status": "failed", "received_at": "2026-10-14T01:35:26.758085+00:00", "execution": {"id": "d6d146c4", "status": "failed", "policy_decision": "procee... R4 ATTACKS AND BOUNDARIES pass R4.1 bank A's keys cannot read bank B's intent, audit, certificate or decision trace observed: {'intent': 404, 'audit': 403, 'certificates': 404, 'intent/explain': 403, 'audit(auditor)': 404} pass R4.2 an agent key cannot read the rules, domains, metrics or users observed: {'/rules': 403, '/domains': 403, '/metrics': 403, '/users': 403} pass R4.3 a tenant admin reads only its own tenant's webhook secret, never the platform's observed: 200 key name=ddab9c9d (the tenant's id; the key itself is never shown) pass R4.4 an agent key cannot approve the review of its own intent (and the attempt is recorded) observed: force_hitl decide=403 records=1 pass R4.5 a reviewer disabled mid-session is refused at once observed: before=200 disable=200 after=401 pass R4.5 logging out on one browser ends the session on every browser observed: [200, 200] -> [401, 401] pass R4.6 someone hammering a reviewer's username locks out their own address, not the reviewer observed: guesses=[401, 401, 401, 401, 401, 429] correct-from- same-address=429 pass R4.7 a 2 MiB request is refused through Caddy (413, or closed mid- upload) and around it (413) observed: caddy=413 direct=413 pass R4.8 a forged client address from a container that is not Caddy is ignored observed: 172.23.0.7 pass R4.9 a bfsi-only operator is refused a sanctions intent and submits bfsi observed: sanctions=403 bfsi=200 pass R4.10 one super_admin cannot reset another user's password or delete a user without a grant observed: reset=400 delete=400 pass R4.11 a tenant admin cannot switch off a principle that governs every tenant observed: 403 pass R4.12 a compliance user cannot approve a review observed: 403 pass R4.6 and the reviewer still signs in from a second address observed: {'status': 200, 'next': 'verify'} R5 THE CONSEQUENCE BOUNDARY: money and messages only with a signed permit pass R5.1 neither app role can append to the ledger directly observed: {'sal_app': 'refused', 'sal_system': 'refused'} setup R5.0 three signed egress permits issued for the tool probe (setup: issuance is the operator's) pass R5.4 the tool network reaches neither the Slack stand-in nor the internet observed: {'sink_reachable': False, 'internet_reachable': False, 'executor_reachable': False, 'first': {'status': 200, 'body': {'formed': True, 'reason': 'admitted', 'actor': '172.22.0.3', 'external_status': 200}}, 'replay': {'sta... pass R5.4 ...nor the executor: only the effect broker (consequence-boundary plan phase 2a) observed: {'executor_reachable': False} pass R5.2 a valid capability presented by the tool delivers exactly one notification observed: {'status': 200, 'body': {'formed': True, 'reason': 'admitted', 'actor': '172.22.0.3', 'external_status': 200}} pass R5.3 the same capability again, an expired one and an oversized message are refused observed: {'replay': {'status': 200, 'body': {'formed': False, 'reason': 'capability already exercised at 2026-10-14 01:36:05.272440+00:00 — single use', 'actor': '172.22.0.3'}}, 'expired': {'status': 200, 'body': {'formed': False... pass R5.2 the Slack stand-in received exactly one capability-gated notification observed: egress=1 pass R5.2 every review raised a notification to the review channel, sent by the broker observed: review notifications=9 pass R5.5 the executor reaches neither the internet nor the Slack stand-in (core_net only) observed: {'internet': 'OSError', 'sink': 'gaierror', 'proxy_other_host': 'HTTP/1.1 403 Forbidden', 'holds_review_urls': [], 'proxy_ai_host': 'HTTP/1.1 200 Connection established'} pass R5.5 its egress proxy refuses any host but the AI provider's, and it holds no review address observed: {'proxy_other_host': 'HTTP/1.1 403 Forbidden', 'proxy_ai_host': 'HTTP/1.1 200 Connection established', 'holds_review_urls': [], 'error': None} pass R5.6 from inside the executor, each of 38 attacks is refused: route, database, its key alone, forgery, wider terms, replay observed: 38 refused pass R5.6 the operator's capability, signed with its exact terms and presented by the executor, forms exactly once; no direct post arrived observed: {'formed': ['admitted'], 'arrived': 1, 'direct': 0} pass R5.6 stated limits, recorded observed: ['it DOES hold the permit signing key (stated: so it can sign; steps 3 and 5 show what that is worth): PERMIT_SIGNING_KEY: present', "its one way out: a tunnel to the AI provider's host (what it sends there is not inspec... pass R5.7 from inside the executor, an approval no person gave, signed with a passkey of its own, gets no permit at all: it cannot issue one itself, and the broker verifies first and issues none (the passkey was never confirmed); ... observed: ['allowed bind an action to permits (rolled back here): facts the broker reads before it issues: sal_app: refused: permission denied for table cb_permit_bindings; sal_system: allowed (then NotNullViolationError)', 'allow... R6 LOAD pass R6.1 6 intents at once across six tenants all settle; /health never fails observed: settled=6/6 health_failures=0 statuses=['completed', 'failed'] R7 THE EVIDENCE setup R7.0 a drift scan runs observed: 200 pass R7.1 all 33 certificates the rehearsal produced verify, and are on record observed: failed: [] pass R7.1 a certificate with one field changed does not verify observed: {'valid': False, 'on_record': False, 'execution_id': '2564e5e5', 'instance_id': 'rehearsal', 'cle_verdict': 'PASS', 'outcome': 'released', 'signature': 'ed25519', 'ts': 1791941764, 'message': 'Certificate is invalid or h... pass R7.2 all 33 verify OFFLINE with the public key the instance publishes, and each says what became of its request observed: keys=['d67194f7ac5220c5'] failed=[] outcomes={'released': 25, 'rejected': 3, 'expired': 1, 'budget_refused': 2, 'blocked': 2} pass R7.3 every demo intent is in its own tenant's audit log, and nothing is filed under another tenant observed: misfiled=0 unaudited=0 pass R7.4 drift alerts from this run are filed under the tenant they measured observed: [] info R7.5 rule coverage: 8 of 25 enabled rule copies fired observed: never fired: 17 rule copies (their names, production's configuration, are left out) pass R7.6 the executor logged no errors during the run observed: 0 error line(s); raised: [] info R7.7 real-model spend stayed under the cap ($4.0) observed: $0.1434 pass R7.8 none of the 61 secrets the run made appears in the log or the report observed: [] R8 EACH COMPANY'S OWN GOVERNANCE (new: open item 30) pass R8.1 a tenant admin adds a principle for its own tenant alone observed: 201 {"id":"2ae5c424","principle_id":"RH-BILLING-B- ONLY","layer":"tenant","version":1} pass R8.2 it blocks that tenant's request, and the same request of another tenant on the same domain goes through observed: billing-b=failed clinic-a=completed pass R8.3 another tenant's admin neither sees it nor changes it (404) observed: {'put': 404, 'delete': 404} pass R8.4 a tenant's own tier rule routes that tenant's requests and no other's observed: rule=201 billing-b tier=[1] clinic-a tier=[2] pass R8.5 the violation is counted in that tenant's compliance report, not another's observed: billing-b=['RH-BILLING-B-ONLY'] clinic-a=[] pass R8.6 each tenant's cache statistics count its own entries only observed: {'demo-clinic-a': (6, 6), 'demo-billing-b': (4, 4)} ================================================================================ RESULT: 88 checks passed, 1 failed.