The consensus arrived fast. A year ago the answer to "how do you audit an AI agent?" was a database table nobody could vouch for. Now the field is converging, independently and correctly, on something better: sign the agent's actions. Hash each one, chain it to the last, seal the chain with a signature, hand the auditor a receipt. Open protocols for it are appearing (for example, an individual IETF draft); reference implementations are shipping (Microsoft's Agent Governance Toolkit signs each MCP tool call); and the building blocks (a signature, SHA-256, a canonical encoding, an offline verifier) are the same boring, correct ones everywhere you look, including here. This is progress, and none of what follows says otherwise.
But the word signed starts to do too much work. In the pitch it means "you can trust this record." Pressed by an auditor, it splits into three separate guarantees that are routinely spoken as if they were one. All three are real and worth having, and each has a different price. Confusing them is how a genuinely good receipt gets oversold into something an evaluator can dismantle with one question.
The three claims
Integrity: "this receipt was not altered after it was issued, and this key issued it." This is what the signature and the hash chain give you. Editing a past event breaks the chain at that exact event, deleting one leaves a gap in the sequence, inserting one breaks the link, and a chain recomputed without the signing key no longer matches the signed checkpoints. This is a strong property, and most receipt systems have it. It is also the one people quietly inflate into the other two.
Trustlessness: "you can verify this without trusting the party that produced it." This does not fall out of a signature. A signature proves a key signed the bytes; it says nothing about whether the holder of that key is someone you should trust. If the vendor holds the signing key, "signed by the vendor" and "trust the vendor" are the same sentence with extra steps. A customer-held key limits the blast radius (the vendor signs only through access you granted and can revoke), but the operator holding the key can still, in principle, rewrite history and re-sign it. Trustlessness requires a signer or an anchor the record-keeper does not control: an external ledger, a party with no incentive to help, or an independent timestamp authority, which stops backdating but catches a rewrite only for someone who kept the earlier timestamp. Until something like that is in the path, "verifiable" means "consistent with a key the issuer holds," and a verifier who distrusts the issuer gets no more than that.
Veracity: "this receipt reflects what the system actually did." No cryptography provides this one, and buyers most often assume they are getting it. A receipt is a statement about an action. Signing it makes the statement tamper-evident; it does nothing to make the statement true. If the receipt is generated from something other than the real execution (an observation, a re-description, a hopeful summary), you have a perfectly signed, perfectly verifiable record of a claim that may not match reality. Veracity comes from where the receipt is derived from.
A test you can run on any receipt
Each claim has a one-line test, and asking costs nothing.
For integrity: if someone edits one past record, does the verifier fail at that exact record, offline, on a machine you control? For trustlessness: who holds the key, and can the party that produced the record also re-sign it? If the issuer holds it and can re-sign, you have integrity without trustlessness, whatever the marketing says. For veracity: is the receipt written by the system as part of the action itself, or by something watching the system?
Most receipt systems pass the first cleanly. The honest ones tell you plainly where they stand on the second. Almost nobody names the third, and it decides whether the record is evidence or a signed opinion.
Observed at the boundary, or written with the action
The veracity question turns on a design choice that is easy to miss, because both answers produce a valid signed receipt.
One approach records the receipt at the tool-call boundary: a proxy or a hook between the agent and its tools, capturing each call as it passes. It is portable and agent-agnostic, working with any framework, any model and any runtime, because it observes the seam instead of living inside the engine. A runtime-bound record does not have that virtue. What a boundary receipt attests, precisely, is that the boundary observed this call.
The other approach writes the receipt as part of the execution itself. Here, the chained event is the state machine's own transition record, committed in the same database transaction as the machine's own state: either both are written or neither is, so the chained record and the machine's state cannot tell two different stories. The cost is the reverse of the boundary's virtue: this record is specific to the runtime that emits it, and no other agent can produce it.
Neither is strictly better. One trades fidelity for portability, the other portability for fidelity. The mistake is to let a boundary receipt borrow the language of the other kind and imply it proves what the system did. It proves what the boundary saw, which is often enough, and the gap matters in the cases where what the system did is the question.
The honest limits
Integrity is tamper-evident. A privileged operator can still alter a chained row, and anyone who verifies it against the signed checkpoint that covers it will detect it, unless whoever altered it also holds the signing key (the next point). Anyone calling a store an operator can write to "immutable" or "tamper-proof" is overselling.
Trustlessness depends on where the key lives, and we say so. Run the deployment yourself and the operator is you: the signing key is a KMS key in your own AWS account, the vendor holds no signing material, and "verifiable without trusting the vendor" is literal. (We offer that deployment to design partners; it has not run in production yet.) Let a vendor host it and the honest claim narrows to tamper-evident and independently verifiable offline, because a privileged operator could rewrite and re-sign before a third party captured a checkpoint. A production deployment is also required to have its checkpoints timestamped by an independent RFC 3161 authority, and the verifier states whether a bundle carries such an anchor; a bundle without one is reported as "self-asserted time only." An anchor stops anyone backdating a record, but it exposes a rewrite only to someone who already holds an earlier timestamp, so the hosted gap narrows and stays open.
Veracity comes from derivation, and only as far as the system recorded. A record written with the action proves it matches what the system did with that action. It cannot attest to an event the system never emitted. Here, a state-machine transition and its chained event commit in one transaction; a flow step's event is written just after the step commits, so a lost write is possible, and it is counted and logged (and, on flows that declare an audit-trail constraint, reported); refusals and binding rejections are recorded outside the chain. That is fidelity between record and behavior, bounded by what the system emitted.
The stakes
A signed receipt answers a compliance questionnaire. The three questions answer an adversary, and the adversary eventually shows up: an auditor reconstructing an incident, or your own counsel deciding whether to put the record in front of a regulator. "Is it signed?" is the least of what they ask; they ask some version of all three at once: can I check this without trusting you, could you have changed it, and is it what the system actually did? A record that conflates the three has one answer for three questions and loses the room on the first follow-up. A record that separates them (this part is integrity, this part depends on who holds the key, this part comes from the execution) sounds less impressive at first and still has an answer for each follow-up.
The verifiers are open source, Apache-2.0, on npm (@zarel-ai/audit-chain, @zarel-ai/audit-tsa), and How it works shows the commands an auditor runs against a deployment's bundle and the verdicts they can return. There is no public deployment to run them against yet.
This sharpens the proof layer of a broader line: communication and proposal may be probabilistic, but authority, consequence, compliance, and the record of all three must be deterministic, declared, and verifiable. The general argument is in You can't fight probabilism with probabilism; the enforcement case is in The agent proposes; the runtime presses the button; the record itself is in Audit you don't have to trust. This piece is about what "verifiable" is allowed to mean.
Nicolás Moreno builds Zarel: governed AI operations, where the AI proposes and the contract decides.