Dora NodaIn June 2026, harvest-now-decrypt-later stopped being a warning and became binding American policy. Executive Order 14412, "Securing the Nation Against Advanced Cryptographic Attacks," states that adversaries are already collecting encrypted United States data today with the goal of decrypting it once quantum hardware matures — and orders the federal migration accordingly. One month earlier, the NSA's AI Security Center published its first-ever security guidance for the Model Context Protocol, concluding that MCP's security posture is "highly dependent on implementation discipline rather than protocol guarantees."
Read those two documents together and an uncomfortable question lands on anyone running an MCP server with real infrastructure authority: the deploy call your agent made this morning, the rollback it triggered last week, the secrets it read back through a tool result — every one of those crossed a TLS connection. If that connection was classically encrypted, its ciphertext is worth storing. And unlike a chat transcript, what it contains doesn't expire when the session does.
Harvest now, decrypt later in 60 seconds
The threat model has a name, a NIST document number, and a clock. NIST's transition guidance (Internal Report 8547, first drafted November 2024) describes adversaries collecting encrypted traffic now "with the goal of decrypting it once quantum technology matures" — and names that practice as a main reason the post-quantum migration is urgent. NIST published the first post-quantum standards in August 2024: FIPS 203 (ML-KEM, key exchange), FIPS 204 (ML-DSA, signatures), and FIPS 205 (SLH-DSA). Most credible forecasts put Q-Day — a cryptographically relevant quantum computer — within roughly a decade, around 2035.
The academic framing is a simple inequality. Call Ld the confidentiality lifetime of your data (how long it must stay secret) and Ha the adversary's decryption horizon (how long until they can read stored ciphertext). You are exposed whenever Ld outruns Ha — and for infrastructure secrets, Ld is measured in months to years while Ha keeps shrinking. An encrypted secret that must stay secret for three years is already in the danger zone if decryption arrives within ten: the adversary doesn't need to break anything today. They just need a hard drive.
The three layers, and which one you forgot
A self-hosted platform encrypts roughly three distinct things with three distinct TLS stacks. Two of them are already on the post-quantum migration path. The third is the one this post is about.
| Layer | What's inside the ciphertext | Typical secret lifetime | Post-quantum status |
|---|---|---|---|
| Kubernetes control-plane TLS (etcd, kubelet, API server) | Cluster state, secret material, service-account tokens | Months; cert rotation cycles | Covered by default: Go 1.24 (February 2025) negotiates hybrid X25519MLKEM768 in crypto/tls whenever CurvePreferences is left nil |
| Tenant-facing ACME certificates | App traffic, login cookies, tenant API keys in transit | Days (cert lifetimes are shrinking toward 6-day certs) | In flight: Let's Encrypt's post-quantum certificate path is already underway |
| Your MCP server's own transport | Agent tool calls: deploy triggers, rollback commands, secrets-read outputs — plus the bearer tokens authorizing them | Months to years (see next section) | Usually uncovered: hand-rolled TLS configs, TLS 1.2 floors, classical-only key exchange |
The first two rows are somebody else's migration. Your language runtime upgraded the control plane underneath you, and your certificate authority is handling the edge. The third row is yours. Remote MCP servers speak Streamable HTTP, authenticated as OAuth 2.1 resource servers — and the TLS underneath that HTTP is whatever the server operator configured. In the wild, that frequently means MinVersion: TLS 1.2 and an explicit cipher-suite list pinned years ago for "hardening." TLS 1.2 cannot negotiate post-quantum key exchange at all — ML-KEM hybrid groups exist only in TLS 1.3 — so a floor set for safety reasons quietly opts the whole agent-to-infrastructure channel out of the migration.
The NSA's May 2026 sheet (PP-26-1834) never mentions quantum; it didn't need to. Its finding that MCP security is "highly dependent on implementation discipline" covers the transport too, because unlike a browser or a managed control plane, nobody upgrades your MCP server's TLS but you.
Why agent tool calls are the worst thing to have on tape
Not all stored ciphertext is equally valuable. A captured session is worth keeping only if something inside it is still useful when it finally gets decrypted. Compare what actually travels across the two kinds of MCP sessions:
| Session type | Representative payload | Longest-lived secret in the transcript | Worth storing? |
|---|---|---|---|
| Read-only chat integration | Conversation text, retrieved document snippets | Days: the information value decays as docs change; bearer tokens expire in minutes to an hour | Marginal — stale context |
| Deploy-trigger tool call | Deploy token or API key, registry credentials, target environment config | Months to never: deploy tokens are often created once and rotated never; a kubeconfig can live a year | Yes |
| Secrets-read tool result | Database passwords, third-party API keys returned as tool output | 30–90 days on a good rotation policy; indefinitely on a bad one | Yes — the crown jewels, in plaintext, in the response body |
| Rollback / history call | Prior image digests, environment config, deploy history | Years: tells an attacker exactly what ran, where, and which versions had known CVEs | Yes — reconnaissance that never expires |
Picture the transcript of a single afternoon: the agent calls deploy with a bearer token good for an hour, the server returns success plus the resolved image digest; later the agent calls a secrets-read tool to debug a failing migration and gets back a database password rotated quarterly. The tokens expire. The session ends. But the stored ciphertext still contains a password valid for 90 days, a deploy credential that may never rotate, and a complete inventory of what is running. Every one of those outlives the session that carried it by orders of magnitude.
This is the reconciliation the title owes you: short-lived tokens do not save you from harvest-now-decrypt-later, because the exposure window is set by the longest-lived payload secret in the transcript, not by the token's TTL. A five-minute bearer carrying a ninety-day database password is a ninety-day exposure the moment the ciphertext is stored.
What hybrid post-quantum transport concretely requires
The good news: for a Go-based MCP server, most of the migration is already sitting in the standard library waiting to be allowed. The checklist is short, and every item is verifiable:
- Run Go 1.24 or later. Hybrid X25519MLKEM768 key exchange has been enabled by default in
crypto/tlssince Go 1.24 — no code changes, no new dependencies. If your MCP server binary is older than February 2025, the transport cannot do post-quantum key exchange regardless of anything else on this list. - Leave
CurvePreferencesnil — or audit it. The default includes the hybrid group; an explicitCurvePreferenceslist written for "hardening" in 2023 almost certainly names only classical groups and silently disables the upgrade. This is the single most common way servers opt out without knowing: security-conscious config that predates the default. (Operators of CoreDNS hit exactly this wall — a hardcoded suite list blocking ML-KEM negotiation.) - Floor TLS at 1.3. Post-quantum key exchange groups exist only in TLS 1.3. A
MinVersion: TLS 1.2floor doesn't just permit old handshakes — it permits the entire session your agent's deploy credentials travel in to negotiate classically. Require 1.3 on the MCP endpoint even if you keep 1.2 elsewhere. - Verify the negotiated group, don't assume it. Log or probe the handshake and confirm clients actually land on group
0x11EC(X25519MLKEM768) rather than falling back to classical X25519. A passing test that constrains both ends to only the hybrid group — handshake succeeds or CI fails — is how at least one team proves the claim continuously instead of asserting it in a README. - Expect middlebox friction and plan for it. Chrome's post-quantum rollout had to change TLS codepoints mid-flight (from the Kyber-era
0x6399to the standardized ML-KEM0x11EC) precisely because ossified middleboxes choked on unfamiliar ClientHello bytes. Your MCP clients cross the same enterprise middleboxes browsers do. Keep classical fallback enabled (that's what makes it hybrid) and monitor fallback rates — a sudden spike in classical-only handshakes is either a broken middlebox or an adversary downgrading you, and you want to know which. - Check client support on the agent side. Chrome negotiates X25519+ML-KEM by default (the opt-out was removed in Chrome 138), and Cloudflare reports over 65% of human TLS traffic already using hybrid ML-KEM — so browser-based agents are largely ready. Purpose-built agent runtimes on older TLS stacks are the gap; inventory them the way you'd inventory anything else in the migration.
None of this replaces the OAuth and session hardening the NSA sheet actually asks for. It sits underneath it: post-quantum key exchange protects the transcript, bearer lifecycle protects the session.
What post-quantum transport doesn't fix (do this first)
Honesty requires the ordering stated plainly. The NSA's critique of MCP — no mandatory authentication, no protocol-level access control, bearer tokens without lifecycle management, inconsistent audit logs — describes attacks that work today, no quantum computer needed. A classically breakable key exchange is a future problem; an unrevoked bearer token with deploy scope is a present one. If your MCP server issues hour-long bearer tokens with no rotation, no revocation, and no per-tool scoping, an attacker doesn't need to store your ciphertext for a decade. They replay the token this afternoon.
So the sequence is: scope tokens per tool and keep them short-lived first, fix revocation and audit logging second, and migrate the transport to hybrid post-quantum key exchange third. The earlier section's "short-lived doesn't save you" and this section's "keep them short-lived" are consistent once the rule is stated precisely: token TTL bounds live replay; payload lifetime bounds harvest-now-decrypt-later. Short TTLs shrink the first window. Only post-quantum transport shrinks the second. One exception strengthens the rule rather than breaking it: sender-constrained tokens (DPoP or mutual-TLS-bound) can't be replayed even after the transcript is decrypted, because possession of the ciphertext was never sufficient to use them. If your agent-to-infrastructure calls use bound tokens, your HNDL exposure is already closer to the payload floor than the token ceiling suggests.
The clock is policy now
Cloudflare has set a 2029 hard deadline for its own post-quantum roadmap. Federal systems are migrating under executive order. Browser traffic is already majority-hybrid. The MCP transport layer — the youngest, least standardized, most hand-configured TLS surface in the stack — is migrating on nobody's schedule but its operator's. For a read-only chat integration, that's a tolerable lag. For a server whose tool calls carry deploy credentials and return live secrets, the lag is the exposure: every classically encrypted session between now and migration day is a transcript someone can afford to keep.
Audit the three layers, fix the third row, and prove the negotiated group in CI. The adversary is already doing the cheap part — storing. Don't make the expensive part — decrypting — worth their while.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
