How can I prove to a client what my AI agent did?

By The Keelstamp team, PowerQuant ApS, Denmark · Last reviewed 30 September 2026

Answer: A log you control is your word against theirs. To make it checkable, record each action with a hash of the exact payload, chain every record to the one before it, publish the latest hash daily somewhere you don't control, and sign records with a key whose public half the client has. The client can then check a record without trusting you.

Why an execution log isn't proof

You can edit it, you can delete it, and it doesn't last: self-hosted n8n prunes execution data after 336 hours by default ^[1]. In a disagreement, the client can't tell an honest log from an edited one.

What each record needs

• Who approved or triggered it, as an ID rather than a name.
• What was done: the action type and a hash of the exact payload.
• When, in UTC.
• The decision: approved, rejected, expired or stopped.
• The hash of the previous record.

Chain, anchor, sign

1. Chain. Each record stores the previous record's hash. Change or delete an old record, and every hash after it stops matching.
2. Anchor. Once a day, publish the latest hash somewhere outside your control, such as a commit to a public git repository. Rewriting a published history is visible to anyone who has a copy.
3. Sign. Sign each record with an Ed25519 key ^[2] kept off the automation host, and publish the public key. Anyone can then verify a record without asking you.

The idea isn't new. Certificate Transparency publicly logs TLS certificates so anyone can check what was issued ^[3]. RFC 9943, from the IETF's SCITT working group, defines an architecture for signed statements, a transparency service that maintains a verifiable log of them, and receipts, which are signed proofs from that log ^[4]. It was written for digital supply chains, but the pattern carries over to agent actions.

Keep personal data out

Store hashes of content, not the content. Names, email addresses and amounts don't belong in a record that will be public or long-lived. If you need to match a person later, hash their ID with a secret salt per client, so the hashes can't be matched to people by guessing.

Disclosure: this page is written by the team building Keelstamp, a tool for verifiable receipts. It isn't released yet, and everything above works without it.