A signed receipt for AI work should prove that an identified signer bound itself to a specific, integrity-protected record of a run. It can show configuration, evidence references, actions, review, and a claimed outcome. It cannot prove that the sources were true, the action was authorized, or the real-world result occurred merely because the signature validates.
Design the receipt for an independent verifier. That person should be able to determine what task was requested, which policy and version applied, which artifacts were used, what the agent attempted, what changed, who reviewed it, and which claims remain outside the receipt.
Record the execution boundary
Include a stable receipt identifier, issuing system, authenticated agent identity, operator or requester where appropriate, task identifier, timestamps, environment, model and configuration, prompt or instruction hash, tool allowlist, and policy version. Separate caller-provided labels from identities asserted by the platform.
Reference inputs with canonical identifiers and cryptographic hashes. For sensitive material, the receipt can retain a hash and controlled pointer rather than raw content. State the normalization method, otherwise two equivalent files may produce records that cannot be compared.
The trust checklist for confident agent output supports questions about evidence and authority. A signed receipt should preserve those answers, but the checklist does not define a cryptographic format.
Describe actions and claimed completion
List tool calls, relevant arguments or argument hashes, authorization decision, target system, operation identifier, response class, retries, and final state. Redact secrets without removing the evidence needed to distinguish an allowed action from an attempted one.
Do not write completed when the only evidence is an accepted API request. Distinguish proposed, authorized, attempted, acknowledged, committed, independently observed, and later reversed. Link the completion claim to the strongest available artifact and name the observer.
Include validation results, exceptions, human review, and unresolved warnings. The article on checking invented agent metrics is relevant because a receipt must preserve denominator and scope rather than signing an ambiguous percentage.
Hash the output and any attached report. If the receipt summarizes several artifacts, use a manifest or Merkle structure so a verifier can confirm inclusion without receiving every sensitive item. Define which fields are mutable annotations and which are covered by the signature.
Make signature verification operational
Specify the signature algorithm, key identifier, issuer, certificate or public-key discovery method, signing time, receipt schema version, and canonical serialization. Publish key rotation and revocation behavior. A signature that cannot be checked after rotation is weak operational evidence.
Protect against replay and substitution. Bind the receipt to the task, environment, target, operation, and nonce where required. Define whether a correction creates a new receipt that references the old one or invalidates a prior claim. Never silently overwrite the signed record.
The verified-completion release documents one product mechanism for carrying completion evidence. It is relevant implementation context, not proof that another receipt format or client action is valid.
Verification must go beyond cryptography. Check that the signer was trusted for this purpose, the key was valid at signing, the hashes resolve, the policy existed, the action stayed within authority, and the claimed destination shows the expected state. Record a verifier verdict separately.
Treat emerging receipt proposals as inputs, not settled universal standards. Schema and protocol choices require security review, interoperability testing, privacy analysis, and an explicit threat model. Retention should preserve enough evidence without turning the receipt store into a new sensitive-data archive.
Test the verification path during normal operation and after key rotation. An unread receipt is not dependable evidence merely because its signature bytes exist.
Frequently Asked Questions
It can bind a signer to an integrity-protected record of configuration, inputs, actions, evidence references, review, and claimed outcome.
No. It proves integrity and signer association, not truth, authorization, source quality, or successful real-world effect.
Hash stable representations of the task, policy, configuration, source snapshot, tool actions, output, reviewer decision, and linked artifacts.
Validate the signature and key status, recompute hashes, resolve referenced artifacts, inspect authority, and independently check the claimed outcome.
For a scoped receipt schema, authority map, key lifecycle, and independent verification procedure, use AI governance and agent audit. A valid receipt strengthens traceability; it does not guarantee truth, compliance, or business success.