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.

[nmcitra]

That was a fast and thorough revision — stronger everywhere it changed, and the per-entry "Quantum mechanism" field is a structure worth adopting across the proposals, mine included. The Emerging + public-artefact route for 02/03 is the right call; glad to read the artefacts when they're up. Good working with you.

[RichardBarron27]

Thank you — good working with you too.

Public artefacts for 02 and 03 are now live on Zenodo.

QS-NEW-02 — Agent Identity Forgery:
https://doi.org/10.5281/zenodo.21834202

QS-NEW-03 — RFC 3161 Timestamp Quantum Vulnerability:
https://doi.org/10.5281/zenodo.21834333

Both include demonstration scripts and evidence output.

[nmcitra]

Read both properly — scripts, output, and records. Thank you for building these; going from "gate-controlled tooling" to CC-BY depositions with DOIs in two days is a real answer to the verifiability problem.

What's solid: the Ed25519 signing and verification are real and the output shows them passing, the detection logic is checkable, and labeling the ML-DSA section as a stub rather than passing it off is the right call — it's the kind of honesty that makes the rest believable.

One thing I'd fix before these get cited, though, because it undercuts the revision you already made. Both artifacts frame the attack as Harvest-Now-Decrypt-Later, including in the titles and in the JSON output — attack_type: "Harvest-Now-Decrypt-Later (HNDL)", attack_phase: "harvest". The record for 02 says Shor's recovers the private key "from the captured public key," but the public key was never secret; capturing tokens today gains the adversary nothing they won't have anyway. That's the same point we worked through on the PR, and your revised entry now sorts 01–03 as TNFL. Right now the proposal and its evidence disagree, and the evidence is the DOI'd half.

Zenodo versions cleanly, so this is a metadata-and-wording pass rather than a rebuild.

On the evidence tag: my honest read is these support Emerging strongly and don't yet reach Demonstrated, because no forgery is actually executed — demonstrate_hndl_attack() returns a description rather than running anything. But there's a short path to closing that, and it's the best argument in your proposal:

Your detection claim — no authentication log anomaly, the forgery cryptographically indistinguishable from legitimate — needs no quantum computer to demonstrate. Sign a legitimate token with the key the script already generates, then sign a backdated or privilege-elevated one with the same key, and show both verifying identically with nothing structural separating them. That runs today, on a laptop. Under #18's rule of tagging by the state of everything except the CRQC, a script that shows the indistinguishability directly would have a real claim on Demonstrated in a way that survives review.

Two smaller things: the sample token in rs_2026_020_output.json expires before it's issued (issued_at 07 Aug 06:55, expires_at 06 Aug 23:59) — cosmetic, but it's in the evidence file. And the records carry NIGHTFALL and SPECTER QUANTA layer references; entirely your call in your own publication, though if the entry cites the artifact, the product references come back into the deliverable by that route.

Happy to read a v2.

[RichardBarron27]

Thank you — this is exactly the level of review these need.

You're right on the HNDL/TNFL contradiction. The PR entries were corrected to TNFL but the artefacts weren't updated to match. That's a straightforward v2 fix.

On Demonstrated — the indistinguishability demonstration you describe is the right test and it runs today. Sign a legitimate token and a backdated one with the same key, verify both pass identically, show nothing structural separates them. Building that now.

Will fix the token expiry cosmetic, correct the attack framing throughout, and add the forgery execution to close the Demonstrated gap.

v2 shortly.

[RichardBarron27]

v2 published — TNFL framing corrected throughout, forgery now
executed and verified (both tokens verify identically with the
same public key), token timestamps fixed, product references
removed from evidence output.

https://doi.org/10.5281/zenodo.21834201

[nmcitra]

Saw v2. You ran the forgery instead of softening the claim, which was the harder of the two paths. Two tokens verifying under the same public key is the whole argument in a single artifact.

Nothing further from me. Good turnaround.