For auditors & compliance reviewers

Verify an authorization receipt yourself. Two minutes, offline, no one’s word for it.

An authorization receipt (formerly Trust Receipt) is a signed, machine-verifiable evidence packet proving that a named human approved a specific AI-agent action before it executed. Unlike an audit log — which asserts what happened inside a system you cannot inspect — a receipt is something you re-verify yourself, with public-key cryptography, without relying on the auditee’s systems or on EMILIA.

Written for U.S. government auditors (GAGAS / the GAO Yellow Book), single-audit practitioners and state auditors, SOC 2 and ISO/IEC 42001 assessors, EU AI Act conformity reviewers, and internal audit. No cryptography background required.

The verification procedure

Obtain the evidence packet. Request the receipt or device-signoff JSON for the sampled action from the auditee. A conformant packet is self-contained — it carries its own public key. If the auditee can only show you a dashboard, that is a finding, not evidence.
Re-verify it independently. Two equivalent paths: in the browser at emiliaprotocol.ai/verify (the check runs locally in your tab — open the network panel and observe that nothing uploads), or fully offline in a terminal:
```
npx @emilia-protocol/verify receipt.json
```
The verifier is open source (Apache-2.0, published on npm) — your firm can pin and review the exact code it ran.
Read the checks. Each line is one verified property (table below). A valid artifact passes all of them; any single failure invalidates it.
Record the result. The workpaper fields below make the verification reproducible by anyone, years later — the receipt does not expire and does not need our servers.

What each check proves

challenge_bindingThe approval is bound to this exact action. Any altered parameter — amount, payee, target — invalidates it.

user_verifiedThe approver passed biometric or PIN verification (Face ID · Touch ID · passkey) at the moment of approval.

user_presentA human was physically present at the signing device.

signatureSigned by the approver’s enrolled device key (ECDSA P-256); receipts are signed by the issuer (Ed25519).

client_data_typeA genuine authenticator assertion — not a replayed enrollment ceremony.

rp_id_hashThe signature is scoped to the expected service, not lifted from another site.

anchorFor receipts: included in the published Merkle anchor — the history cannot be silently rewritten.

The honest boundary: what offline verification does not prove

Offline verification proves the artifact is authentic, intact, and bound to the exact action. A revocation can also be evidenced offline: a portable, signed revocation statement(EP-REVOCATION-v1) is checkable with npx @emilia-protocol/verify revocation, fail-closed, with no EP server. What offline checking cannot prove is a negative — the absence of a revocation you were never handed (a liveness/transparency problem), and one-time use (that a signoff was consumed exactly once) remains server-state. The question to ask the auditee:“Show me your consumption record and any revocation statement for this signoff_id.” A conformant deployment rejects replays before any state changes.

What to record in workpapers

receipt_id / signoff idThe artifact’s identifier, from the evidence packet

action / context hashThe digest the approval is bound to

key_classA = approver-held device key (highest); C = platform-held

verifier + versione.g. @emilia-protocol/verify 3.6.2 (record the version you ran)

resultvalid: true/false and each individual check

verified on / byDate and team member — the verification is reproducible by anyone

↓ Download a completed sample workpaper (PDF)

Red flags

A governed action class (e.g. payment release) with no receipt produced for a sampled transaction — absence of evidence is the finding.
key_class C on actions the auditee’s own policy designates as requiring Class A (approver-held key).
challenge_binding: false on any artifact — the approval evidence does not match the action it is attached to.
Receipts that can only be “verified” inside the auditee’s or vendor’s own dashboard. Independently verifiable evidence requires no such access.

Ingesting receipts into a SIEM

Receipts are canonical JSON (RFC 8785) — Splunk, Datadog, and Elastic parse them natively, which lets a compliance dashboard correlate every governed action with its human approval. Core fields:

@versionFormat identifier (EP-RECEIPT-v1)

payload.receipt_idUnique receipt identifier

payload.action_hashSHA-256 digest of the canonicalized action

payload.approver_id / key_classNamed approver and authenticator class

payload.decisionapproved / rejected

signature.algorithm / valueSignature material (verify before ingest)

anchor.merkle_rootAnchor for tamper-evidence correlation

Full schema in the specification. Verify signatures before ingest; treat the SIEM copy as an index, the signed JSON as the evidence.

Compliance and control mappings

Bring this to a client’s control test

Auditors are how this evidence format spreads: every engagement where a receipt is re-verified in workpapers normalizes it. Forward the sample workpaper to the team running the control test — it shows exactly what to record. Want a 30-minute briefing? We’ll walk your team through a live verification on your own laptops, including a forged receipt your team catches themselves. Try it first-hand now: approve an action with Face ID on /try, then verify what you signed on /verify.

team@emiliaprotocol.ai →