Zero-knowledge proofs promise mathematical non-repudiation while signed, anchored traces deliver millisecond receipts, yet teams must pick one or the other for now. This guide explains the two production-grade architectures shipping in 2026, the exact fields to record at inference time, and the canonical steps that produce a tamper-evident receipt an auditor can verify offline. It maps each technical choice to the compliance demands of the EU AI Act Article 12, the NIST AI Risk Management Framework, and ISO/IEC 42001. Read on for a three-change minimal implementation you can prototype today and a nine-step checklist for production.

Two production trade-offs dominate the design space: cryptographic certainty at seconds-to-minutes per inference, or near-instant receipts that rely on external anchors and attestation. That contrast decides which architecture you pick, and it drives every downstream decision about payload, signing, chaining and verification.

1. Pick the verification architecture that matches your latency and threat model

The first binary choice is between two production-grade approaches in use today. The first is the Zero-knowledge proof route. In this model a prover produces a succinct cryptographic proof that the inference computation was executed correctly under a specified model. Verifiers check the proof without re-running the model, so the guarantee rests on mathematics rather than operational trust. The downside is prover cost: expect seconds-to-minutes of compute per inference, which makes this suitable for high-assurance, low-frequency decisions rather than high-throughput interactive agents.

The second approach is the Signed trace anchored to an external medium. Here the system records events, bundles them into a Merkle tree or a rolling hash chain, and anchors the chain head to a trusted timestamp authority or a public ledger. Receipts verify quickly and scale to interactive agents, but they depend on an external anchor, an attestation service or hardware signing for non-repudiation. Choose zero-knowledge when you need per-inference cryptographic non-repudiation and can tolerate latency and cost. Choose signed, anchored traces when you need millisecond-level receipts and accept an anchored-trace trust model.

Worked example: a loan-decision system that must defend a single automated refusal in court might prototype a zero-knowledge proof for that specific decision. A consumer chat assistant that needs to display a receipt to users in real time will likely adopt signed traces and Merkle anchoring.

2. Define a canonical payload to record at generation time

Design a minimal, canonical record that expresses the guarantees auditors demand. At minimum include a unique Receipt type identifier, an Agent or tenant identifier, the exact Input presented to the model, the exact Output returned, the Model identifier and version, a precise Timestamp, and metadata for any tool calls or sub-agent actions invoked during processing. These fields let attestations prove five claims: the recorded input, the recorded output, the model and version used, that the record hasn't been altered since signing, and the issuer identity linked to a public key.

When personal data appears in transcripts, redact or transform Personally Identifiable Information at the SDK boundary so sensitive data never leaves your control. That design decision both reduces legal exposure and preserves auditability because the canonical record still binds input to output without leaking raw PII.

Worked example: an assistant logs the user prompt, the model response, model name and version string, any tool call identifiers and tool outputs, and a tenant ID. The tenant ID plus the timestamp plus a canonicalised input and output form the core receipt.

3. Canonicalise and hash

Before any signing or chaining, produce a deterministic byte-level representation of the payload so independent verifiers derive the same digest. RFC 8785 canonical JSON is a production-proven choice for canonicalisation. After canonicalisation compute a deterministic digest, typically SHA-256. That digest is the single cryptographic handle you will sign, chain, or include in a Merkle tree.

Worked example: the system serialises the receipt payload to canonical JSON, applies SHA-256 and records the hex digest alongside the timestamp and model version. The same canonicalisation applied by an auditor yields the identical digest for offline verification.

4. Choose a signing primitive that matches your verification model

Pick the signing primitive to match whether you need public, offline verifiability or only internal tamper-evidence. For public verifiability use an asymmetric signature such as Ed25519 over the canonical digest. Ed25519 lets auditors verify receipts offline with only the public key. For the lowest latency some systems adopt symmetric HMAC signatures for tool-call receipts. HMAC-signed receipts can be produced in a few milliseconds and are enough for internal tamper-evidence or cross-checking within a controlled verifier set, but they require careful key management if third parties must verify.

Document the signing scheme in your compliance policy so auditors know how to validate receipts and where to find public verification keys. Include key identifiers in the receipt payload so signature verification is unambiguous.

Worked example: a high-volume agent signs tool-call receipts with HMACs under a rotation schedule, while critical end-decision receipts are Ed25519-signed and published with a stable public key for offline audit.

5. Chain receipts so order and integrity are preserved

Create a Rolling-hash chain or batch receipts into a Merkle tree before anchoring. Chaining prevents silent deletion or reordering because removing or moving a receipt breaks chain integrity. For timestamp authority you can use RFC 3161 timestamping to anchor a chain head to a trusted time source. Alternatively commit Merkle roots to a public ledger or blockchain for an operator-independent anchor. Ensure the implementation produces a chain head, records the anchor identifier for example a transaction ID or timestamp token, and includes that anchor reference in the receipt payload.

Mastheads

Worked example: every minute the system batches recent receipts into a Merkle tree, publishes the Merkle root on a public ledger, and stores the ledger transaction ID in each receipt so auditors can obtain an inclusion proof later.

6. Provide a verification path that doesn't require contacting your service

Publish the public verification key and the verification algorithm and provide an Offline verifier that checks canonicalisation, digest, signature and chain anchoring. When you use an attestation service that returns an attestation ID and a public verification URL, document how auditors can resolve that ID without relying on your live infrastructure. In anchored-trace architectures include both the receipt and the anchoring evidence so an auditor can independently fetch the anchor record on the public ledger and verify the inclusion proof.

Worked example: ship an auditor pack containing the receipt schema, canonicalisation rules, the issuer public key, the Merkle inclusion proof and the ledger transaction ID. The supplied verifier program reproduces canonicalisation, checks the digest, validates the Ed25519 signature and confirms inclusion of the receipt digest in the ledger via the provided proof.

7. Understand the trade-offs and operational costs

Zero-knowledge proofs deliver the strongest per-inference guarantee but impose heavy prover costs and latency; they're best for high-assurance, low-frequency use cases. Signed receipts with hash-chaining scale to high-volume interactive agents with millisecond-level overhead. Research on lightweight receipt frameworks shows sub-20 ms verification overhead for HMAC-based receipts and high recall at detecting fabricated tool executions when cross-checked against logged tool outputs. Design choices about where to redact PII, where to store raw transcripts, and whether canonicalisation runs on the client SDK or the backend will determine legal exposure and auditability.

Worked example: a team measured prover cost for a representative inference before committing to ZK proofs. The prototype proved correctness but revealed a per-inference latency that made the design impractical for live chat. They kept ZK for end-of-day high-value decisions and used signed traces for the interactive surface.

8. Align retention and reporting with regulatory obligations

High-risk systems under Article 12 of the EU AI Act must automatically record events for the lifetime of the system with traceability enough for post-market monitoring. National and sectoral regulators, and certification audits under ISO/IEC 42001, expect persistent, authenticable records that survive discovery. The NIST AI Risk Management Framework also emphasises traceability and verifiable records for post-deployment review. If you plan to use an attestation provider or publish chain anchors, retain raw archives and key material per your legal hold and evidence retention policy so you can reproduce or re-validate receipts under subpoena.

Worked example: an organisation stores canonical archives in a WORM-enabled store for the retention period mandated by their certification audits, and mirrors key material into a secure key escrow to preserve the ability to validate old receipts after key rotation.

9. Build verification tooling and an auditor pack

Provide auditors a verification pack that includes the receipt schema, canonicalisation rules, the issuer public key, chain anchors or timestamp tokens, and an automated verifier. Packages that allow offline verification remove the need for auditors to depend on your live systems. Structure evidence packs to match regulator expectations, for example by grouping receipts relevant to a specific decision into a single bundle with inclusion proofs.

Worked example: a vendor delivered an evidence bundle grouped by decision, with each bundle containing the canonical receipts, Merkle proofs, the ledger transaction IDs, and a small verification binary. Auditors ran the binary offline and validated a sample set of decisions without network access to the vendor environment.

Where sources differ on timing

The technical foundations and tactics above are stable, but guidance on compliance timelines varies. One industry guide maps obligations as applying from August 2025 with fuller rollouts through 2026 and 2027. A vendor product page highlights an August 2 2026 enforcement milestone and a set of preconfigured evidence packs aimed at that date. Treat reported timelines as implementation targets rather than uniform legal cutoffs and confirm obligations that apply to your jurisdiction and sector.

Practical next steps to put in place a minimal proof path

If you want a fast prototype that yields auditor-verifiable receipts, put in place these three changes now. First, record a canonical payload at generation that includes input, output, model ID and a timestamp. Second, canonicalise the payload and compute a SHA-256 digest. Third, sign the digest with an Ed25519 key you publish for verifiers and bundle receipts into a rolling hash chain. That sequence produces a tamper-evident receipt any independent verifier can check offline.

For organisations evaluating higher assurance, prototype a zero-knowledge proof for a representative low-volume inference to measure prover cost versus assurance gain. Use the prototype to decide whether to adopt ZK for a small slice of critical decisions or to standardise on signed traces for the entire interactive surface.

Implementation notes and operational checklist

First, decide where canonicalisation runs. Client-side canonicalisation reduces server-side PII transmission, but it imposes SDK maintenance. Server-side canonicalisation centralises logic and eases updates to canonical rules. Second, document key rotation and escrow procedures. Third, ensure your chain anchors record anchor identifiers in each receipt and that auditors can independently resolve those identifiers on the public ledger or from a timestamp authority.

Finally, deliver the auditor pack with an offline verifier, schema, canonical rules and the issuer public key. Include clear instructions on how to reproduce digests and validate inclusion proofs so auditors don't need live access to your environment.

In Short

- Record a canonical payload at generation that includes input, output, model ID, timestamp, and tool-call metadata.

- Canonicalise with RFC 8785, compute a SHA-256 digest, sign with Ed25519 and include key identifiers.

- Chain receipts with rolling hashes or Merkle trees and anchor the chain head via RFC 3161 or a public ledger transaction ID.

- Publish the public key, ship an offline verifier and an auditor pack containing schema, proofs and anchors.

Related Articles

Start with the three-change minimal path: record canonical payloads, canonicalise and SHA-256 them, sign the digest with an Ed25519 key and bundle receipts into a rolling hash chain. That sequence yields a tamper-evident receipt any independent verifier can check offline.

This article was created with AI assistance.