What Your Auditor Will Ask For

When agent activity gets examined from outside, the examiner's questions follow a pattern. An external auditor, a customer's security reviewer, and a counterparty in a dispute are all probing the same thing: not whether you kept records, but whether the records deserve belief. The asks below recur, and each one maps to something a receipt holder can hand over and the asker can check.

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

The asker is testing completeness and portability. A dashboard screenshot fails this test because the asker cannot take a dashboard home. What you hand over is one offline file:

asqav audit-pack export --start ISO --end ISO --output-file FILE

The pack carries the receipts for the window and verifies against the public key, offline, after the fact. The asker does not need an Asqav account or a running Asqav to read it.

"How do I know nothing was deleted?"

The asker is testing for silent gaps. Each Asqav receipt commits to its predecessor through a SHA-256 chain link, so a record removed from the middle leaves a broken link rather than silence. Given the predecessor receipt, the open verifier rederives the link and confirms the chain holds. Independent Verification lists the exact check.

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

The asker is testing tamper evidence. Each receipt is signed with ML-DSA (NIST FIPS 204), ML-DSA-65 by default, over its canonical bytes, produced with JCS canonicalisation so a verifier reproduces the exact byte string the signer signed. Change one byte of the record and the signature fails. The check runs on the asker's machine, not yours.

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

They should not have to, and the architecture is built so they never do. The wire format is published as an IETF Internet-Draft, the verify key is public at GET /.well-known/jwks.json, and the verifier is open source. Verification runs offline with no Asqav account. Asqav cannot make a forged receipt pass and cannot make a genuine one fail. Verify a Receipt Without Asqav is the ten-minute version of this answer.

"Could the operator have signed this record themselves?"

This is the question that separates evidence from self-attestation. Asqav signs each record server-side with keys held by an operator unaffiliated with the agent's operator. The recorded party never holds the signing key, so it cannot forge or backdate its own record. Anyone who signs their own audit log, whatever the algorithm, is affiliated with the record subject by definition. Key Custody and Disclosure documents who holds which keys.

"When did this record exist?"

The asker is testing against backdating. Receipts can carry external time anchors, including OpenTimestamps and RFC3161 timestamps from authorities outside Asqav, and the verifier recomputes the envelope digest each anchor commits to. A backdated record would need every external witness to cooperate. Multi-Witness Anchoring covers 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?"

Evidence has to outlive the tools that made it. The format is an open Internet-Draft, the verify key stays published, and the verifier is a single readable file the asker can copy into their own audit environment. The post-quantum signature scheme is chosen for retention windows that run into the quantum-threat horizon. Nothing about checking a receipt depends on Asqav existing when the check runs.

"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