Executive summary
Enterprises deploying AI at scale are running production systems whose cryptographic foundations they cannot see. Not because the security team is careless. Because the tools that give them visibility into cloud posture, endpoint posture, and network posture were not designed to answer questions about the AI stack.
Five questions define the visibility gap. Every AI-forward enterprise should be able to answer them in real time. Most cannot answer any of them today. This brief defines the five questions, explains why they matter, and describes the operational posture that closes the gap.
Question 1: Which of our production models are signed with quantum-vulnerable algorithms?
Every foundation model, fine-tuned variant, and inference endpoint in production carries a cryptographic signature. That signature is what the deployment pipeline validates before loading the model. If the signature is valid, the model is trusted. If the signature was created with RSA or ECDSA — which almost every model signature is today — then a cryptographically relevant quantum computer will make it forgeable.
Most enterprise security teams cannot produce a list of every model in production with its signature algorithm. They can produce a list of models. They can produce a list of registries. But the mapping from model to signing algorithm to quantum exposure is not something existing tools surface, because existing tools were built to catch malware, not to inventory cryptographic provenance.
The consequence: when a nation-state adversary forges a signature on a poisoned foundation model and pushes it to a public registry, every enterprise pulling from that registry accepts it as legitimate. The poisoning targets specific edge cases — a misdiagnosis on a particular pattern of chest X-rays, an incorrect approval on a particular loan profile, a subtle miscalibration in an industrial control loop. Standard benchmarks do not catch it. Production monitoring does not catch it. Only the adversary knows when to invoke the poisoned behavior.
The team that can answer Question 1 in real time can migrate the model signing pipeline before that scenario becomes executable. The team that cannot is exposed.
Question 2: How many of our enterprise prompts have been captured on classical TLS sessions?
Every prompt sent to an enterprise LLM API travels over a TLS session. The session key is derived from a classical key exchange — RSA or ECDHE. Nation-state adversaries with tap points on the internet backbone are capturing these sessions today and storing them. When a CRQC arrives, the private keys become derivable and the stored sessions become readable.
The average enterprise has sent thousands to millions of prompts to LLM APIs over the past two years. Those prompts contain legal strategy, patient records, source code, engineering designs, financial analysis, M&A modeling, and classified reasoning. Every one of them is a Harvest Now, Decrypt Later target that has already been harvested.
The security team is expected to know how much data has been sent to which LLM APIs over which sessions using which cipher suites. That data exists — it is in inference gateway logs, in cloud API telemetry, in enterprise firewall records. But it is not aggregated into a single answer. No dashboard in most enterprises produces the number: "the number of enterprise prompts currently at risk of retroactive decryption."
That number is not zero. The team that can produce it can begin protecting future traffic today. The team that cannot has no baseline for how bad the exposure will get before it is contained.
Question 3: Which of our confidential AI workloads depend on quantum-vulnerable attestation?
Confidential computing is the fastest-growing security architecture for enterprise AI. Intel SGX, AMD SEV-SNP, and NVIDIA H100 confidential compute enclaves promise that models run in verified enclaves where neither the cloud provider nor the adversary can extract the data. That promise depends entirely on remote attestation — a cryptographic proof that the enclave is genuine and running the expected code.
Every remote attestation certificate today is RSA or ECDSA-signed. When a CRQC arrives, the attestation can be forged. The adversary presents a "verified" enclave that is not verified at all. The confidentiality guarantee evaporates.
Most enterprises building confidential AI cannot list which workloads depend on which attestation service and which cryptographic algorithm. Attestation is an infrastructure primitive that "just works" until it doesn't. When it doesn't, the entire confidential AI investment thesis is defeated.
The team that can answer Question 3 can prioritize migration of the highest-risk confidential workloads, request PQC attestation roadmaps from chip and CSP vendors, and put compensating controls in place for workloads whose attestation cannot yet be migrated. The team that cannot is trusting cryptography that has a defined shelf life.
Question 4: In our multi-agent architectures, which agent identities can be forged?
Enterprise AI is moving fast toward multi-agent architectures. LangGraph, CrewAI, AutoGen, MCP-based agent networks, Agentforce, Microsoft Copilot Studio — every major AI platform is building agent-to-agent workflows where one agent authenticates to another, executes actions, accesses data, and returns results. That authentication is a certificate-based operation, and the certificates are classical crypto.
When a CRQC exists, agent identity certificates become forgeable. An adversary inserts a malicious agent into a legitimate workflow. It authenticates correctly. It participates in reasoning chains. It executes tools. It accesses data. It terminates its session. No trace remains beyond audit logs that look completely legitimate — because they are cryptographically legitimate.
The security team is expected to know how many agent identities exist in the enterprise, which are internal versus vendor-supplied, which certificate authority issued each one, and what algorithm secures each one. That inventory is not something most enterprises have built. Agent frameworks are recent. Governance frameworks for agents are still emerging.
The team that can answer Question 4 can begin migrating agent identity PKI on the same timeline as the rest of the enterprise. The team that cannot has a permanent invisible back door growing at the rate their agent architecture grows.
Question 5: When our board asks for a single number describing our AI cryptographic risk, what do we say?
Every other AI risk category has a governance answer. Model bias has metrics. Hallucination has evaluation frameworks. Data privacy has DLP controls. Prompt injection has guardrails. Every one of these can be reported to a board or a regulator with a defensible number.
Cryptographic posture of the AI stack has no such number in most enterprises today. There is no metric that answers "what percentage of our AI cryptographic surface is PQC-ready, and what is our target date for the remainder." There is no unified report that spans model provenance, inference session integrity, attestation, agent identity, RAG authentication, and governance controls.
The consequence: when a board or regulator or Authorizing Official asks the question, the answer is a promise to look into it. That answer will not survive the next audit cycle in any regulated sector. NIST AI RMF is developing PQC guidance. EU AI Act high-risk system provisions are moving toward cryptographic assurance requirements. FDA premarket review for AI medical devices is heading in the same direction. Financial services regulators are following the same path.
The team that can answer Question 5 with a single defensible number can walk into any board meeting, any audit, any regulator conversation and demonstrate current posture, current trajectory, and current gap closure timeline. The team that cannot will spend the next three years explaining why they were surprised.
What closes the gap
The visibility gap defined by these five questions closes when three capabilities are in place simultaneously.
First, continuous ingestion of cryptographic posture data from every AI infrastructure component in the enterprise — model registries, inference gateways, confidential compute attestation services, agent identity systems, RAG pipelines, AI governance platforms, and the vulnerability scanners, PKI lifecycle tools, and OT visibility platforms the enterprise has already invested in for the rest of its stack.
Second, reconciliation of that data into a single unified inventory that answers each of the five questions with a live, current, defensible number — not a quarterly snapshot, not a manually-updated spreadsheet, not four separate dashboards from four separate teams.
Third, a prioritized migration backlog that translates the current posture into forward-moving work: what to migrate first, what to migrate next, what to accept as compensating-control risk in the interim, and what the projected completion date is based on current data.
Enterprises that build this capability now — while procurement leverage still exists with AI vendors, while regulatory frameworks are still emerging, while the CRQC timeline still allows a graceful migration — will be able to answer their board's simplest question. Enterprises that wait will face the question and the CRQC arrival at approximately the same time.
The AI cryptographic surface is real. It is quantum-vulnerable. It is being harvested. And the tools to see it — to answer these five questions in real time — exist today.