What Your Auditor Will Ask For

Auditors, customer security reviewers and counterparties need records they can inspect and check. The questions below explain what a receipt holder can export, which checks run independently, and what further evidence the reviewer needs.

"Show me everything your agents did in this period."

Export the recorded receipts for the requested period in a portable file. Establishing that every relevant action was captured also requires evidence about the integration and the boundaries of the record set:

asqav audit-pack export --start ISO --end ISO --no-only-compliance --include-signed-bytes --output-file FILE

The pack carries recorded receipts for the requested window. --no-only-compliance includes receipts outside compliance mode; the default export includes only compliance receipts. With signed bytes, trusted public-key material and a compatible verifier, a reviewer can check receipt signatures offline without an Asqav account. The export does not by itself establish that every action in the period was recorded.

--include-signed-bytes includes the bytes needed to check individual receipt signatures; it is off by default. Without those bytes, a reviewer holding only the pack can check its manifest signature but cannot independently check each receipt signature. Choose the export form for the intended review and retention use, and preserve the necessary key material. The pack records its form in content_disclosure.

"How do I know nothing was deleted?"

A receipt can commit to its predecessor through a SHA-256 chain link. Given both records, the open verifier can rederive that link; a missing record between retained neighbours leaves a gap. This does not establish that every action was recorded or detect an omitted beginning or end without evidence of the sequence boundaries. Independent Verification describes the predecessor check.

"How do I know this was not edited afterwards?"

Receipt signatures use ML-DSA (NIST FIPS 204), with ML-DSA-65 as the default. The signer and verifier canonicalise the signed payload with JCS to reproduce its bytes. Checking the signature under a trusted key detects changes to that signed payload. Unsigned envelope fields, including added anchor proofs, are outside that signature and need their own checks.

"Why should I take the vendor's word for any of this?"

The wire format is published as an IETF Internet-Draft, public keys are available at GET /.well-known/jwks.json, and the verifier is open source. You can check a retained receipt offline against a key you have established as trustworthy. This removes dependence on a hosted verification answer; it does not remove trust in key custody, key distribution or the verifier. A party holding the private key can sign records. Verify a Receipt Without Asqav shows the offline workflow.

"Could the operator have signed this record themselves?"

In the hosted service, Asqav holds the platform signing key separately from the customer submitting the record. Establish who controlled the key used for the receipt you are reviewing, including any customer-managed key arrangement. Separate custody does not prove the truth of the submitted event or prevent a key holder from signing another record. Key Custody and Disclosure describes the custody arrangements.

"When did this record exist?"

Receipts can carry RFC 3161 or OpenTimestamps proofs. A successfully checked anchor constrains when the committed record bytes existed under that proof's trust assumptions. It does not establish when the asserted event occurred. Check the available proofs, identify who controls each witness, and retain the relevant certificates or other trust material. Merely listing an anchor does not verify its time claim. Multi-Witness Anchoring describes the anchor set.

"How was this action observed?"

A careful auditor distinguishes a record emitted at the call site from one reconstructed out of telemetry. The capture_topology field answers this inside the audit trail with a controlled vocabulary of six values, from in_process_sdk to passive_telemetry, so the asker can calibrate how much corroboration each receipt needs. See Capture Topology.

"Will this still verify in five years, without you?"

Prepare for later verification by retaining the signed receipt bytes, public keys whose provenance you have established, the verifier and its dependencies, and applicable anchor proofs and trust material. Preserve that material when you export; do not rely on a key remaining in the live directory. Offline verification can then use the retained material, subject to the verifier's supported checks and the cryptographic assumptions that still hold at audit time.

"Which obligations does this support?"

Verifiable receipts support recordkeeping obligations rather than satisfy them on their own, and the careful wording matters. The record types that come up:

Where to go next