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.
When it is enabled for an operation, a TrustReceipt keeps a signed digital record of the context and decision. It helps detect later changes; on its own, it does not prove the event happened or determine legal liability.
v1.0 corpus in place · issuance in production is still switched off · v1.1 hardening behind a flag.
The problem is not the agent's action
When an agent buys on someone's behalf, you have to reconstruct what was recorded.
Every piece — the intent the agent declared, your policy's decision, the order created and the final outcome — lives 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
issuance off in production04
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": "agenticmcpstore", "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
Four steps to check a receipt without asking Trusteed.
Any standard JOSE library verifies the signature. No proprietary SDK required.
Resolve the JWKS snapshotThe embedded snapshot is downloaded and validated, with its own validity window
step 1Verify the signatureThe JWS kid selects the right Ed25519 public key
step 2Recompute the canonical hashesRFC 8785 JCS: any mismatch with inputHash or outputHash means tampering
step 3Check the time evidenceTimestamping and revocation chain, where it applies
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 detached JWS Ed25519: pure cryptography, no vendor dependency.
- RFC 8785 JCS canonical hashing, deterministic across languages
- Embedded JWKS snapshot for offline verification
- 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.
Detached Ed25519 signatureVerifiable 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 contextVerification implemented; production mode off by default
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, embedded JWKS and cross-language canonical hashing: verified outside Trusteed, even if Trusteed disappears.
Before citing it in a dispute
What people ask when they assess a receipt.
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 exist behind a disabled flag and are not presented as an operational capability.
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 does not replace your checkout, your payment provider or your system of record. It makes what was already happening verifiable outside Trusteed.