Quantum-Safe AI: Protecting Agents, Models & Training Data

Why a quantum guide ends in AI

Everything in this series — the two kinds of locks, what Shor breaks, the tower of RSA, ECC, PKI and TLS — describes the security substrate of modern software. AI systems are modern software. They just happen to concentrate an unusual amount of long-lived, high-value secret in one place, and to add a new layer of machine-to-machine trust (agents calling agents, tools, and model endpoints). Both of those make the quantum question sharper, not softer.

None of what follows is new cryptography — it is the same primitives from the rest of the series, seen from where your AI systems actually run: the data they hold, the channels they open, and the artifacts they ship.

Harvest-now-decrypt-later meets AI

Harvest now, decrypt later (HNDL) is the attack where an adversary records your encrypted data today and waits for a quantum computer to unlock it. The data that matters most for HNDL is data whose value survives for years. AI is full of exactly that:

If any of these move over today’s TLS using a classical key exchange, a patient attacker can capture the ciphertext now and read it after Q-day. Mosca’s inequality (X + Y > Z) applies directly: if your model or corpus must stay secret for X years, migration takes Y years, and a quantum computer arrives in Z years, then whenever X + Y exceeds Z you are already late.

The crypto under your agents

An agent system is a web of machine-to-machine trust: an orchestrator calls sub-agents, agents call tools and APIs, and everything talks to model endpoints — increasingly over the Model Context Protocol (MCP). Every one of those hops is secured by the public-key cryptography this series showed quantum breaks:

• TLS handshakes establish each channel using a key exchange (ECDH) that Shor’s algorithm defeats.
• Certificates and PKI prove which service is which — the same trust anchors covered in what breaks.
• Signed tokens (the identity an agent presents) rely on RSA or ECC signatures.

This is where quantum risk collides with an anti-pattern the wider guide already warns about: implicit agent-to-agent trust. If the cryptography that authenticates one agent to another can be broken, an attacker can impersonate a trusted agent or sit in the middle of a tool call — the confidentiality and authenticity damage described in the threat part, now aimed at your control plane. The same logic extends to poisoned knowledge bases and boundaryless data egress: broken transport crypto weakens the very boundaries those patterns depend on.

Fixing the agent channel is not theoretical — hybrid post-quantum TLS is already shipping. The X25519MLKEM768 key exchange (a classical curve run alongside ML-KEM) is on by default in current Chrome and Firefox, supported in OpenSSL 3.5, AWS-LC and BoringSSL, and terminated at the edge by Cloudflare and other CDNs. For an AI control plane that means the outer hops — client-to-gateway, and service-to-service behind a modern proxy — can be quantum-safe today with a configuration change, not a rewrite. The catch is internal and quantitative: a hybrid handshake carries roughly one to two kilobytes of extra key material per connection, and a chatty mesh of agents, tools, and MCP calls re-handshakes far more often than a typical web app. Inventory which hops actually renegotiate per call, and lean on connection reuse and session resumption before you worry about the handshake cost.

Signing models & the MLBOM

The assessment part introduced the cryptographic bill of materials (CBOM) — a living inventory of where cryptography lives. AI has a natural extension: the MLBOM (machine-learning bill of materials), which records the datasets, base models, and dependencies that went into a model, and pairs it with model signing so you can prove an artifact was not tampered with between training and deployment.

Those signatures use exactly the algorithms that must migrate: today’s RSA/ECC signing should move to the new ML-DSA and SLH-DSA standards. The same applies to signing AI-generated code before it ships — a control the wider guide leans on when it argues for disciplined, gated agent output. Provenance you can’t cryptographically trust is provenance in name only.

Concretely, this isn’t a new tool to invent — it’s the software supply-chain stack you already use for containers and packages, pointed at models: Sigstore/cosign to sign the artifact, in-toto attestations to bind that signature to how the model was built, and a CycloneDX bill of materials extended with ML components. Hugging Face already supports signing model repositories this way. An MLBOM entry is deliberately mundane — it records what a reviewer needs in order to trust the artifact:

component:
  type: machine-learning-model
  name: support-triage-classifier
  version: 2026.06
  hashes: [ sha-256: 9f2c… ]        # the exact weights
  modelCard:
    base-model: llama-3.1-8b          # what it was built on
    datasets: [ tickets-2019-2025 ]   # what it learned from
  signature:
    algorithm: Ed25519                # ← today; migrate to ML-DSA

Every one of those signatures is an RSA, ECDSA, or Ed25519 signature under the hood — exactly the primitive that must move to ML-DSA (or hash-based SLH-DSA for the longest-lived roots of trust). Sign models and generated code now with whatever you have; just make the signing algorithm a swappable choice so the migration is a config change, not a re-plumb.

Crypto-agility is model-agility

The migration part’s central lesson was crypto-agility: don’t hard-code an algorithm; design so you can swap it quickly, this time and every time after. AI engineers already practise the same instinct under a different name — model-agility, the ability to change model or provider behind an abstraction without rewriting the application.

The parallel is literal. The model-agility you already write and the crypto-agility you need have the same shape — a factory keyed by configuration that returns something the call site uses without knowing the brand:

# Model-agility you already write:
llm   = get_model(config.model)     # "gpt-4o" | "claude-3.7" | "llama-3"
reply = llm.complete(prompt)

# Crypto-agility is the identical move:
kem   = get_kem(config.kem)         # "x25519" | "ml-kem-768" | "hybrid"
ct, shared = kem.encapsulate(peer_public_key)

If config.kem can flip from x25519 to hybrid to ml-kem-768 without touching a single call site, you are crypto-agile. If it can’t, that is the work — and it is the same refactor you would do to stop hard-coding a model.

What to actually do

When you run the readiness assessment on an AI system, add four AI-specific lines to the checklist:

Run in hybrid where you can (classical + ML-KEM together) so you get protection today without betting everything on a young algorithm, and prefer platforms that already ship PQC — see Quantum-Safe on Microsoft Platforms.

HNDL (harvest now, decrypt later)

Recording encrypted data today to decrypt once a quantum computer exists; the core reason AI’s long-lived data is exposed now.

Embeddings

Numeric vector encodings of content; recoverable enough that leaked embeddings can leak the source text.

RAG

Retrieval-augmented generation — an agent fetching from a private knowledge base at query time.

MLBOM

Machine-learning bill of materials: an inventory of the datasets, base models, and dependencies behind a model — the AI analogue of the CBOM.

Model signing

Cryptographically signing model artifacts so tampering is detectable; must migrate to PQC signatures.

Sigstore / cosign

Software supply-chain signing used for containers, packages, and now model artifacts — the practical way to sign weights today.

in-toto

A framework for signed attestations that bind a signature to how an artifact was built, not merely that it was signed.

Hybrid

Running a classical key exchange and a post-quantum one together (e.g. X25519 + ML-KEM) so security holds if either one survives.

Model-agility

Designing so a model or provider can be swapped behind an abstraction — the same discipline as crypto-agility.

TLS / PKI / RSA / ECC / ECDH

The transport-security stack quantum breaks: TLS (Transport Layer Security), PKI (Public-Key Infrastructure), RSA (Rivest–Shamir–Adleman), ECC (Elliptic-Curve Cryptography) and ECDH (Elliptic-Curve Diffie–Hellman) key exchange.

MCP (Model Context Protocol)

The emerging protocol agents use to reach tools and model endpoints — another channel to secure with PQC.

ML-KEM / ML-DSA / SLH-DSA

The post-quantum standards to migrate to: ML-KEM for key exchange, ML-DSA and SLH-DSA for signatures.

CBOM (Cryptographic Bill of Materials)

The crypto inventory the MLBOM extends for AI systems.

PII (Personally Identifiable Information)

Personal data in prompts and logs that keeps its sensitivity for years — an HNDL target.

PQC (Post-Quantum Cryptography)

The quantum-resistant algorithms AI transport and signing must adopt.

What to carry forward

• AI concentrates long-lived secrets (data, weights, embeddings) — the prime harvest-now-decrypt-later targets.
• Agent, tool, and model channels run on the TLS/PKI/token crypto quantum breaks — the foundation of agent-to-agent trust.
• Extend the CBOM to an MLBOM and sign models (and generated code) on post-quantum signatures.
• Crypto-agility is model-agility: put the algorithm behind an abstraction you can swap.
• Post-quantum readiness isn’t adjacent to AI security — for AI-first teams, it is AI security.

Go deeper on two axes

This capstone is the map. Two companion articles are the territory — each takes one axis from above and works it end to end:

• Quantum-Safe Agent Channels — the operator’s guide to the transport under an agent mesh: which hops open a TLS session, why hybrid key exchange (X25519MLKEM768) is already shippable, what the extra handshake bytes cost a chatty system, and the order to migrate.
• Signing Models & the MLBOM — the supply-chain half: why a hash isn’t provenance, signing weights with Sigstore and in-toto, a worked CycloneDX MLBOM, and why signatures migrate on a different clock than key exchange.

That brings the field guide home. ← Back to the full series, or explore the AI Agent Engineering Guide the anti-patterns above come from.

Understand it in your own words

Paste into any AI assistant to check yourself:

I'm connecting post-quantum cryptography to AI systems. Quiz me one
question at a time, correcting me gently:

1. Which AI assets are the biggest harvest-now-decrypt-later targets, and why?
2. Which cryptography secures agent-to-agent, tool, and model channels, and
   what does quantum do to it?
3. What is an MLBOM, and how does it relate to the CBOM and model signing?
4. Why is crypto-agility "the same discipline" as model-agility?
5. What four AI-specific lines belong on a quantum-readiness checklist?