Refusals need receipts

The agent standards wave is building proofs for everything an agent does. What an agent was stopped from doing leaves no record at all, and that silence is load-bearing.

Watch a policy gate run in front of an autonomous agent for a while and one pattern shows up early. A proposed payment gets refused, over cap. Two minutes later the same payment comes back just under a round number. Then it comes back split in two. Then it comes back described differently, same recipient, same intent. Nothing malicious is happening. A plan got stuck behind a refusal, and to the agent the refusal is indistinguishable from noise, so the planning loop does what planning loops do: it varies the action until something passes.

The part of this failure worth standardizing is not the cap. It is the memory. The third mutated re-proposal of a refused payment is not a new proposal, but only a system that remembers refusals can say so. If the deny leaves no record, the policy boundary becomes a search space, and the agent probes it for free.

That is the angle of this piece: refusals need receipts. The current wave of agent standards specifies, in real and increasing detail, how an agent proves who it is, what it may do, and what it did. What it was stopped from doing is recorded nowhere in the stack.

The proof stack, as it stands

This is not an abstract survey. It is what is being argued on the Ethereum Magicians forum right now, in threads that are live as I write.

ERC-8004 gives agents identity, reputation and validation registries: who is acting, and whether to trust it. ERC-8183 standardizes agent commerce: jobs, funding, expiry, settlement. ERC-8380 binds execution to spend-once credentials, so the second use of the same capability reverts. ERC-8354 proves, in zero knowledge, that an allow or deny verdict was computed faithfully against a policy that is never disclosed on chain. And a fresh pre-ERC draft, Recomputable Verification Receipts, wants verification results to be re-derivable: same claim, same evidence, same rules, same receipt.

Squint and the common shape is obvious. Authority is granted and provable. Execution is receipted and verifiable. The paper trail thickens toward the happy path, and every one of these designs is better than what preceded it.

Now ask a single question of each: where does a refused action go?

Three silences

In a confidential-verdict scheme, a deny is a proof that nobody submits. There is nothing pending, nothing on chain, and nothing in the spec that asks anyone to retain it. The deny does not happen anywhere.

In a credential scheme, the refusal is a revert. A revert that reaches a chain at least leaves a failed transaction behind, which is more than most refusals get. But the refusals that matter most are caught earlier, agent-side, before a transaction exists, and those leave nothing. A revert is transport, not memory.

In a commerce flow, refusal-shaped outcomes settle economically. An expired job becomes a refund. The record is the settlement, which preserves exactly what moved and nothing about why.

RVR is the closest thing to a counterexample, and it proves the appetite rather than closing the gap. It treats REFUTED as a first-class outcome and demands that a later reviewer be able to re-derive it. That is precisely the right discipline, pointed at the wrong end of the pipeline: it receipts claims about work after the fact. The pre-execution refusal, the moment a policy stops a transaction before it is born, has no receipt anywhere in the stack.

Why the silence is load-bearing

Three reasons, in increasing order of how expensive they get.

First, the retry loop from the opening. A policy with no refusal memory is an oracle. The agent queries it by proposing, reads the binary answer, adjusts, and proposes again. Detecting that pattern, three variants of one refused action inside ten minutes, requires history. Without records the defender cannot even ask the question, let alone rate-limit the search.

Second, the audit asymmetry. After an incident, review reads the logs of what executed. But the security posture of a gate is measured by its near misses: the interesting behaviour of a guardrail is what it stops. If receipts exist only for executions, an audit can establish what happened and nothing about what almost happened, which is the half the next attacker studies.

Third, ambiguity collapses. A two-value verdict set forces everything uncertain into allow, which is unsafe, or deny, which makes the agent useless. In practice the verdict that carries real operation is the third one: held, for a human. A hold is a refusal with a future. It is also the record that most needs integrity, because it must survive into the moment a person releases it: what exactly was proposed, which rule held it, who signed the release, and that the release was spent once and never again.

What a refusal receipt is

Nothing about this is exotic. A refusal receipt is a line in an append-only log: the identity of the action (a hash over recipient, spender, amount, asset, chain, class and nonce), the rule that fired, the verdict. Each line carries the hash of the line before it, so editing or deleting history breaks everything after the edit and verification can name the first broken line. Sign the lines and a third party holding only a public key can check the whole log without being trusted with anything else. Make the verifier exit non-zero on a broken chain and the audit trail becomes a CI step instead of a promise.

One tension deserves naming, because it decides whether this composes with confidential policies. A refusal record must not leak the policy. The receipt should say which rule class fired, not the predicate that implements it; a committed policy can commit to rule identifiers exactly as it commits to the rules. Record that, and a confidential-verdict scheme keeps its secrecy while gaining a memory.

I run this shape in practice: a local gate in front of an agent signer that writes allow, hold and block decisions to the same hash-chained log (pi-crypto-gate), and I went through its failing cases in an earlier piece. The point here is not the tool. The point is that refusal receipts are cheap, the discipline demonstrably exists in the ecosystem, and it is currently aimed only at what succeeded.

What the wave could adopt

Three moves, any subset of which helps, ordered by how much they buy.

Three-value verdict sets. Specify allow, hold and deny instead of allow and deny. In confidential schemes, hold can emit a commitment the approver opens out of band; the verdict stays private, the pending state becomes real.

Refusal entries in receipt schemes. RVR-style recomputability applies unchanged. Same content-addressed claim, evidence and profile identities; the result simply happens to be a refusal. A reviewer re-deriving why an action was stopped is as valuable as one re-deriving why a claim was verified.

Veto windows at the executor. An allow followed by an escrow period a human can interrupt. It composes with timelocks that already exist, and it is the weakest of the three, because the veto behaviour is observable and leaks the policy’s band boundaries. It is still better than silence.

The honest limit

A receipt stops nothing. A local log is only as durable as the machine it lives on, and an agent with unrestricted shell access can reach a log file the same way it reaches a key. None of this substitutes for the gate itself, and a gate on one host says nothing about the agent’s copy on another.

But the ungated agent is the today problem, and the unrecorded refusal is the tomorrow problem hiding inside the fix. The moment agent transactions are policed everywhere, the question shifts from whether the bad transaction was stopped to what the stopping looked like, at which rule, how often, and in what pattern. Refusals are where the policy meets the adversary. Give them receipts.