Executive summary
Enterprise adoption of artificial intelligence has outpaced the security disciplines built to protect it. Model registries, inference APIs, agent networks, vector databases, and confidential computing enclaves have become foundational infrastructure — and every layer of that infrastructure depends on classical asymmetric cryptography that a cryptographically relevant quantum computer (CRQC) will break.
The prevailing enterprise assumption is that AI systems inherit the security posture of the cloud infrastructure they run on. That assumption is wrong. AI systems have their own distinct cryptographic surface — one that spans model provenance, inference session integrity, remote attestation, agent identity, and training data lineage. Each of these layers is quantum-vulnerable today. Each of them is being targeted for Harvest Now, Decrypt Later (HNDL) collection at this moment.
This whitepaper defines the AI cryptographic stack, enumerates the ten layers where quantum-vulnerable cryptography lives in production AI systems, describes the specific threat scenarios that emerge when a CRQC becomes available, catalogs the enterprise artifacts that provide visibility into AI PQC posture, and outlines the migration path that AI-forward enterprises must begin now.
The window to act is short. NIST is developing AI-specific PQC guidance. The EU AI Act's high-risk system provisions will require cryptographic assurance. FDA premarket review for AI medical devices is moving in the same direction. And the underlying threat — that adversaries are harvesting enterprise prompt traffic, model download sessions, and agent authentication tokens today — is already in motion.
1. Why AI is a distinct cryptographic environment
Cloud, IT, and OT are the three environments most enterprises recognize as needing PQC migration. AI is emerging as a fourth — architecturally distinct, cryptographically dependent, and operationally consequential.
The distinction matters because AI systems have properties that traditional environments do not:
Model artifacts are code that behaves like data. A poisoned foundation model does not fail loudly the way malicious code does. It performs correctly on standard benchmarks and misbehaves only on adversary-chosen inputs. This makes cryptographic provenance the primary defense — and cryptographic provenance is exactly what a CRQC breaks.
Inference is a session-based data flow with high-value payloads. Enterprise prompts to LLM APIs routinely contain legal strategies, patient records, source code, engineering designs, and financial analysis. Every prompt is a TLS session, every session key is derived from a classical key exchange, and every session is a candidate for HNDL harvesting.
AI systems are increasingly multi-agent, multi-tenant, and multi-cloud. The identity fabric that authenticates one agent to another, one enclave to another, one model to another, is built on classical PKI. Compromise the identity fabric and the entire architecture of trust collapses at once.
Regulatory pressure is arriving simultaneously with the quantum timeline. Unlike OT, where PQC guidance is arriving before enforceable mandates, AI has both maturing at the same time — NIST AI RMF, EU AI Act, ISO/IEC 42001, FDA premarket AI guidance, and the growing body of sector-specific AI governance requirements.
For these reasons, treating AI as "just workloads that run in the cloud" is a category error. AI is its own environment. It requires its own PQC posture assessment. And it is currently the least mature of the four in terms of quantum readiness.
2. Where cryptography lives in the AI stack
There are ten identifiable layers where classical asymmetric cryptography is embedded in production AI systems. Each is quantum-vulnerable. Each requires an independent migration path.
2.1 Model provenance and integrity
Every foundation model, fine-tuned model, and inference endpoint has cryptographic signatures proving where it came from. Hugging Face uses Sigstore for model signing. OpenAI, Anthropic, and Google sign model updates and API responses. Every model file downloaded from a registry is verified against a signature — RSA or ECDSA today, quantum-vulnerable tomorrow.
A CRQC-enabled adversary can forge a signature on a poisoned model. Every downstream consumer accepts it as legitimate. Detection is nearly impossible because the model still performs correctly on standard benchmarks — the poisoning targets specific edge cases like decision-making in critical infrastructure control loops or medical diagnosis. This is the AI equivalent of the TRITON attack on safety systems: silent, invisible, and consequential only at the moment it matters.
2.2 Model registry and artifact stores
MLflow, Weights and Biases, Databricks Model Registry, SageMaker Model Registry, Vertex AI Model Registry, Azure ML, and Hugging Face Enterprise all authenticate their artifact push and pull operations with TLS and OAuth. The signing keys, the API tokens, the TLS certificates — all quantum-vulnerable. An adversary with derived private keys can push malicious model versions to your registry with valid signatures, and every deployment pipeline that pulls from that registry will treat them as authorized.
2.3 Inference API endpoints
Every call to an LLM API — OpenAI, Anthropic, AWS Bedrock, Google Vertex, Azure OpenAI — is a TLS session. The API key, the mTLS certificate, the JWT token — all protected by classical asymmetric crypto. Enterprises are sending prompts and receiving responses over sessions that are being harvested today. For regulated industries this is a rapidly growing HNDL exposure: prompts to enterprise LLMs routinely contain PHI, PII, financial data, trade secrets, and classified reasoning. A decade of prompt history is being accumulated on adversary storage right now.
2.4 Training data provenance
Where the training data came from is increasingly cryptographically attested. The EU AI Act, NIST AI RMF, and emerging FDA guidance on AI medical devices all require attestation of training data lineage. Those attestations are signed. The signing keys are quantum-vulnerable. Forge the signing key and an adversary can attest to training data that never existed — or hide the presence of training data that did.
2.5 Federated learning and secure aggregation
Federated ML systems — TensorFlow Federated, NVIDIA FLARE, Meta federated learning, Substra — rely on cryptographic protocols including secure aggregation, differential privacy noise generation, and secure multi-party computation. Every one of these protocols uses elliptic curve pairings or RSA today. Every federated learning round has quantum-vulnerable cryptography in the aggregation step, meaning the privacy guarantees of federated learning collapse the moment a CRQC exists.
2.6 Confidential computing enclaves
AI workloads increasingly run in trusted execution environments: Intel SGX, AMD SEV-SNP, NVIDIA Confidential Computing on H100 and H200. Each of these enclaves produces remote attestation certificates that prove to a verifier that the model is running in a genuine enclave with the expected code. Those attestations are RSA or ECDSA-signed. The entire promise of confidential AI — "your model runs in a verified enclave, your data cannot leak" — depends on remote attestation. Break the attestation crypto and the confidential guarantee evaporates.
2.7 Agent-to-agent authentication
Multi-agent AI systems — LangChain agent networks, MCP servers, Salesforce Agentforce, Microsoft Copilot Studio agents, AWS Bedrock Agents — authenticate to each other using service identities backed by certificates. As agent architectures become the deployment pattern for enterprise AI, the identity fabric between agents becomes critical infrastructure. Forge an agent's identity certificate and an adversary can insert a malicious agent into the workflow. It authenticates correctly. It executes actions. It disappears without a trace.
2.8 Vector database and embedding store access
Pinecone, Weaviate, Milvus, Qdrant, ChromaDB — all authenticated via API keys and TLS. Embeddings themselves are typically not encrypted at rest, but the access control layer is quantum-vulnerable. Forge the credentials and an adversary can read every embedding, understand every semantic relationship in the corpus, and inject malicious embeddings that steer retrieval behavior at inference time.
2.9 RAG pipeline authentication
Retrieval-Augmented Generation pipelines pull from document stores, databases, and knowledge bases using service accounts and OAuth tokens. Every connection is TLS-protected with quantum-vulnerable cryptography. RAG is the primary architecture pattern for enterprise LLM deployment — and every RAG session that touches sensitive corporate data today is a HNDL target.
2.10 Guardrail and policy enforcement
Prompt injection defenses, output filters, and AI safety guardrails — NVIDIA NeMo Guardrails, Lakera Guard, Protect AI, Robust Intelligence, HiddenLayer — enforce their policies via signed policy files and TLS-protected control APIs. If an adversary forges the signature on a policy file, they can silently disable the guardrail. The AI system continues to appear compliant while its safety layer has been surgically removed.
3. The AI-specific threat model
The threats to AI systems from quantum-vulnerable cryptography differ in character from OT or IT threats. They are more subtle, more scalable, and more difficult to detect after the fact.
3.1 Model poisoning at scale
An adversary with a CRQC can forge Hugging Face, OpenAI, or vendor signatures on poisoned foundation models. Every enterprise pulling that model accepts it as legitimate. The poisoning targets specific behaviors — an incorrect diagnosis on chest X-rays showing a specific pattern, an incorrect risk score on loan applications from specific demographics, an incorrect decision in industrial control loops when specific process conditions are present. Standard benchmarks do not detect it. Production monitoring does not detect it. Only the adversary knows which inputs trigger the poisoned behavior, and only they know when to invoke it.
3.2 Prompt harvest and retroactive decryption
Enterprise prompts to LLM APIs contain the highest-value data an organization produces. Legal strategy documents. M&A analysis. Patient records queried through clinical AI. Source code shared with coding assistants. Engineering designs sent to specialized models. Every one of these prompts travels over a TLS session whose key exchange is classical. Nation-state adversaries with tap points on the internet backbone are harvesting these sessions today. When a CRQC arrives, a decade of enterprise prompt history becomes readable.
3.3 Inference response tampering
An adversary who can forge TLS certificates can inject responses into LLM API calls. The user asked "what does this radiology image show?" and the response is quietly altered. The user asked "should I approve this loan?" and the answer is flipped. The user asked "is this contract clause enforceable?" and the analysis is skewed. Detection requires cryptographic verification of the response — which is exactly the defense that PQC migration provides and that classical crypto no longer will.
3.4 Attestation forgery in confidential AI
The entire confidential AI value proposition depends on remote attestation. Enterprises deploying models in Intel SGX, AMD SEV, or NVIDIA H100 confidential computing enclaves are trusting that the attestation certificate proves the model is running where it should be, with the code it should be. If the attestation crypto is broken, the confidentiality guarantee is broken. Every confidential AI deployment built on classical attestation crypto has a defined shelf life that ends when a CRQC arrives.
3.5 Agent identity forgery
Multi-agent AI systems represent the fastest-growing category of enterprise AI deployment. LangGraph, CrewAI, AutoGen, MCP-based agent networks, and Agentforce all rely on service identity crypto to authenticate agent-to-agent communication. In these architectures, a single forged identity certificate compromises the entire workflow. The malicious agent authenticates correctly, participates in reasoning chains, executes tools, accesses data, and terminates its session. No trace remains beyond legitimate-looking audit logs.
3.6 Federated learning privacy collapse
Federated learning was designed to enable multi-party model training without centralizing data. Its privacy guarantees depend on cryptographic secure aggregation — which is quantum-vulnerable. When a CRQC exists, the privacy guarantee retroactively collapses. Every party's training contributions become derivable from the aggregated updates the adversary has been recording. Healthcare consortia running federated learning across hospitals. Financial institutions running federated fraud detection. Chip design collaborations. Every one of them is exposed.
4. What enterprises can actually see: the artifact landscape
The PQC posture of an AI stack is not invisible. It is visible in specific enterprise artifacts that most organizations already produce or can produce. Building AI PQC posture intelligence begins with inventorying these artifacts.
4.1 Model registries and MLOps platforms
MLflow, Databricks Model Registry, SageMaker Model Registry, Vertex AI Model Registry, Azure ML, Hugging Face Enterprise, Kubeflow, Metaflow, ClearML, and Neptune all contain model artifact metadata, signature information, deployment history, and lineage records. These platforms are the single richest source of AI cryptographic posture data — they know what models exist, where they came from, how they were signed, and where they run.
4.2 AI Bill of Materials (AIBOM)
CycloneDX has published an AIBOM extension. MITRE and NIST are actively defining AI-specific bill of materials standards. AIBOMs enumerate model components, training data provenance, fine-tuning history, embedded dependencies, and their cryptographic properties. AIBOMs are to AI what SBOMs are to software — the primary artifact for cryptographic transparency at the model level.
4.3 Inference gateway logs
API gateways in front of LLM endpoints — Cloudflare AI Gateway, Kong AI Gateway, Portkey, LiteLLM, Databricks AI Gateway, and IBM watsonx.governance — log every inference call including TLS session details, negotiated cipher suites, certificate metadata, and authentication token types. These logs are the AI equivalent of the network telemetry used for OT and IT PQC inventory.
4.4 AI observability platforms
Arize, WhyLabs, Fiddler, Truera, and IBM watsonx.governance monitor model behavior in production and have visibility into inference pipeline configuration — including the cryptographic surface of the inference stack.
4.5 Prompt guard and DLP telemetry
Enterprise AI security tools — Lakera, Protect AI, Robust Intelligence, HiddenLayer, Cranium, CalypsoAI — log every prompt and response and have visibility into API session cryptographic properties. Where deployed, these tools are second only to model registries as a source of AI PQC posture data.
4.6 Confidential computing attestation logs
Intel Trust Authority, Azure Attestation Service, AWS Nitro Enclaves attestation, and NVIDIA Confidential Compute Manager produce attestation reports that reveal the cryptographic posture of every enclave-hosted AI workload. These are the ground truth for confidential AI cryptographic state.
4.7 Vector database access logs
Pinecone, Weaviate Enterprise, Milvus Cloud, Qdrant Cloud, and ChromaDB Enterprise audit logs reveal TLS versions, cipher suites, and authentication tokens protecting vector stores. As RAG becomes the default enterprise AI deployment pattern, vector database access logs become foundational to AI PQC intelligence.
4.8 AI governance platforms
Credo AI, Holistic AI, Fairly AI, and Fiddler AI Governance track policy compliance across AI deployments and increasingly include cryptographic controls in their governance schemas. As the EU AI Act and NIST AI RMF mature, these platforms will become primary sources of PQC compliance evidence.
4.9 Agent framework telemetry
LangChain, LangGraph, CrewAI, AutoGen, and MCP server implementations produce agent invocation logs that reveal the identity crypto protecting agent-to-agent authentication.
4.10 CI/CD and code signing for model deployment
The pipelines that promote models to production — Jenkins, GitHub Actions, GitLab CI, ArgoCD, Flux — sign artifacts and orchestrate deployments. Their signing keys and TLS configurations are AI PQC posture data.
5. Regulatory and standards trajectory
AI PQC posture is not just a security question. It is becoming a compliance question, and the compliance clock is running faster than the quantum clock.
NIST AI RMF is developing sector-specific PQC guidance for AI systems, with initial drafts expected in late 2026.
EU AI Act high-risk system provisions require cryptographic assurance for provenance, integrity, and access control. PQC readiness is not yet explicitly mandated, but the current classical-crypto stack will not satisfy the assurance requirement once quantum-relevant compute arrives.
FDA premarket review for AI/ML-enabled medical devices increasingly requires demonstration of cryptographic integrity across training data, model artifacts, and inference. PQC readiness discussions are active in the FDA Digital Health Advisory Committee.
ISO/IEC 42001 (AI management systems) references cryptographic controls but is currently algorithm-agnostic; PQC-specific amendments are expected in the 2027–2028 revision cycle.
Financial services regulators — NYDFS Part 500, FFIEC AI guidance, OCC AI/ML risk management — are moving toward explicit cryptographic assurance requirements for high-consequence AI systems.
Sector-specific AI governance is emerging at pace: DoD Responsible AI guidance already references CNSA 2.0. Healthcare provider AI governance frameworks reference NIST PQC standards. Automotive AI standards (ISO/PAS 21448, ISO/SAE 21434) are being extended with AI-specific cryptographic requirements.
The pattern is clear. Every AI regulatory framework that includes cryptographic assurance requirements will eventually reference PQC. The enterprises that treat AI PQC posture as a 2028 problem will face 2028 audits with 2020s-era classical crypto embedded in their AI stack.
6. The migration path
AI PQC migration follows the same phased structure as Cloud, IT, and OT migration — but with AI-specific actions in each phase.
Phase 1 — Discover and protect (2025–2028)
- Inventory model registries and enumerate model signing algorithms
- Generate AIBOMs for all production models using CycloneDX AIBOM extension
- Audit inference gateway TLS configurations for quantum-vulnerable cipher suites
- Establish baseline cryptographic posture for confidential computing attestation
- Enumerate agent identity certificates across multi-agent deployments
- Begin formal PQC roadmap requests to model registry vendors and confidential computing providers
Phase 2 — Hybrid transition (2025–2031)
- Deploy dual-signing for model artifacts (classical + ML-DSA or SLH-DSA signatures)
- Migrate inference API TLS to hybrid PQC cipher suites (X25519MLKEM768)
- Rotate KMS-protected model encryption keys to PQC-capable HSMs
- Migrate agent identity PKI to hybrid classical + ML-DSA certificates
- Deploy PQC-capable attestation on confidential computing workloads as chip vendors ship support
- Update AIBOMs to reflect hybrid cryptographic posture
Phase 3 — Full migration (2031–2035)
- Enforce PQC-only model signing across model registries
- Retire classical TLS from all inference API endpoints
- Complete PQC-only agent identity infrastructure
- Retire classical attestation crypto from confidential AI workloads
- Establish PQC as default for all new AI system deployment
7. What buyers should demand of AI vendors starting now
Enterprises deploying AI systems today should include the following in their vendor procurement requirements:
- Vendor commitment to PQC-capable model signing on a defined roadmap
- Cryptographic Bill of Materials (CBOM) for all AI infrastructure components
- Hybrid classical + PQC support for inference API TLS by end of 2027
- PQC attestation roadmap for confidential computing offerings
- Certificate authority migration commitment for agent identity infrastructure
- Contractual right to require escrow signing if the vendor cannot deliver PQC on schedule
8. Conclusion
The AI cryptographic stack is real, distinct, and quantum-vulnerable at every layer. Enterprises treating AI as a subset of cloud infrastructure will miss the migration surface entirely. Enterprises treating AI PQC as a future problem will face regulatory and threat exposure simultaneously.
The right posture is to add AI as a fourth environment — alongside Cloud, IT, and OT — in every PQC migration program. To begin inventorying the AI cryptographic artifact landscape now, using the enterprise systems that already exist. To engage AI vendors on PQC roadmaps while procurement leverage still exists. And to demand cryptographic assurance for AI deployments the same way boards, auditors, and regulators demand it for financial systems, safety systems, and healthcare systems.
The harvest of enterprise prompt traffic, model artifact downloads, and agent authentication tokens is already underway. The decryption arrives when a CRQC exists. The window to migrate the AI stack closes on the same timeline as the rest of the enterprise — and it opens on a stack that is currently less mature than any of the others.