ARBITER: the consequence boundary, attacked from inside the executor A real run on production (sovereignarbiter.com), 13 October 2026, 22:37 UTC ================================================================================ WHAT THIS IS ARBITER sits between AI agents and the effects they can cause. Its executor is the part that reads untrusted input and calls the AI model, so it is the part most likely to be made to run an attacker's code. This run IS that code: a program run inside the production executor, as its own user, with its full environment, its database login and the key it signs permits with, and handed the real webhook credentials. It tries every way to an effect it can name. Every attempt is printed with the system's answer. RESULT: 38 attempts refused, 1 effect formed, 0 outcomes other than the design predicts. The one effect is the sanctioned one: a capability the operator wrote, signed with its exact terms, which sent one message to a Slack channel kept for this test. Its receipt is hash-chained and was copied to write-once storage (S3 Object Lock) about five seconds later. WHAT CHANGED SINCE THE 12 OCTOBER RUN (step 6) A reader of the 12 October run asked why invalid authority produced a permit at all. It had: the executor forged a person's approval with a passkey of its own, the database issued the permit, and only the broker refused it when it was presented. That was the right question. Since 13 October nothing the executor can reach creates a permit: the broker, the one service that can move the money, reads the request, verifies the approver's signature against passkeys the operator has confirmed, and only then issues the permit, under its own key. In this run the executor forged the same approval and asked the broker; the broker issued nothing, and the refusal is on record. "0 outcomes other than the design predicts" is a test result, not a claim that nothing upstream can be forged: step 6 shows what the executor can still forge, and what that gets it. The 12 October log stays published: 2026-10-12-executor-compromise.txt WHAT IT DOES NOT SHOW (also at the end of the log) - The executor serves the page where a person approves, so it could show them one amount while their device signs another. It cannot sign without them. - A new passkey signs once the operator confirms it: a moment of trust. - What the executor sends to the AI provider is not inspected. - It words the review notices sent to the company's own review channel. - A shell in the database or the broker, or root on the host, is outside this test. - No customer uses ARBITER yet. The money is a demonstration ledger, and step 6's records live in a company set up for this proof only, switched off. EDITED FOR PUBLICATION Container names and private network addresses are replaced by their role (, , ...). Nothing else is changed. The unedited log stays on the server; its SHA-256 is 6e0a96bacb13e9ef5e98ebe8ab427efdf1674108914f2746f912b53d665c5453 Jerry McClintock, Consequence AI Systems · jerrymcclintock@sovereignarbiter.com Try it yourself: https://demo.sovereignarbiter.com/ ================================================================================ The operator writes one capability (as the table owner, outside the executor) ──────────────────────────────────────────────────────────────────────────── capability 93d4922c-9ad6-424c-97ac-a64d722f05f9: gate release-window, at most 200 characters, until 2026-10-13T22:47:33.036647+00:00 It is unsigned. Only the executor's key can sign it; the broker moves nothing without that. The operator stages a request held for a person's review (company 'boundary-proof') ──────────────────────────────────────────────────────────────────────────── review e2f498b3-fae5-4dab-a587-c7768d4c5992: 48000.00 from BOUNDARY-PROOF-1, approved by no one yet Inside the executor: its user, its environment, its login, its key ──────────────────────────────────────────────────────────────────────────── runs as uid 10001, database login arbiter_executor 0. What it holds OK it holds no effect credential (the egress demo's and the review channel's webhook addresses are the broker's) holds: none OK it signs in to the database as its own login, which owns nothing login: arbiter_executor LIMIT 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 1. Handed the real credentials: the route REFUSED handed the egress demo webhook, it posts directly: no route ConnectError REFUSED handed the egress demo webhook, it posts through its proxy settings: no route ProxyError REFUSED the egress proxy refuses a tunnel to the egress demo webhook's host HTTP/1.1 403 Forbidden REFUSED handed the review channel's webhook, it posts directly: no route ConnectError REFUSED handed the review channel's webhook, it posts through its proxy settings: no route ProxyError REFUSED the egress proxy refuses a tunnel to the review channel's webhook's host HTTP/1.1 403 Forbidden REFUSED an address on the internet, directly OSError REFUSED the tool's network (it is not on it) gaierror 2. The database, as its own login (every attempt rolled back) REFUSED append to the ledger, as either of its roles sal_app: refused: permission denied for table cb_ledger; sal_system: refused: permission denied for table cb_ledger REFUSED write a ledger permit, as either of its roles sal_app: refused: permission denied for table cb_capability_grants; sal_system: refused: permission denied for table cb_capability_grants REFUSED re-open a spent ledger permit, as either of its roles sal_app: refused: permission denied for table cb_capability_grants; sal_system: refused: permission denied for table cb_capability_grants REFUSED write an egress capability, as either of its roles sal_app: refused: permission denied for table eb_grants; sal_system: refused: permission denied for table eb_grants REFUSED re-open a spent egress capability, as either of its roles sal_app: refused: permission denied for table eb_grants; sal_system: refused: permission denied for table eb_grants REFUSED open a closed gate, as either of its roles sal_app: refused: permission denied for table eb_gates; sal_system: refused: permission denied for table eb_gates REFUSED add a receipt of its own, as either of its roles sal_app: refused: permission denied for table eb_attempts; sal_system: refused: permission denied for table eb_attempts REFUSED rewrite a receipt, as either of its roles sal_app: refused: permission denied for table eb_attempts; sal_system: refused: permission denied for table eb_attempts REFUSED delete a receipt, as either of its roles sal_app: refused: permission denied for table cb_attempts; sal_system: refused: permission denied for table cb_attempts REFUSED move a chain head, as either of its roles sal_app: refused: permission denied for table receipt_chain_heads; sal_system: refused: permission denied for table receipt_chain_heads REFUSED rewrite an audit receipt, as either of its roles sal_app: refused: permission denied for table audit_log_receipts; sal_system: refused: permission denied for table audit_log_receipts REFUSED call the payment function itself, as either of its roles sal_app: refused: permission denied for function cb_exercise; sal_system: refused: permission denied for function cb_exercise REFUSED call the broker's payment function, as either of its roles sal_app: refused: permission denied for function cb_exercise_as; sal_system: refused: permission denied for function cb_exercise_as REFUSED record a refusal as the broker, as either of its roles sal_app: refused: permission denied for function cb_refuse; sal_system: refused: permission denied for function cb_refuse REFUSED become sal refused: permission denied to set role "sal" REFUSED become arbiter_broker refused: permission denied to set role "arbiter_broker" REFUSED become receipt_anchor refused: permission denied to set role "receipt_anchor" REFUSED become sal_backup refused: permission denied to set role "sal_backup" 3. Its signing key alone REFUSED it signs an egress capability no operator wrote, with the real key no such capability — nothing was minted for this movement REFUSED it signs a ledger permit for $1,000,000 nobody issued, with the real key no such capability — nothing was minted for this movement 4. Forgery REFUSED the operator's real capability with a made-up signature the permit is not signed by ARBITER (its signature does not verify): nothing moves REFUSED its real signature over terms altered afterwards (a longer message) the permit is not signed by ARBITER (its signature does not verify): nothing moves 5. The sanctioned path, presented by the executor REFUSED it signs WIDER terms than the operator wrote: the row's bound still holds message is 201 chars, capability ceiling is 200 FORMED the operator's capability, signed with its exact terms: the one effect admitted REFUSED the same capability again capability already exercised at 2026-10-13 22:37:33.655982+00:00 — single use 6. A forged approval (plan phase 3) 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) ALLOWED say which company owns an account (rolled back here): facts the broker reads before it issues sal_app: refused: permission denied for table cb_account_owners; sal_system: allowed (then NotNullViolationError) ALLOWED its roles record the staged review as approved by a person, and the request as completed written REFUSED it issues the permit itself, with the broker's issuing function, as either of its roles sal_app: refused: permission denied for function cb_permit_issue_verified; sal_system: refused: permission denied for function cb_permit_issue_verifie ALLOWED it registers a passkey of its own passkey 35e56348c905b2f2: pending, the operator is alerted REFUSED it confirms that passkey itself, as either of its roles sal_app: refused: permission denied for table approver_keys; sal_system: refused: permission denied for table approver_keys ALLOWED it signs the approval's exact terms with that passkey, and stores the signature stored REFUSED it asks the broker for the permit: the broker verifies the signature first, and issues none the approving passkey was never confirmed by the operator: nothing moves REFUSED so no permit exists for that request: there is nothing to sign or present permits: 0 7. Stated limits (shown, not hidden) LIMIT its one way out: a tunnel to the AI provider's host (what it sends there is not inspected) HTTP/1.1 200 Connection established The operator revokes the passkey the executor registered ──────────────────────────────────────────────────────────────────────────── fingerprint | username | now ------------------+--------------+--------------------------- 35e56348c905b2f2 | the executor | revoked: it signs nothing (1 row) Receipts: every presentation this run made to the broker ──────────────────────────────────────────────────────────────────────────── 22:37:33 REFUSED seq 104 no such capability — nothing was minted for this movement 22:37:33 REFUSED seq 105 the permit is not signed by ARBITER (its signature does not verify): nothing moves 22:37:33 REFUSED seq 106 the permit is not signed by ARBITER (its signature does not verify): nothing moves 22:37:33 REFUSED seq 107 message is 201 chars, capability ceiling is 200 22:37:33 PENDING seq 108 capability claimed — external call in flight 22:37:33 ADMITTED seq 109 lawful continuation: capability valid, standing resolved under current conditions 22:37:33 REFUSED seq 110 capability already exercised at 2026-10-13 22:37:33.655982+00:00 — single use 22:37:33 via arbiter_broker REFUSED seq 79 no such capability — nothing was minted for this movement (ledger) The broker's decision on the forged approval (step 6, from the audit log) ──────────────────────────────────────────────────────────────────────────── 22:37:33 permit_not_issued the approving passkey was never confirmed by the operator: nothing moves No permit was issued for it, so there is nothing to present: no ledger receipt for it above. The sanctioned effect in the anchored chain ──────────────────────────────────────────────────────────────────────────── This run's last eb_attempts receipt is at chain sequence 110. Waiting for the anchor sidecar to copy a head at or past it to write-once storage (S3, Object Lock): -> anchored eb_attempts seq=110 anchors/eb_attempts/00000000000000000110-20261013T223738703295Z.json Every receipt, recomputed from the database (what the hourly health check runs): PASS cb_attempts: 79 receipt(s), head at sequence 79 PASS cb_ledger: 12 receipt(s), head at sequence 12 PASS eb_attempts: 110 receipt(s), head at sequence 110 PASS priv_attempts: 3 receipt(s), head at sequence 3 PASS audit_log: 944 receipt(s), head at sequence 944 PASS execution_certificates: 28 receipt(s), head at sequence 28 Result ──────────────────────────────────────────────────────────────────────────── Attacks refused: 38 Effects formed: 1 (by the sanctioned capability) Outcomes other than the design predicts: 0 (a test result, not a claim that nothing upstream can be forged: step 6 shows what the executor can still forge, and what that gets it) A shell inside the executor holds no credential for any effect, and handed the real ones it has no route to use them: its network reaches the database, the broker and a proxy that opens the AI provider and nothing else. Its database login can write no ledger row, permit, capability, gate or receipt, call no payment function and become no other role. Its signing key moves nothing without a row an operator wrote, and cannot widen that row's terms. The one effect formed through the broker, receipted, chained and anchored where nothing on this host can rewrite it. Since plan phase 3 (step 6) it can still record an approval no person gave, register a passkey of its own and sign the approval with it -- and no permit comes of it. It cannot issue a permit itself; only the broker issues permits from reviews, and only after verifying the approver's signature against passkeys the operator confirmed on the server, which nothing in the executor can confirm. The refusal is on record; the passkey alerted the operator (health_watch check 18) and is revoked. Stated limits. (a) It serves the dashboard, so while a person is approving it could show them one amount and have their device sign another: a passkey signs a challenge, it does not display it. It cannot sign without a person approving at that moment. (b) Registering a passkey is a moment of trust: the operator confirms it from its fingerprint and who registered it when. (c) It reaches the AI provider, and what it sends there is not inspected. (d) It can send review notices of its own wording to the company's own review channel. (e) A shell in the broker or the database container, or root on this host, is outside this proof; anchored history stays checkable against the write-once copies.