What does a signed AI receipt actually prove?
A signed AI receipt proves that its issuer committed to a specific record without later alteration; it does not by itself prove that every fact in that record is true.
AI providers make claims about models, regions, retention and controls. A receipt turns some of those claims into a record that can be inspected after the response has disappeared from the screen.
Start with the claim, not the signature
A cryptographic signature answers a narrow question: has this exact record changed since the holder of a specific signing key signed it? That is useful, but it is only the outer seal. The evidentiary value comes from the fields inside the receipt and the systems that produced them.
What a useful receipt should contain
- The exact model and version requested, plus a weight hash or another immutable model identifier.
- The deployment and provider that handled the request, including the workload region.
- The retention mode, policy version and guardrail version applied at execution time.
- Hashes of the prompt, response and tool activity instead of the sensitive content itself.
- A timestamp, receipt identifier, signing-key identifier and verifiable signature.
- Any provider attestation or infrastructure evidence that supports claims made by the routing layer.
What it proves—and where the proof stops
| Claim | What the receipt can establish | What still needs outside evidence |
|---|---|---|
| The record was not changed | The signature verifies against the signed payload | Control of the signing key and its rotation history |
| A model version was recorded | The exact identifier is bound to the run | That the executor actually loaded those weights |
| A region was recorded | The router committed to the selected deployment | Provider or infrastructure evidence for physical processing |
| No content was logged | Only hashes appear in the receipt | Logging configuration, access controls and independent assurance |
A verification workflow for buyers and operators
- Canonicalise the receipt payload using the documented format.
- Resolve the signing key from a trusted key registry and check its valid time window.
- Verify the signature and confirm that the receipt identifier has not been revoked.
- Recompute any hashes from content you already possess; do not upload that content to a third-party verifier.
- Follow referenced attestations to the provider, deployment and policy records.
- Record which claims were verified, which were merely declared and which remain unknown.
The procurement question is evidence coverage
Ask a provider to map every material claim to its authoritative evidence source. Region belongs with infrastructure evidence. Provider ownership and support access belong with corporate and operational controls. Subprocessors belong with a current register. International transfer claims belong with a documented legal basis. A receipt can bind those references to a run, but it cannot replace them.
Treat a signed receipt as a tamper-evident index into an evidence chain—not as a universal certificate of sovereignty, privacy or correctness.
Common questions
- Does a valid signature prove the provider told the truth?
- No. It proves that the holder of the signing key signed an unchanged record. Confidence in the recorded facts depends on the issuer, the execution controls and any independent attestations linked from the receipt.
- Should a receipt contain the prompt and response?
- No. A privacy-preserving receipt should contain metadata and cryptographic hashes. The user can verify a hash locally without disclosing the original content to a verifier.
- Can a receipt prove data sovereignty?
- Not alone. It can record and bind evidence about region, deployment, retention and policy, while sovereignty also depends on provider ownership, support access, subprocessors, legal transfer basis and operational control.