Post-quantum Signed Receipts for AI Tool Calls

Asqav is the unaffiliated third-party notary for AI tool call receipts. The signer that produces a receipt is operated by Asqav, not by the agent vendor and not by the regulated entity. The receipt format is published on the IETF Datatracker, so any auditor can verify a customer's evidence pack against the public verify key.

Post-quantum signatures with ML-DSA-65 (NIST FIPS 204) are one of the signer options Asqav exposes. They are available to customers whose retention windows reach into the quantum-threat horizon.

What it is: an Asqav-signed receipt, with ML-DSA-65 as one of the signer's algorithm options.

What it proves: the receipt verifies against a public key for the full retention window, past the point where a quantum computer breaks classical signatures.

Who signs it: Asqav, an unaffiliated third party, never the agent vendor and never the regulated entity.

Why the unaffiliated signer matters

Regulated buyers ask for a receipt that a party other than the regulated entity can verify. A receipt signed by the same workload being audited does not pass that test. Three rules bear on the unaffiliated-party property, and SEC 17a-4(f)(3)(v) writes it directly into the rule text:

• SEC 17a-4(f)(3)(v): broker-dealers designate a third party, unaffiliated with the broker-dealer, with access to and the ability to download required electronic records.
• NYDFS 23 NYCRR 500.06: covered financial entities maintain audit trail systems sufficient to reconstruct material financial transactions.
• DORA Articles 28 to 30: financial entities evidence ICT third-party risk management and retain attestable evidence of those controls.

Deployment topology

The signer holds the keys. The agent never touches the signing key. To audit, the reader fetches the public verify key from a documented endpoint, takes the customer's audit pack, and verifies every signature offline without an Asqav account.

The signer runs in one of two trust topologies:

• Asqav-hosted SaaS signer at https://api.asqav.com. Asqav holds the keys. The customer holds none.
• Customer-deployed signer via the asqav-signer container image, with keys held in a customer-controlled KMS or HSM (LOCAL, AWS KMS, or GCP KMS). See Out-of-process signing.

Both topologies emit the same wire format, both verify against keys exposed at GET /.well-known/jwks.json, and both are documented against the IETF receipt format.

Signer options

The signer accepts the algorithm choice as configuration. Two options are documented today:

The algorithm identifier rides inside the signed envelope ("alg": "ML-DSA-65"), so an auditor reads which scheme protects each receipt without trusting transport metadata.

What ML-DSA-65 buys

ML-DSA is the Module-Lattice-Based Digital Signature Algorithm. It derives from CRYSTALS-Dilithium and was standardized in NIST FIPS 204 in August 2024.

ML-DSA-65 is the Category 3 parameter set. It targets roughly 192 bits of classical security and resistance against an adversary with a fault-tolerant quantum computer. The full standard is published by NIST at csrc.nist.gov/pubs/fips/204/final.

The algorithm choice follows the retention window. A receipt signed in 2026 needs to verify against the public key for the full window the regulator applies:

• HIPAA Security Rule expects six years from creation or last effective date for records of security activity.
• SEC 17a-4 requires six years for most records and lifetime for some categories of broker-dealer record.
• DORA Articles 28 to 30 expect financial entities to retain attestable ICT third-party-risk evidence across the regulator's audit cycle, which spans multiple years.
• NYDFS 23 NYCRR 500.06 requires audit trail systems designed to detect and respond to cybersecurity events, retained for periods set by the same regulation.

For receipts whose retention window crosses into the quantum-threat horizon, the algorithm choice is part of the third-party-notary contract. ML-DSA-65 has no known polynomial-time quantum attack against the underlying module-LWE and module-SIS problems.

Where the receipt format is published

The receipt envelope, signature encoding, decision vocabulary, and capture topology values are published in an IETF Internet-Draft on the Datatracker:

datatracker.ietf.org/doc/draft-marques-asqav-compliance-receipts/

The draft documents the canonical hash, the signature scheme identifier, the timestamp format, and the verification algorithm. Any independent implementation can parse and verify an Asqav receipt without an Asqav account.

Producing a signed receipt

The Python SDK takes a single call. The algorithm is server-side configuration. The SDK does not pick it:

import asqav

asqav.init(api_key="sk_live_...")

agent = asqav.Agent.create("invoice-bot")

receipt = agent.sign(
    "filesystem:write",
    {"path": "/exports/q1-invoices.csv", "bytes": 18324},
)

print(receipt.signature_envelope)
# {
#   "alg": "ML-DSA-65",
#   "signed_at": "2026-05-25T14:02:11Z",
#   "signature": "...",
#   "verify_key_id": "vk_...",
#   "previous_receipt_hash": "..."
# }

The envelope carries the algorithm identifier, the signer-issued timestamp, the signature bytes, the verify key identifier so a verifier can fetch the right key from /.well-known/jwks.json, and the previous receipt hash so the chain-of-custody is enforceable.

Verifying a receipt offline

The receipt format is on the IETF Datatracker and the verify key is on a public endpoint, so an auditor never needs an Asqav account:

asqav audit-pack verify \
  --pack ./audit-pack-2026-q1.tar.gz \
  --verify-key https://api.asqav.com/.well-known/jwks.json

The CLI parses the pack, fetches the verify key, validates each signature against the algorithm named in the envelope, and confirms the hash chain is unbroken across the receipts in the pack.

Further reading

• Self-hosted Signer
• Out-of-process signing for high-assurance deployments
• NSA MCP Security Guidance: Asqav Coverage
• SEC 17a-4 standards page
• NYDFS Part 500 standards page
• DORA standards page
• HIPAA Security Rule standards page