Quantum-Safe Agent Channels: PQC for TLS, Certificates & MCP

The channel map

Before you can secure the transport, you have to see it. An agent system opens far more sessions than a typical web app, and they are easy to miss because most are machine-to-machine and never touch a browser. Every one of these hops is a TLS session with a key exchange, a certificate, and often a signed token:

The pattern that makes AI different is fan-out and frequency. A single user request can trigger dozens of downstream sessions, and a long-running agent loop re-opens them constantly. That density is what turns a per-handshake cost into a system-level one — the point we return to in the cost section.

What is shippable today

The most important thing to know is that this is no longer a waiting game for the key-exchange half. Hybrid key exchange — running a classical algorithm and a post-quantum one together so the session is safe if either holds — is already deployed at internet scale. The concrete name to look for is X25519MLKEM768: the X25519 elliptic curve run alongside ML-KEM-768.

For an AI control plane, that coverage maps directly onto the channel map. Any hop that terminates TLS at a modern proxy, gateway, or CDN — and any hop between services written in Go or linked against OpenSSL 3.5 — can negotiate a quantum-safe key exchange today with a configuration change. The remaining gaps are usually older runtimes and language TLS stacks that have not yet shipped the hybrid groups; those are the ones to inventory and track, not to block the whole migration on.

The real cost: a chatty mesh

Hybrid key exchange is not free, and the cost lands in a place that matters more for agents than for web pages. An X25519 key share is 32 bytes; an ML-KEM-768 public key is about 1,184 bytes and its ciphertext about 1,088 bytes. So a hybrid handshake carries roughly one to two kilobytes of extra key material per connection, split across the client and server messages.

On a single page load that is invisible. On a mesh it compounds, for three reasons specific to agent systems:

• Fan-out. One user turn can open dozens of downstream sessions; the handshake tax is paid on each.
• Short-lived connections. Serverless functions, per-call tool invocations, and cold model endpoints often open a fresh connection and immediately close it — the worst case, because the expensive handshake is never amortised.
• Larger first flight. The bigger ClientHello can spill beyond the initial congestion window or a single packet, occasionally tripping old middleboxes that assumed a small first flight.

The fix is not to avoid post-quantum crypto — it is to handshake less. Every technique that reduces full handshakes pays for itself twice over once the handshake is heavier:

The practical move is to inventory which hops actually re-handshake per call before optimising anything. In most meshes a handful of short-lived, high-frequency edges dominate the cost; fix those with pooling and resumption and the extra kilobyte becomes a rounding error.

Key exchange first, signatures later

The single most useful sequencing rule is that a TLS session has two kinds of public-key crypto on two different clocks, and they do not migrate together.

This is harvest-now-decrypt-later applied to your control plane. An eavesdropper who records a classical key exchange between two agents today can recover that session key once a quantum computer exists, and then read everything the session carried — prompts, tool outputs, retrieved documents. That is why key exchange is the emergency. A signature, by contrast, is only useful while it is being verified; a certificate forged in 2035 does nothing to traffic captured in 2026. Post-quantum signatures are also much larger, which balloons certificate chains and token sizes, so there is a real engineering cost to rushing them.

The exception worth calling out: long-lived roots of trust. A root CA certificate, a firmware-signing key, or a model-signing root that must stay valid for ten to fifteen years is effectively harvested too — an attacker who can forge it in the future can undermine everything chained under it. Those move to conservative, hash-based SLH-DSA on a nearer horizon. Leaf certs and short-lived tokens can wait for ML-DSA to settle. Provenance signatures for models are their own topic — see Signing Models & the MLBOM.

A concrete rollout order

Put the pieces together and the migration has an obvious shape: start where one change covers the most hops and the crypto libraries are already ready, then work inward to the chatty edges.

Finally, make the change observable. Log the negotiated key-exchange group on every connection and chart the share of traffic that is hybrid. A migration you cannot measure is a migration you cannot finish — and “percent of agent hops on X25519MLKEM768” is exactly the kind of line that belongs on the readiness dashboard.

Hybrid

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

X25519MLKEM768

The TLS 1.3 hybrid key-exchange group pairing the X25519 elliptic curve with ML-KEM-768; enabled by default in current browsers.

TLS

Transport Layer Security — the protocol securing almost every agent, tool, and model connection; its key exchange is what quantum breaks.

Key exchange

The step that agrees a session’s secret key; the harvest-now-decrypt-later target, so it migrates first.

Session resumption

Reusing a previously negotiated TLS secret (a pre-shared key) so a reconnect skips the expensive key exchange entirely.

MCP

Model Context Protocol — how agents reach tools and model endpoints; remote MCP rides on TLS like any other channel.

PKI

Public-Key Infrastructure — the certificates and authorities that prove which service is which; its signatures migrate on the slower clock.

ML-KEM

The post-quantum key-encapsulation standard (FIPS 203) that replaces classical key exchange.

ML-DSA / SLH-DSA

The post-quantum signature standards (FIPS 204 / 205); SLH-DSA is the conservative, hash-based choice for the longest-lived roots of trust.

HNDL (harvest now, decrypt later)

Recording encrypted traffic today to decrypt once a quantum computer exists — the reason key exchange is urgent.

What to carry forward

• Map the hops first — agent, tool, model, and MCP channels are all TLS sessions, and there are more of them than a web app has.
• Hybrid key exchange is shippable today (X25519MLKEM768) — on by default in browsers, in OpenSSL 3.5, Go, AWS-LC/BoringSSL, and at the CDN edge.
• The cost is operational, not cryptographic: ~1–2 KB per handshake bites a chatty mesh, so handshake less — pool, keep-alive, resume.
• Migrate key exchange first (harvested now); move certificate and token signatures on a slower clock, starting with long-lived roots.
• Roll out edge → mesh → east-west → signatures, and measure the share of hybrid traffic.

Next in The AI Frontier: once the channels are safe, prove the artifacts are authentic — Signing Models & the MLBOM →. Or return to the Quantum-Safe AI capstone, or the full series.

Understand it in your own words

Paste into any AI assistant to check yourself:

I'm making the transport under an agent system quantum-safe. Quiz me one
question at a time, correcting me gently:

1. Which hops in an agent system open a TLS session, and why are there
   more of them than in a typical web app?
2. What is X25519MLKEM768, and where is it already deployable today?
3. Why does the ~1-2 KB hybrid handshake cost matter more for a chatty
   agent mesh than for a web page, and what reduces it?
4. Why does key exchange migrate before certificate signatures?
5. What is a sensible rollout order, and what would you measure?