Agent evidence is signed, retained for years, and mostly not quantum-safe — which makes signature lifetime a governance question, not just a cryptography one.

The post-quantum debate has focused on confidentiality. For an evidence layer the risk runs the other way: if a signature scheme becomes forgeable before the retention period ends, the receipt does not leak — it stops being proof. Harvest-now-forge-later.

Get an Agent Trust Gap Brief

The question almost nobody is asking

The post-quantum conversation has been about confidentiality — harvest-now-decrypt-later, encrypted traffic captured today and read in a decade. That framing misses something for anyone building an evidence layer.

Agent governance does not primarily produce secrets. It produces signatures. An execution receipt is only worth anything because its signature can be verified and its chain proves nothing was altered. If the signature scheme becomes forgeable before the retention period ends, the evidence does not leak — it stops being evidence.

Call it harvest-now-forge-later. An adversary does not need to break the signature today. They need it breakable before the moment somebody relies on that record.

Why retention makes this concrete

This would be theoretical if agent evidence were short-lived. It is not. Under the EU AI Act, logging obligations come with retention periods. Financial-services model-risk regimes expect records to survive supervisory review cycles. Incident evidence is retained through limitation periods that run years.

So the working question is not is Ed25519 safe today. It is: for how long must this specific receipt remain verifiable, and does the signature scheme survive that window? Most teams have never asked it, because the evidence layer is new and the retention obligations were written for logs nobody expected to cryptographically verify.

The standards that set the clock

Item	What it is	When
ML-KEM (FIPS 203)	Post-quantum key establishment	Standardised
ML-DSA (FIPS 204)	Post-quantum digital signature — the one that matters for receipts	Standardised
SLH-DSA (FIPS 205)	Hash-based signature, conservative alternative	Standardised
CNSA 2.0	New US national-security systems quantum-safe	January 2027
FIPS 140-2 sunset	Remaining certificates move to Historical; only 140-3 for new procurement	21 September 2026
NIST CSWP 39	Considerations for achieving crypto agility	Published

Verified 2026-08-06. CNSA 2.0 binds national-security systems, not most enterprises — but it moves vendors and supply chains, which is how it becomes an effective market deadline. Not legal advice.

What to actually do — and what not to

Build a cryptographic inventory first. Which algorithm signs which artifact, in which module, with what key lifetime. A cryptographic bill of materials. Migrating before you can enumerate is how organisations migrate twice.
Make the algorithm a versioned field, not an assumption. Every receipt should name its signature algorithm and key identifier, and every verifier should handle more than one. That single design choice is most of crypto agility.
Map retention against algorithm lifetime. For each evidence class: how long must it stay verifiable, and does the current scheme plausibly survive that window? Where it does not, that is a documented risk with an owner — not a silent one.
Consider hybrid signing for long-retention evidence. Classical and post-quantum together, so verification survives either failing.
Do not rip out working cryptography on a schedule nobody set. Ed25519 is a sound choice today. The failure mode is not using it — it is having no path off it and no record of where it is used.

Direct answers

Are AI agent execution receipts quantum-safe?

Almost certainly not today. Most signing in this space uses Ed25519 or ECDSA, neither of which is quantum-resistant. That is a reasonable choice right now — but evidence is retained for years, so the question is not whether the signature is safe today, it is whether it is still verifiable when the retention period ends.

What is harvest-now-forge-later?

The evidence-side companion to harvest-now-decrypt-later. An adversary does not need to break a signature today. They need the signature scheme to be breakable before the moment someone relies on that record in a dispute, an audit, or a regulatory proceeding.

What are ML-KEM, ML-DSA and SLH-DSA?

NIST's standardised post-quantum algorithms. ML-KEM (FIPS 203) for key establishment, ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for digital signatures. ML-DSA and SLH-DSA are the ones that matter for signing evidence.

What is the CNSA 2.0 deadline?

CNSA 2.0 requires new US national-security systems to be quantum-safe by January 2027. It is not binding on most enterprises, but it drives vendor and supply-chain behaviour, which is how these deadlines become effective market deadlines.

What happens to FIPS 140-2 in 2026?

Remaining FIPS 140-2 certificates move to Historical status on 21 September 2026. After that, only FIPS 140-3 validated modules may be used for new procurement. If your evidence pipeline depends on a validated module, that date matters.

What is crypto agility?

The ability to change cryptographic algorithms without rebuilding the system around them. NIST published CSWP 39 on this. For an evidence layer it means the signature algorithm is a versioned field in the receipt, not an assumption baked into the verifier.

Should we migrate agent signing to PQC now?

Not necessarily. The defensible position is crypto agility plus a cryptographic inventory, so migration is a configuration change rather than a rebuild. Migrating before you can enumerate what you are running is how organisations end up migrating twice.

ApexClaw's own position, stated plainly

The published ApexClaw Receipts schema carries alg and kid on every signature object, so the algorithm is a declared, versioned field rather than an assumption. The reference samples use Ed25519.

ApexClaw does not currently sign with a post-quantum algorithm, and does not claim quantum resistance. What it claims is narrower and checkable: the schema is agile by design, so migration is a configuration and verifier change rather than a rebuild. That is the honest state, and it is labelled that way in the claims ledger.