Series 1 of 2
Enterprises can create AI agents faster than their inventory processes can record them. A team may connect a model to internal data and tools within days, then record the result as one application, one service account, or one entry in an AI register. Its security footprint is much larger.
Every agent depends on cryptography to authenticate users and workloads, protect traffic, validate tokens, and connect to tools or data. It may also verify signed software, model artifacts, messages, or responses. Each function creates a dependency that a post-quantum cryptography (PQC) program must eventually address.
This is the blind spot. AI inventories often focus on models, data, purpose, and responsible use. Cryptographic inventories focus on certificates, keys, algorithms, and endpoints. Neither view can support migration until the organization connects both to the business workflows that use them.
An agent is a network of trust relationships
An AI agent rarely acts alone. It may receive authority from a human identity, authenticate through an identity provider, and call a model through an API gateway. The same workflow may use a tool server, database, message service, or another agent. Every connection introduces a trust decision.
Current protocols make this dependency visible. The Model Context Protocol defines OAuth-based authorization for protected HTTP resources. The Agent2Agent protocol supports TLS, mutual TLS, OAuth, OpenID Connect, API keys, and bearer tokens. SPIFFE can issue X.509 or JWT identities to workloads.
These controls solve real authentication and transport problems. They also place certificates, signing keys, token validators, trust stores, and cryptographic libraries inside the agent workflow. The agent inherits those dependencies even when the AI inventory does not record them.
The trust chain can cross teams and platforms: a human identity grants authority; a machine identity represents the runtime; TLS or mutual TLS protects connections; tokens carry delegated authority; libraries implement cryptography; and hardware security modules (HSMs) or key management services (KMSs) protect keys. External services may verify the agent or its output.
An AI register can show that the agent exists. It rarely shows every certificate issuer, token verifier, library, and external trust relationship. That missing context becomes a migration risk when an algorithm must change.
Quantum risk requires precise language
AI systems do not make every cryptographic control quantum vulnerable. A cryptographically relevant quantum computer would primarily threaten widely used public-key systems such as RSA and elliptic-curve cryptography. Those systems support digital signatures, certificate authentication, and key establishment across many enterprise protocols. No such quantum computer exists today, but migration cannot wait for one to appear.
NIST published three principal post-quantum standards in 2024. ML-KEM supports key establishment. ML-DSA and SLH-DSA support digital signatures. NIST now advises organizations to identify vulnerable algorithms and begin migration planning.
Symmetric encryption and hash functions have a different quantum risk profile. They do not fail in the same way as RSA or elliptic-curve systems. Organizations may need stronger parameters or updated protocol profiles, but they must assess those controls separately. A blanket “quantum vulnerable” label hides the decisions engineers need to make.
Certificates and tokens also require technical context. A certificate can contain an RSA or elliptic-curve public key. A JSON Web Token can use a vulnerable public-key signature, a symmetric message authentication code, or another method. The object name does not reveal its quantum risk.
| Dependency | Inventory context needed | Migration consequence |
|---|---|---|
| TLS or mutual TLS | Key establishment, certificate algorithm, issuer, trust store, implementation | Both sides must support the replacement |
| Access or identity token | Signing method, issuer, validator, audience, lifetime | Every validator must accept the new signature or format |
| Workload certificate | Algorithm, profile, issuing authority, renewal process, verifier | Issuers and relying parties must migrate together |
| Signed artifact | Signature, signing service, verification library, retention period | Older verifiers may reject newly signed artifacts |
| Cryptographic library/key | Product, version, provider, configuration, location, hardware support | The implementation may limit available replacement options |
The public-key threat creates two business risks. An attacker can retain long-lived encrypted traffic and attempt decryption later. A future attacker could also forge vulnerable signatures and impersonate a service, workload, software publisher, or agent. The inventory must preserve both confidentiality and authentication context.
PQC migration follows the workflow, not the asset
A scanner can find an RSA certificate on an AI gateway. That identifies a vulnerable asset, not a safe migration plan. The gateway is only one participant in the trust path.
Suppose the gateway adopts a post-quantum or hybrid certificate profile. The agent client must support the new handshake and format. The service mesh, cryptographic library, issuing authority, trust store, HSM, monitoring tools, and external partners may also require changes.
The migration can fail at any incompatible verifier. A new certificate does not help if the client library rejects its signature. A new token signature does not help if a downstream resource server cannot validate it. An updated signer does not complete the migration when retained artifacts still need an older verifier.
The workflow is therefore the migration unit. Teams must map the initiating identity, service connections, implementations, and relying parties, then coordinate owners, release schedules, vendors, and external dependencies. Some systems will need classical and post-quantum coexistence; others need protocol upgrades before they can accept a new key or signature. The inventory must expose those blockers before production changes begin.
Build one operating picture
Agent counts alone do not measure the problem. One agent running in development, test, and production may use an identity provider, hosted model, tool servers, a data store, and a message service. Each connection can use a different certificate, token, trust store, or library—and each environment can have a different owner.
A migration-ready inventory must connect:
- the agent, its purpose, environments, and accountable owner;
- the human and machine identities that authorize and represent it;
- certificates, keys, tokens, protocols, algorithms, libraries, and key platforms;
- APIs, tools, data sources, gateways, service meshes, partners, and verifiers; and
- migration readiness, including technical, vendor, commercial, and sequencing blockers.
Stable identifiers should connect these records to applications and business services. Each relationship should retain its source, environment, observation time, and confidence. A discovered dependency and an inferred one should not carry the same authority, and known gaps should remain visible.
This is the operational gap: organizations have AI dashboards and cryptographic scanners, but rarely the correlation needed to predict how a cryptographic change will affect an agent workflow. Closing it requires more than reporting. The result must support sequencing, testing, exception management, ownership, and verification before and after deployment.
Leaders can test their position with three questions:
- Can we identify every production agent and its owner?
- Can we trace each agent through identities, cryptographic controls, tools, data, applications, and verifiers?
- Can we predict which workflows will fail when one vulnerable dependency changes?
If the answer to the third question is no, the organization does not yet have a PQC migration plan for its AI estate. It has separate inventories describing parts of the problem. The immediate priority is to connect them before agent adoption expands the dependency graph again.
Series 2 will examine how an AI or ML Bill of Materials can connect with a Cryptography Bill of Materials. It will focus on the data relationships, ownership model, and readiness signals needed for migration. The objective will remain operational impact, not a marketing combination of AI security and PQC.
References
- National Institute of Standards and Technology, “Post-Quantum Cryptography,” reviewed August 3, 2026.
- NIST National Cybersecurity Center of Excellence, “Migration to Post-Quantum Cryptography,” reviewed August 3, 2026.
- CISA, NSA, and NIST, “Quantum-Readiness: Migration to Post-Quantum Cryptography,” August 2023.
- Model Context Protocol, “Authorization,” draft specification reviewed August 3, 2026.
- Agent2Agent Protocol, “Protocol Specification,” development specification reviewed August 3, 2026.
- SPIFFE, “SPIRE Concepts,” reviewed August 3, 2026.
- OWASP CycloneDX, “Machine Learning Bill of Materials,” reviewed August 3, 2026.
Limitations
This is an operating model, not a universal schema or migration score. Protocols, standards, libraries, and vendor support continue to change, so organizations must verify each implementation before production migration.