NOTE (added 13 October 2026): superseded by 2026-10-13-executor-compromise.txt. In this run the database issued a permit for the approval the executor forged (step 6), and only the broker refused it when presented. A reader asked why invalid authority produced a permit at all. Since 13 October it does not: the broker verifies the approver's signature before it issues any permit. The log below is unchanged. -------------------------------------------------------------------------------- ARBITER: the consequence boundary, attacked from inside the executor A real run on production (sovereignarbiter.com), 12 October 2026, 21:44 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: 37 attempts refused, 1 effect formed, 0 failures. 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. Step 6 is new: the executor forged a person's approval of a permit to move 48,000.00, signed it with a passkey it registered itself, and ARBITER issued the permit. The broker, the only service that can move the money, refused it: a permit from a review moves only with the approver's passkey signature, by a passkey the operator confirmed on the server, which nothing in the executor can do. The operator then revoked the executor's passkey. 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 e520e0961c0f4b593c177be5c5ba2f69641c84c3e3ae694dd7b048c36d43a6c3 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 43b04c70-2c91-4e51-bc88-898bc231d3b6: gate release-window, at most 200 characters, until 2026-10-12T21:54:05.205767+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 0dbdb1a8-d63b-43c2-9eb7-3d0c21811911: 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-12 21:44:05.810594+00:00 — single use 6. A forged approval (plan phase 3) ALLOWED bind an action to permits (rolled back here): what the permit function trusts 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): what the permit function trusts 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 asks ARBITER for the permit that approval would issue the approval was not signed with a passkey on the person's own device ALLOWED it registers a passkey of its own passkey 58a0e407bbb583a3: 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: now ARBITER issues the permit issued: 48000.0 from BOUNDARY-PROOF-1 REFUSED it signs that permit with ARBITER's key and presents it: the broker moves nothing the approving passkey was never confirmed by the operator: nothing moves 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 ------------------+--------------+--------------------------- 58a0e407bbb583a3 | the executor | revoked: it signs nothing (1 row) Receipts: every presentation this run made to the broker ──────────────────────────────────────────────────────────────────────────── 21:44:05 REFUSED seq 97 no such capability — nothing was minted for this movement 21:44:05 REFUSED seq 98 the permit is not signed by ARBITER (its signature does not verify): nothing moves 21:44:05 REFUSED seq 99 the permit is not signed by ARBITER (its signature does not verify): nothing moves 21:44:05 REFUSED seq 100 message is 201 chars, capability ceiling is 200 21:44:05 PENDING seq 101 capability claimed — external call in flight 21:44:05 ADMITTED seq 102 lawful continuation: capability valid, standing resolved under current conditions 21:44:05 REFUSED seq 103 capability already exercised at 2026-10-12 21:44:05.810594+00:00 — single use 21:44:05 via arbiter_broker REFUSED seq 77 no such capability — nothing was minted for this movement (ledger) 21:44:05 via arbiter_broker REFUSED seq 78 the approving passkey was never confirmed by the operator: nothing moves (ledger) The sanctioned effect in the anchored chain ──────────────────────────────────────────────────────────────────────────── This run's last eb_attempts receipt is at chain sequence 103. Waiting for the anchor sidecar to copy a head at or past it to write-once storage (S3, Object Lock): -> anchored eb_attempts seq=103 anchors/eb_attempts/00000000000000000103-20261012T214410860058Z.json Every receipt, recomputed from the database (what the hourly health check runs): PASS cb_attempts: 78 receipt(s), head at sequence 78 PASS cb_ledger: 12 receipt(s), head at sequence 12 PASS eb_attempts: 103 receipt(s), head at sequence 103 PASS priv_attempts: 3 receipt(s), head at sequence 3 PASS audit_log: 937 receipt(s), head at sequence 937 PASS execution_certificates: 28 receipt(s), head at sequence 28 Result ──────────────────────────────────────────────────────────────────────────── Attacks refused: 37 Effects formed: 1 (by the sanctioned capability) Failures: 0 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, sign the approval with it and have ARBITER issue and sign the permit -- and that permit moves nothing: the broker checks the approval's signature against passkeys the operator confirmed on the server, which nothing in the executor can confirm, and refuses. The attempt is a receipt; 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.