AI agents increasingly emit signed "receipts" for what they did: a tool call, a payment authorization, a policy check, wrapped in a canonicalized, content-addressed, signed record. The direction is right. The trap is reading a well-formed signed record as a true one.
A valid signature establishes something precise: the presented bytes verify under a particular public key. With a trusted binding between that key and an identified authority, it can also establish signer provenance. It does not establish that the action occurred, that it was authorized, or that the checks described in the record actually ran.
So I started decomposing an action receipt into four separately assessable properties:
- Envelope integrity and authenticated provenance — are the bytes intact, and is the signing key reliably bound to the claimed signer?
- Occurrence — did the action happen (and in which state: requested, attempted, completed, failed, settled)?
- Authorization — was it the action, with the exact parameters, that was authorized?
- Check execution and integrity — did the claimed checks run, or is "verified" a fail-open default?
Signing supports only the envelope property. The other three require independently verifiable evidence attributable to the relevant authorities: a checker, an authorization authority, and an execution authority. In the stronger design demonstrated here, each authority occupies a separate cryptographic trust domain, so the receipt emitter cannot manufacture their attestations.
The claim worth testing follows directly:
A format-valid, correctly signed receipt whose asserted claims are not semantically supported must be rejected.
I made that claim executable. Each authority receives a distinct Ed25519 keypair, while the verifier holds only the trusted public keys. The negative vectors include:
- a substituted checker result;
- a stale transcript;
- authorization bound to different parameters;
- an execution acknowledgment bound to a different action; and
- an emitter claiming a check for which it has no authority attestation.
The envelope signature verifies in every case. The claim-level verifier still rejects each receipt for a specific semantic reason.
This is a controlled demonstration, not a field evaluation. It complements formal-conformance and capability-binding research rather than replacing it. Those approaches test whether controls and capabilities are correctly defined or exercised. This demonstration tests a different boundary: whether the evidence artifact claims more than its supporting trace can prove.
The short methodology note is on Zenodo: 10.5281/zenodo.21418701 (record: zenodo.org/records/21418702). The reference verifier and the negative vectors are open source: github.com/msaleme/red-team-blue-team-agent-fabric (module protocol_tests/receipt_claim_harness.py).
Views my own.
Top comments (0)