Two weeks ago, I looked at the OpenAI and Hugging Face incident. Overblown headlines, basic hygiene failures. Treat that as AI on AI Part I. [1]
Last week, in Part II, I orchestrated the Cloud Security Alliance (CSA) post-mortem into actions a CISO can execute on the ground and show tangible risk reduction in three months. [2]
The same week, Anthropic disclosed that Claude Mythos Preview had uncovered a previously unknown structural weakness in HAWK, a candidate post-quantum signature scheme. An algorithm that had survived two years of NIST expert review was withdrawn from the standardisation process the following day. Sixty hours of semi-autonomous work. Roughly a hundred thousand US dollars in API credits. A price point clearly within reach of state actors and well-funded research labs. [3][4]
Convergence, and what it changes
The same AI capability that broke into Hugging Face using weak passwords and unauthenticated endpoints also broke down the mathematics of a candidate cryptographic algorithm.
HAWK was a PQC candidate. It was designed to resist a quantum computer, yet was killed by an AI model, using classical mathematics, that spotted a weakness expert cryptographers had missed for over two years. This convergence of AI accelerating both, hacking the infra and cracking the math, cannot be ignored.
Until now, we were preparing for a predicted event in the future (Q-Day).
Now, we must prepare for an unpredictable event that could happen anytime.
This Part III is therefore about that convergence. For a CISO, it changes what “AI risk” means.
Marin Ivezic, CEO of Applied Quantum, covered this ground in AI Hacking Theater and the Crypto-Agility Wake-Up Call. Anyone who has followed his work will recognise the depth he brings to quantum and cryptographic questions. It is the definitive analysis of what that convergence means and what actually defends against it.
Marin’s argument is for heterogeneity and crypto-agility: avoiding reliance on a single mathematical family across the entire crypto stack, and building the architectural capability to swap algorithms without rebuilding the applications themselves. I will not restate his argument further. Please take the time to read his article. [5]
Extending the catalogue of deliverables orchestrated from CSA’s post-mortem
In Part II, I proposed a catalogue of deliverables from CSA’s post-mortem recommendations that a CISO can execute in one quarter to demonstrate tangible risk reduction against agentic AI intrusions. Function-owned slices, three-month deadlines, evidence over intent, weekly coordination without a steering committee. [2]
This convergence, however, makes it necessary to extend that catalogue with an additional set of deliverables to accomplish crypto-agility and ensure heterogeneity. They are described in the table below and run as a new control track owned by Engineering, Operations, and Risk together, executed under the same weekly cadence.
Our teams run the Part II deliverables and the Part III deliverables in parallel. The functional leads bring both to the same meeting, and both are tracked in the same folder of artefacts. Every deliverable below produces evidence a board and an underwriter can read directly, in the same way the agent-governance deliverables in Part II do. Same vocabulary. Completeness, effectiveness, efficiency. What it demonstrates for the business.
| Control | Deliverable | Metrics | Demonstrates |
|---|---|---|---|
| Engineering & Data | |||
|
Cryptographic inventory
Recommended on top of what CSA has advised.
|
Every place a cryptographic algorithm is used, named, classified, and owned. Covers application code, protocols, HSMs, certificates, VPN tunnels, and third-party dependencies. Rationale: crypto-agility begins with visibility. Most enterprises discover thousands more cryptographic touchpoints than they thought once they look properly, and every one of those is a place we may need to swap an algorithm on short notice. |
Completeness: percentage of production systems covered by the inventory. Effectiveness: number of previously unknown crypto touchpoints discovered per month. Efficiency: time from a new system going live to being registered in the inventory. |
Transparency Faster incident response |
|
Algorithm abstraction on critical services
Recommended on top of what CSA has advised.
|
For the top ten highest-value services, every cryptographic call goes through an interface that lets the algorithm behind it be changed without touching the calling code. Rationale: if the cipher is hard-coded into the application, swapping it means rewriting the application. Abstraction is what turns crypto-agility from a slogan into something operations can actually do in a maintenance window. |
Completeness: percentage of the top ten critical services with abstraction in place. Effectiveness: time to swap a test algorithm in a controlled environment. Efficiency: reduction in code changes required per algorithm swap. |
Meaningful risk reduction Operational efficiency |
| Operations & Platform | |||
|
Hybrid deployment and rehearsed update paths
Recommended on top of what CSA has advised.
|
A hybrid classical-and-post-quantum key exchange live on the two or three highest-value external connections. One end-to-end drill of pushing a new cryptographic algorithm across the estate: endpoints, HSMs, certificate chains, and embedded devices. Time-to-swap documented per category. Rationale: hybrid deployment means running a classical algorithm we trust today alongside a post-quantum one. To break the connection, an attacker must break both. Google and Cloudflare have been running this in production TLS since 2023; there is no reason to wait for PQC to feel mature. The update drill answers an honest question: can we actually deploy a new algorithm across our estate in weeks, not years? |
Completeness: percentage of highest-value external connections running hybrid. Effectiveness: time from a decision-to-swap to full deployment across the estate. Efficiency: self-inflicted outages during a hybrid or update drill. |
Tangible resilience Operational efficiency |
| Risk & Legal | |||
|
Algorithm diversity policy and crypto-agility programme ownership
Recommended on top of what CSA has advised.
|
A published policy that no single mathematical family (for example, lattice) carries both our key exchange and our digital signature duties. A named owner for the crypto-agility programme, with authority to keep the inventory current, run drills, and report to the board. Rationale: cryptography does two main jobs, key exchange and digital signatures. It is tempting to standardise on one mathematical family for both because it is efficient; it is also a single point of failure. Pair a lattice signature scheme (ML-DSA) with a hash-based one (SLH-DSA), so a single mathematical breakthrough does not take out both jobs on the same day. And crypto-agility is a programme that needs a permanent owner, not a project that ends. |
Completeness: presence of the policy with named owner, board acknowledged. Effectiveness: number of new deployments blocked or reshaped by the policy. Efficiency: mean time from a new cryptanalysis result to a reviewed enterprise position. |
Cleaner board conversation Reduced legal exposure |
Two assurances as we commence
Hybrid deployment is production-proven at internet scale
Google Chrome and Cloudflare have been running hybrid classical-and-post-quantum key exchange in TLS since 2023. Chrome enabled it from August 2023. [7] Cloudflare enabled it in beta from October 2022 and marked it Generally Available in September 2023. [8] Both initially deployed the draft Kyber algorithm and have since migrated to its final NIST-standardised form, ML-KEM.
Marin has documented the trajectory of this deployment [10], and reports that by late 2025 quantum-safe connections crossed the 50% threshold across Cloudflare’s network. [11] What we are asking our teams to do at enterprise scale, these providers have proven works at internet scale.
Algorithm diversity is why NIST standardised two signature algorithms, not one
ML-DSA (FIPS 204) is lattice-based. SLH-DSA (FIPS 205) is hash-based. NIST published both deliberately, so that if a fundamental weakness were ever found in lattice mathematics, digital signatures would not all fall on the same day. SLH-DSA rests on hash function security, a mathematically different and more conservatively tested foundation. [9]
Marin’s analysis of NIST’s third-round signature candidates makes the concentration risk plain: two of the three current signature standards are lattice-based, and SLH-DSA is the hash-based backup that would survive if lattice mathematics were ever broken. [12] That is precisely what the last deliverable asks for.
Two cautions as we execute
It is comforting to know that the already-standardised post-quantum algorithms (ML-KEM, ML-DSA, and SLH-DSA) are not affected by this result, and that no deployed cryptography needs an emergency patch this week. But as we build these deliverables, Marin cautions us against two flavours of vendor pitch.
The first: security products newly rebranded as “AI-resilient,” “Mythos-resistant,” or “autonomous-agent-proof.” Marin calls this out in his crypto-agility piece. Do not buy them as a substitute for doing the fundamentals properly. Some of these tools will be useful. All of them will carry an AI premium. None will compensate for the discipline we agreed on in Part II. [5]
The second: proprietary “quantum-safe” or “mathematically proven unbreakable” cryptography. Marin has written another definitive piece explaining why nobody should buy these. If a post-quantum algorithm is not specified in a NIST standard or approved by a national cryptographic authority, do not buy it, pilot it, or let it near your data. [6]
How this fits with what we already agreed
Nothing about running this changes what we agreed in Part II. Same weekly cadence. Same ten-minute-per-function meeting. Same one folder of artefacts. Same principle: the CISO’s job is to unblock, not to build. When Engineering needs a decision to start the inventory work, or Operations needs authority to book a maintenance window for the hybrid drill, that decision gets secured the same week, not added to a backlog.
The enterprise-level reporting emerges naturally from the artefacts, the way it does for the agent-governance deliverables. An inventory that reconciles across functions. A tested hybrid connection. A written diversity policy. A named programme owner. No parallel workstream needed. Just the functions doing the work, and the CISO coordinating them.
Closing
Marin’s piece ends with a line worth noting: forget Q-Day predictions, do good cybersecurity, do it faster, and build crypto-agility into the architecture. [5]
Nothing about these incidents demands a new discipline. What they demand is better enforcement of the disciplines we already have, faster, and applied to layers of the stack we used to treat as somebody else’s problem.
Part I said the headlines were overblown. [1]
Part II said the theory was already written, and it was time to put our hands in the mud. [2]
Part III says the mud is bigger than we thought. So is the reward for being ahead of it.
Sources
1. Grey Orbits, “AI on AI: Overblown Headlines Likely to Spook Insurers”
2. Grey Orbits, “AI on AI Part II: Actions for a CISO amidst agent chaos”
3. Anthropic, “Discovering Cryptographic Weaknesses”
4. NIST, Post-Quantum Cryptography
5. Marin Ivezic (PostQuantum.com), “AI Hacking Theater and the Crypto-Agility Wake-Up Call”
7. Chromium Blog, “Protecting Chrome Traffic with Hybrid Kyber KEM” (August 2023)
8. Cloudflare Blog, “Post-quantum cryptography goes GA” (September 2023)
9. NIST, FIPS 205: Stateless Hash-Based Digital Signature Standard
10. Marin Ivezic (PostQuantum.com), “Hybrid Cryptography for the Post-Quantum Era”
11. Marin Ivezic (PostQuantum.com), “Cloudflare Secures Majority of Internet Traffic with PQC”
12. Marin Ivezic (PostQuantum.com), “NIST Selects 9 Third-Round PQC Signature Candidates”
About the author
Viren Mantri is a cybersecurity advisor and former senior technology leader across Standard Chartered, UBS, McAfee, and KPMG. After three decades at the intersection of technology, risk, and regulation, he now helps organisations cut through complexity and make better security decisions.
CC-BY Viren Mantri, 2026, licensed under a Creative Commons Attribution 4.0 International License.
Disclaimer: All views expressed here are entirely mine.