Proposal: AI Inference Layer Quantum Attack Surface — 5 new risk entries

[RichardBarron27]

Five proposed additions covering the AI-specific quantum attack surface — model signing integrity, agent identity binding, evidence chain cryptographic dependency, inter-agent trust protocol exposure, and RAG confidentiality.

All five gaps are absent from existing PQC frameworks (NIST FIPS 203/204/205, OWASP QS v0.1 draft, NIST AI RMF, ISO 42001).

All five risks are operationalised in NIGHTFALL L46 (Post-Quantum AI Cryptography) and AI Shield M103 (Quantum AI Security Engine) — findings come with tested offensive and defensive counterparts.

Invited to contribute by Roy Barkay via LinkedIn.

Reference: RS-2026-003 DOI 10.5281/zenodo.21462689

[nmcitra]

Reading this as someone with an entry in adjacent territory (#31, identity and authorization continuity). QS-NEW-02 and QS-NEW-03 overlap it directly, so weigh what I say about those two with that in mind. I work on infrastructure and authorization systems rather than cryptography, so the crypto notes below are the ones to weight least.

The core instinct here is right, and I don't think it's covered elsewhere. Agent-to-agent authentication and AI audit trails both have cryptographic dependencies that the migration guidance was written before anyone needed to think about. Worth having in the conversation. This deserved a first read sooner than it got one.

QS-NEW-02 and QS-NEW-03 are the strongest of the five.

In 02, this line is the most valuable thing in the document:

There is no authentication log anomaly. The forged agent identity is cryptographically indistinguishable from legitimate.

That's a detection argument, not a cryptography argument, and it's the reason this class is worse than classical credential theft. I'd build the entry around it. Most readers will already accept "signatures become forgeable"; the thing they haven't internalised is that the usual detection surface goes silent at the same time.

03 is the one I'd expect a regulated-industry reader to act on soonest. RFC 3161 having no post-quantum profile is concrete, checkable, and unresolved, and the admissibility framing gives it consequence that doesn't depend on anyone's CRQC timeline.

The HNDL framing on the signature entries doesn't hold, and I think fixing it makes them stronger.

This is my main technical note. Harvest-now-decrypt-later is a confidentiality mechanism: collect ciphertext today, decrypt when the key breaks. For signatures there's nothing useful to harvest. An adversary who can derive a signing key from a public key can forge whatever they want at that point — collected signed model distributions from 2026 don't help them.

So in 01, "an HNDL adversary collecting signed model distributions today" is doing no work. The real risk is that everything signed with a classical key becomes forgeable retroactively, so provenance built today can't be relied on tomorrow. That's a stronger claim, and it doesn't require the adversary to have collected anything.

Worth noting this maps onto the QS01/QS02/QS03 discussion in #11, where the discussion converged on separating harvest-now-decrypt-later from trust-now-forge-later. 01, 02, and 03 are all TNFL. 05 is genuinely HNDL. 04 already splits correctly — the ECDH half is HNDL, the message-signature half is TNFL. Sorting them that way would slot this into the taxonomy the project is already converging on rather than cutting across it.

The evidence classification is the part I'd change first.

The document header stamps the whole proposal Demonstrated, and 01–03 carry it per entry, resting on NIGHTFALL L46 and AI Shield M103. But the document also says the tooling is gate-controlled and requires signed ROE, which means nobody reviewing this can check it. I don't doubt the work exists — the problem is that "Demonstrated" in an OWASP deliverable is a promise to the reader about what they can verify themselves, and this doesn't let them.

04 and 05 are already marked Emerging, which is a good fit. For 01–03 you might get further with Emerging plus a public artifact — a signed sample, a reproducible forgery against a test key, anything a reader can run. That would earn Demonstrated in a way that survives review. See the evidence convention proposed in #18.

The product references are going to draw fire, and I'd rather say so than watch it happen.

Every entry carries a Red Specter implementation block naming specific modules, and the document closes with a company footer and a tagline. I understand why it's there — it's your evidence that this is operational rather than speculative. But in an OWASP deliverable it reads as placement, and the risk is that someone dismisses the whole proposal on that basis without engaging with 02 and 03, which deserve engagement.

My suggestion: strip the per-entry implementation blocks, keep one line in the references noting that the risks are operationalised commercially and that details are available on request. You lose nothing that matters and you remove the easiest reason to say no. Same for the tagline in the footer.

Whether implementation references belong in the deliverable at all is a question for the project leads. This is only my read of how it will land in review.

On packaging: five entries is a lot of the list.

There are ten slots. Five new entries is asking for half, which makes this a harder yes than it needs to be. These read to me as one coherent entry — the AI agent layer's cryptographic dependencies — with five sub-risks under it, or possibly two entries splitting agent identity from evidence integrity. 05 in particular looks like it belongs inside the HNDL entry proposed in #11 rather than standing alone, since it's the same mechanism applied to a specific store.

I'd rather see one entry land than five stall. I've said the same about my own — #31 is filed standalone-first, absorption-ready, and says so under Placement. Not asking you to do anything I'm not.

Smaller things:

• The mitigations say CRYSTALS-Kyber; FIPS 203 standardised it as ML-KEM, and your own reference list already uses the new name. A PQC reviewer will notice the drift. (ML-DSA is used consistently — this is only the KEM.)
• 03 says HMAC-SHA256 evidence chains are not quantum-resistant. By the same Grover argument 05 gets right, HMAC with a full-length key holds up. The quantum-fragile pieces in 03 are the RFC 3161 signature and the Ed25519 log signatures, not the HMAC.
• ML-DSA-65 throughout without a rationale. Since defence is named as a target sector, worth noting CNSA 2.0 requires ML-DSA-87 for national security systems — ML-DSA-65 isn't permitted there.
• 05 correctly identifies that AES-256 is Grover-resistant and puts the risk in key management. That's the right call and I'd make it more prominent — a lot of writing on this gets it wrong.
• "the trust fabric of multi-agent orchestration collapses" in 02 is doing less work than the detection line right below it. The specific claim is stronger than the sweeping one.

Happy to read a revision if you do one. The agent identity entry is the one I'd most want to see in the final list.

[RichardBarron27]

@nmcitra — thank you for this. Taking each point:

TNFL/HNDL taxonomy corrected. 01, 02, 03 are TNFL not HNDL. The retroactive forgeability argument is stronger and more precise. Revised accordingly and aligned with the QS01/QS02/QS03 taxonomy from #11. 04 already split correctly. 05 is genuine HNDL.

HMAC note accepted. The quantum-fragile components in 03 are the RFC 3161 signature and Ed25519 log signatures. HMAC-SHA256 holds under Grover with a full-length key. Corrected.

ML-KEM naming. CRYSTALS-Kyber → ML-KEM throughout. Fixed.

ML-DSA-87 for CNSA 2.0. Added rationale and noted the national security system distinction.

Evidence classification. Downgrading 01/02/03 to Emerging. The gate-controlled tooling doesn't satisfy the verifiability standard. Public artefacts for 02 and 03 are in preparation.

Product references. Stripped per-entry implementation blocks. Single reference line at close. You called it correctly.

Consolidation. Agreed five slots is too much. Proposal is now absorption-ready — placement note added. Happy to follow the project leads' preference on structure. QS-NEW-02 and QS-NEW-03 are the ones I'd most want to see land.

Revised file committed to the branch.