A log does not survive an audit
An application log can be edited, truncated or lost with nobody noticing; it does not distinguish tampering from normal operation.
A signed receipt exposes any alteration: verification fails if a single byte changed.TrustReceipt · public proof
A receipt helps verify what was recorded.
A TrustReceipt is a signed record of the context and decision recorded by Trusteed for a covered action. Transaction or payment references may be included when available. The receipt alone does not prove buyer intent, payment settlement or that the underlying event occurred, and does not determine legal liability.
v1.0 corpus in place · issuance in production is ON (`/api/v1/health` → `trust_receipts.issuing`) · what does not enqueue a receipt by default is the standalone MCP path · v1.1 hardening behind a flag.
In a minute and a half
What a Trust Receipt does for your store
Issuing a receipt does not mean a payment was settled. At the 2026-09-13 review, the public merchant registry reported beta_closed, no production merchants and accepts_real_payments=false. Check /.well-known/merchant-index.json for current availability; demonstrations and checkout previews are not evidence of real purchases.
What does a Trust Receipt do for a merchant?
A Trust Receipt is a signed record of what an AI agent does in your store and what your rules decided. Anyone can check it with standard tools, and if someone changes a single detail the signature no longer matches. It helps you prepare for disputes and audits; on its own it does not prove payment or decide who is right.
What the video says
Illustrative example · issuing a receipt does not establish a real payment.
An AI agent just bought something in your store. It acted on behalf of a customer; nobody on your team was watching.
What proof is left of that purchase? The agent log, on another company’s servers; your store; the payment provider; shipping. Loose pieces that don’t tell the whole story.
Three months later, a complaint arrives: “I never authorized this purchase.” What you have to respond with is a row in a database, and a row can be edited without leaving a trace.
Enter the Trust Receipt: a signed record of what an agent does in your store and what your rules decided.
Step 1 · The agent asks to buy, with its customer’s instructions: what to buy, how much to spend and where to ship it.
Step 2 · Your rules decide. Before the purchase goes through, it is checked against the rules you have set: allowed, blocked or waiting for your approval.
Step 3 · The receipt is created and signed. What was requested, what your rules decided and the outcome are recorded and sealed on the spot.
Step 4 · Anyone can check it: your payment provider, an auditor or you, with standard tools and no need to ask us.
What if someone changes it later? Change a single detail and the signature no longer matches. Like a tamper seal: it doesn’t stop anyone opening the box, but it shows that someone did.
What’s in it for you: better-prepared disputes, painless audits, less manual work and control over agents.
What a receipt does: proves that the record is authentic and that nobody has touched it since it was signed. What it doesn’t do: it does not prove on its own that the payment or event happened. It does not determine who is right. Issued for the operations and surfaces where it is enabled.
Don’t just log what agents do. Make it verifiable.
The problem is not the agent's action
When an agent buys on someone's behalf, you have to reconstruct what was recorded.
The intent the agent declared, your policy's decision, the order created and the final outcome each live in a different system: the agent's logs, your store, your payment provider, your fulfilment. When a dispute, a refund or an audit arrives, redoing that trail by hand is slow and contestable.
Agent identity is not proof by itself
Knowing which agent acted says nothing about what input it received, what output it produced or under which policy the decision was made.
Every receipt references the canonical hash of the exact input and output of that operation.Every recipient asks for different proof
A payment provider, a court and an auditor consume neither the same format nor the same criteria.
The v1.1 legal posture is implemented, but remains behind a flag and pending external legal review.From operation to signature
One signature per action instead of a generic summary.
The receipt signs the hashes and context captured on a covered surface. It strengthens traceability; it does not guarantee a defence or replace the rest of the file.
01
The surface records the actionCheckout, confirmation or outcome within the supported scope
by surface02
Hashes are capturedCanonical input and output available
built03
The record is signedJWS · Ed25519
issuing · partial coverage04
v1.1 hardening appliesKMS, timestamping and legal posture behind a flag
dormantAnatomy of a receipt
Example structure of a TrustReceipt v1.0.
The full input and output bodies never leave the merchant's encrypted vault; the receipt only references their hash. What is signed and shared is this.
{ "id": "tr_01JY7E4M8XN3QF7A92F", "callId": "call_01JY7E4M79QK", "agentId": "urn:agent:demo-buyer-01", "merchantId": "demo-store", "bucket": "checkout", "tool": "complete_checkout", "inputHash": "sha256:4b8d…21f0", "outputHash": "sha256:9a11…77c2", "signingKeyKid": "trusteed-ed25519-2026-06", "jws": "eyJhbGciOiJFZERTQSJ9…", "jwksSnapshotUrl": ".well-known/jwks/2026-06.json", "schemaVersion": "1.0", "createdAt": "2026-07-27T10:14:32Z"}Verification without depending on us
Verify v1.0; identify the limits of v1.1 hardening.
For v1.0, obtain the issuer's trusted public key from its JWKS and retain the verification material. Verify the JWS with the key selected by kid. Compare canonical input/output hashes only when the original data is available. Historical embedded JWKS and additional time evidence belong to v1.1 hardening, which remains gated; they are not guaranteed by a v1.0 receipt.
Obtain the issuer’s trusted public keyv1.0: resolve kid in the issuer’s trusted JWKS and retain the key; embedded historical snapshots belong to v1.1.
step 1Verify the signatureVerify the JWS with the Ed25519 key selected by kid; the signature authenticates the record, not intent or payment.
step 2Recompute the canonical hashesWith the original data and the hashes present, apply RFC 8785 JCS. A mismatch means the data does not match the signed record; it does not identify the cause on its own.
step 3Check the time evidenceCheck the version, asserted time and available evidence. Qualified timestamping is not offered; v1.1 evidence remains gated.
by surfaceWhat each side gets
A signed receipt serves whoever needs to check it, not only whoever issues it.
Proof is only worth something if it saves a specific person work at the moment they need it.
01built
FOR THE MERCHANTPrepare disputes with signed, tamper-evident records.
It reduces manual reconstruction across systems when the surface has issued the receipt.
- GDPR Art. 5(2) accountability and AI Act transparency
- Audit export with your jurisdiction's retention
- Tampering shows up as an invalid signature
02built
FOR THE INTEGRATOR OR THE AGENTVerify with any open-source JOSE library.
Standard compact JWS with Ed25519; verification requires the signed record and trusted public key.
- RFC 8785 JCS canonical hashing, deterministic across languages
- v1.0 offline verification requires retaining the trusted public key; embedded historical JWKS belongs to gated v1.1
- Agent identity via RFC 9421
03in pilot
FOR THE PAYMENT PROVIDER OR THE AUDITORA verification that depends on the issuer as little as possible.
The key that signed travels with the receipt itself, not only in a third-party system.
- Published, signed key rotation history
- Export per jurisdiction with its retention period
- Format agreed with whoever will consume it
How it applies per regulation
The same receipt, read with the right legal framework in each jurisdiction.
This section is technical guidance, not a certification or a legal opinion. The claims policy is still pending external approval.
v1.1 hardening for the EUArchitecture aligned as an evidence candidate; qualified timestamping is not active in production.
dormantEuropean identity walletSD-JWT VC presentation with selective disclosure. Relying-party registration and member-state rollout remain uncertain.
plannedESIGN Act and UETAAttribution and admissibility depend on the agreement, the facts and the applicable jurisdiction.
legal reviewUK frameworkUK-specific wording requires legal review before being published as a claim.
legal reviewNotice: a TrustReceipt is cryptographically verifiable technical evidence. It does not determine legal liability by itself. Its admissibility or weight depends on applicable law, the agreements between the parties and other facts outside the format.
Explicit limits, not small print
A receipt proves integrity. It does not replace your other obligations.
What it lets you verify technically
- That Trusteed issued a record with those hashes and that timestamp.
- That the signed content has not changed since issuance.
- The key and verification material included in v1.1, once that version is enabled.
- The posture declared in legal_posture in v1.1; not an external legal qualification.
What it does not establish
- It is not a qualified signature on its own: that requires a qualified provider.
- It does not prove the buyer's intent on its own: that lives separately, in the consent context.
- It does not reverse a fraudulent charge: it provides evidence; the remedy is up to the merchant or the issuer.
- It does not replace a SOC 2, ISO 27001 or PCI DSS audit.
Technical design
More than keeping a log: a format built for independent verification.
These are the implemented or planned pieces. Their status says whether they can be used today or remain behind a deployment condition.
Compact JWS · Ed25519Verifiable with standard JOSE libraries
builtHistorical key snapshotPart of the v1.1 hardening, behind a flag
dormantRFC 8785 canonical hashingDeterministic canonicalisation across implementations
builtCompact envelopeDesigned for the key service's signing limit
builtAgent identity contextDeployed in `block_spoofed`: a signature that fails verification is rejected, an unsigned request is not
builtPer-jurisdiction postureRequires external legal approval before being published
legal reviewWithout a receipt versus with one
The difference is not having logs. It is being able to prove them without depending on whoever keeps them.
Without a piece like this, every dispute starts by reconstructing what happened by hand, cross-checking the agent's logs, the store and the payment provider, and trusting nobody touched them.
Without a receiptThe log lives inside a provider, with its format and its active key. If the provider goes down, the proof goes with it.
With a receiptStandard JWS can be verified outside Trusteed when the signed record and trusted public key have been retained. v1.0 does not guarantee an embedded historical JWKS snapshot.
Before citing it in a dispute
What people ask when they assess a receipt.
Who can verify a Trust Receipt?
Anyone who receives it: your payment provider, an auditor or you. The signature is checked with standard JOSE libraries and the issuer's public key, without asking Trusteed for permission. Verifying the signature establishes that the record is authentic, not that the payment settled.
What happens if someone changes a Trust Receipt?
Verification fails: changing a single detail is enough for the signature to stop matching the content. It works like a tamper seal: it does not stop anyone touching the record, but it shows that someone did.
Is it admissible in court?
That cannot be claimed universally. Admissibility and weight depend on the jurisdiction, the procedure, the agreements between the parties and the rest of the evidence.
Do I need a qualified provider to use them?
Not to verify a JWS signature. Yes for any qualified-seal claim; that capability is not available.
Where are receipts stored?
The current corpus persists the JWS and its references. Hash chaining and checkpoints are ARMED in production (`TRUST_RECEIPT_CHAIN_ENABLED` is set, with a genesis declared on 2026-08-06), but they are still not presented as an operational capability, for a different reason than before: receipts issued before that genesis are not chained, and how many later ones are has not been counted. Armed, not measured: sequence immutability over the whole corpus is not offered.
What happens if the signing key rotates or is revoked?
The architecture provides historical snapshots and a signed revocation list. The code is finished, but deployment and the production probe must be confirmed before relying on them.
Trust as infrastructure
A covered operation can leave a signed record.
This receipt allows retained signed content to be verified outside Trusteed; it does not replace checkout, payment-provider evidence or your system of record.