What is proven — and what is not

• The payload with this hash was screened by the detector with this verifying key, under the policy with this root.
• The deterministic layer (L1 regex rules, as committed DFAs) found it clean. A proof cannot exist for a payload L1 flags.
• The screening is bound to one on-chain action — program, instruction, signer, recipient, mint, amount — and to an expiry slot and a fresh nonce.
• On chain: the attestation was consumed once. A second use fails.

• L2 (embeddings) and L3 (model judge) verdicts. They are recorded in the audit log and can be run in a TEE (planned); their output is not inside the proof.
• The content of the audit log itself. The chain proves integrity and order of entries, not that an operator ran every call through the proxy.

• Traffic that does not pass through the proxy.
• Novel attacks the deterministic rules miss. On the published red-team corpus the proven layers alone catch roughly a third of attacks and little of the novel holdout set; detection in practice leans on L2/L3, which are attested rather than proven. The numbers are in packages/LIMITATIONS.md and are updated with every corpus change.
• The correctness of the gated program beyond the fields it forwards. Blindseal checks that the forwarded action equals the screened one; it does not audit the program.
• L0 decode-then-L1 is run by the proxy but is not yet inside the guest; the proof covers L1 on the payload as received. In-guest L0 is the next increment and will change the detector version.

Six hashes and a slot number. No prompt, no tool arguments, no policy contents or thresholds, no model scores, and nothing that names the agent or the operator. The explorer shows counts and policy roots only.

Both on-chain programs — the verifier merZNYKpKwwX4CGgzvma3jPvLfrMTkZcb1cSXUKANcb and the transfer-gate example ErAS5x2oUky3aCJPasSKNaf8USVE9of5vzHHCPWwSEVG — keep an upgrade authority, held today by a single key. Whoever holds it can change what the verifier accepts; the integrity of past consumptions is unaffected, but a verifier you trust is a verifier whose authority you trust. Every upgrade so far is listed with its signature in the repository, and solana-verify lets you check that the deployed bytes match the public source.

Planned: the authority moves to a Squads multisig with a timelock, and the program ids stay the same. Until then, treat the single key as the trust root it is.