Prove the approval happened.

Every AI governance policy says the same thing: a human reviews the important decisions. The payment over the limit, the refund outside policy, the contract clause the model was unsure about. Somewhere in the deployment documents there is a sentence promising that a person signs off before the agent acts.

Now an auditor points at one specific payment and asks the question the policy was written for: prove it for this one.

Today the honest answer at most companies is a screenshot. Or an exported chat log, or a ticket that says "approved per Slack," or a query against the agent platform's own database. Attestation by screenshot, audit by log archaeology: digging through records written by the same system being investigated, none of which would survive a hostile question about tampering. The policy claims oversight. The evidence for any particular act of oversight is whatever happened to be lying around.

An approval should be a signature

In a Sequesign receipt, a human approval is not a log line. It is a cryptographic signature, made with the approver's own key, over a canonical message that names the task, the type of action being authorized, and a hash of the context the approver agreed to. The verifier holds the approval to that binding: an approval signed for a different task, or for an action type that never occurred in the chain, fails verification outright. The actions themselves live in a signed hash chain, countersigned as the work happened by an independent witness that never sees the underlying content. The whole thing travels as one artifact, and anyone holding it can verify it offline, without contacting Sequesign or anyone else.

So when the auditor points at the payment, the answer is no longer archaeology. The receipt either contains a valid approval signature covering that task's payment instruction, or it does not. If someone altered the evidence afterward, the verifier fails loudly and says which action broke. If the workflow was supposed to include an approval and the agent skipped it, a profile-constrained receipt fails validation for exactly that reason.

Two states, honestly labeled

Here is the part most verification stories skip, and the part we think matters most. When the verifier finds an approval, it reports one of two states.

present_unverified means the approval signature is valid and correctly bound to the action, but the verifier cannot confirm who holds the signing key. The signature says "someone with this key approved this action." It does not, by itself, prove that key belongs to the Brent your records say approved it. This is what you get out of the box, and the verifier refuses to dress it up as more than it is. Run our invoice demo and the verification summary reads:

Sequesign verification PASSED
Level: L3_POLICY_BOUND
Identity: self-asserted (unregistered)
Mode: profile_constrained
Profile: sequesign.invoice_payment.v0.1
Schema validation: PASSED
Workflow validation: PASSED
Witness: verified
Approval: present_unverified

present_verified is the stronger state. The approver has enrolled their key with the platform, proving they control it, and the platform issued a signed identity proof binding that key to a named identity and role. The proof travels inside the receipt, so a reviewer can check it offline against the platform's published key. Registered-key vouching is the bridge between the two states: same approval, same signature, but now the "who" is cryptographically vouched rather than asserted.

The gap between those two states is not a weakness of the protocol. It is the protocol telling you the truth. Most audit tooling collapses "an approval record exists" and "this named person approved it" into one checkbox. A reviewer deserves to know which of the two they are looking at, because only one of them survives the follow-up question.

What this does not prove

A receipt with a verified approval proves that the approval signature exists, is valid, is bound to the task and the approved action type, and was made with a key vouched for a named identity. Be precise about the granularity: in a workflow with several actions of the same type, the approval binds to the type within the task, not to one action record among them, so workflows that need per-action sign-off should give those actions distinct types. It also does not prove the approver read the invoice carefully, understood it, or approved wisely. No cryptography proves diligence, and we will not pretend otherwise. What the receipt does is convert the vague claim "a human was in the loop" into a specific, checkable fact: this person's key signed off on this kind of action, for this task, before the agent proceeded, in a chain nobody has rewritten since.

That conversion is the difference between a policy and a record. Policies describe what is supposed to happen. Receipts are how you answer for what did.

Try the live demo.Read the trust model.What a receipt actually proves