Proof

The send gate

This page shows one mechanism out of a production system: a staged pipeline in which the model reviewer holds withhold-only authority, so a prompt-injected model cannot authorize a send. Below are the pipeline, the excerpt that implements its last stage, and one Ed25519-signed attestation receipt. Take none of it on trust — the code is on the page, and the receipt is one command away from being checked on your own machine.

The pipeline

Solid boxes are deterministic code: the same input yields the same decision, and nothing written in the inbound message changes it. Dashed boxes are model calls. Read the arrows rather than the boxes — no dashed stage has an exit that reaches the wire, and the reviewer’s only authority is to withhold. The one arrow that reaches the wire leaves a solid box.

The send pipeline, stage by stageAn inbound message passes through deterministic, input-independent gates and three model calls — the third a fresh-context review whose only authority is to withhold — before the deterministic wire-openers: recipient allowlist, daily cap, ledgered autonomy grant. That solid stage is the only one whose exit reaches the wire, where the send happens and an Ed25519-signed receipt is written. No model call can authorize a send.deterministic code — input-independentmodel call — cannot authorize a sendinbound messagedeterministic gatesinput-independent checksstopmodel call #1cannot authorize a sendstopmodel call #2 — draftcannot authorize a sendstopdeterministic gatesinput-independent checks on the draftstopmodel call #3 — fresh-context reviewverdict · claims · data boundary · injectionexits: pass along, or WITHHOLDwithholddeterministic wire-openersrecipient allowlist · daily capledgered autonomy grantpark / blocksend + Ed25519-signed receiptNo dashed stage has an exit that reaches the wire.The arrow that opens the wire leaves a solid box.

The last stage, in twenty lines

# ---- model call #3: fresh-context review (defanged inbound) ----
verdict = review(artifact, defang(msg.body), slug)
write_verdict_files(verdict, artifact)
if not verdict.all_pass():
    ledger.mark_error_presend(msg.key, "review-fail")
    return {**base, "action": "review-fail", "outcome": "verdict-not-all-pass"}

# ---- dry-run stops here ----
if not send:
    return {**base, "action": "drafted", "outcome": "dry-run", "verdict": "PASS"}

# ---- gate (only with --send) ----
if not allowlist_ok(msg.sender):
    return {**base, "action": "blocked", "outcome": "recipient-not-allowlisted"}
if ledger.sent_today_count() >= DAILY_CAP:
    return {**base, "action": "cap-parked", "outcome": "daily-cap"}
if not reply_send_allowed():
    handoff(msg, "reply-autonomy-not-granted (Tier 2: human releases from pending/)", cls)
    return {**base, "action": "parked", "outcome": "reply-autonomy-not-granted"}
mid = gate_and_send(artifact, msg.key, msg, ledger)
return {**base, "action": "sent", "outcome": "ok", "verdict": "PASS"}

and the verdict contract it calls

def all_pass(self) -> bool:
    return self.verdict == self.claims == self.data_boundary == self.injection == "PASS"

Excerpted from the production responder; logging, CRM and ledger bookkeeping, and per-return metadata fields are elided. The control flow is unaltered. All four review axes — verdict, claims, data boundary, injection — must read PASS, and a PASS is necessary without ever being sufficient: everything downstream of it is a deterministic gate on the recipient allowlist, the daily cap, and a ledgered autonomy grant. That is the whole point of the arrangement. The reviewer’s authority is withhold-only, so a prompt-injected model can stop a send and can never cause one.

One receipt

Every governed action — send, handoff, block — emits an attestation receipt in this format: append-only, vendor-neutral, independently verifiable, and chained to the action before it by the up field. One attestation format is shared by the agent and the product gateway.

{"v":1,"seq":0,"account_id":"acct-demo","agent_id":"demo-agent","vendor":"generic","model":"","action":"email.send","decision":"allow","input_tokens":0,"output_tokens":0,"cost_usd":0,"dlp_result":"clean","threat_type":"","trust_score":100,"ts":"2026-08-24T02:37:15.000Z","up":"genesis","signature":"f19aa9818c2fd6f1b26e7ec86d8de216b5c989afae6b8fde06309a7924531ff050322d3ad655c1d5b8b83b6bc2a99ff6eb829f97d397da7c7da293ecae53dc09"}

public key (hex)28eab78449b89099648c17c1383d0a2b622ff2c0f38a52c685a889896ade2c16

Download the receipt

A demonstration receipt in the production attestation format. It was minted at build time with a single-use demo key and really signed — the hex above is a genuine Ed25519 signature over the fields that precede it, which is why the command below succeeds. It is an example of the format, not a live production record: the account, agent and vendor values are inert placeholders and the chain starts at genesis.

Verify it yourself

# 1. save the receipt beside you (the download link is above)
# 2. pip install pynacl
python -c "import json,sys; from nacl.signing import VerifyKey; r=json.load(open(sys.argv[1])); sig=bytes.fromhex(r.pop('signature')); msg=json.dumps(r,separators=(',',':'),ensure_ascii=False).encode('utf-8'); VerifyKey(bytes.fromhex(sys.argv[2])).verify(msg,sig); print('OK: signature verifies')" sample-receipt.json 28eab78449b89099648c17c1383d0a2b622ff2c0f38a52c685a889896ade2c16

The signature covers the canonical serialization of every field above it, so any edit to the receipt — one digit of trust_score, one character of the timestamp — makes this command fail instead of printing OK. A missing library is a different failure: without pynacl installed you get an import error, not a bad signature.