Two supply chain transparency programmes are running in parallel right now, and neither one sees the other.

On one track: the Cryptography Bill of Materials, or CBOM. Standardised in CycloneDX v1.6, expanded in v1.7, and made a federal requirement in the US by executive order in June 2026. A CBOM inventories every cryptographic asset in a system: algorithms, keys, certificates, protocols, libraries. It exists because you cannot migrate to post-quantum cryptography if you don’t know where your current cryptography lives.

On the other track: the SBOM for AI, sometimes called AIBOM. The G7 Cybersecurity Working Group published minimum elements in May 2026, built around seven clusters: metadata, models, dataset properties, system-level properties, KPIs, security properties, and infrastructure. CISA updated its SBOM minimum elements in July 2026 to explicitly call out AI as requiring additional elements. OWASP ships an open-source AIBOM generator. The EU Cyber Resilience Act and the EU AI Act both push toward this. An AIBOM inventories the models, training data, frameworks, and dependencies that make up an AI system.

Both programmes are necessary. Both are gaining regulatory traction. Both are producing real tooling. And both are blind to the same thing: the cryptographic assets that AI agents carry.

That blind spot is the subject of this post.

What CBOM sees

CBOM tooling scans for cryptographic assets in software. It looks inside binaries, libraries, container images, firmware, and network traffic. It finds the RSA key in your TLS certificate, the AES-GCM in your VPN configuration, the SHA-256 in your code signing pipeline, the ECDH in your key agreement protocol. It records the algorithm, the key length, the location, the library that implements it, and the quantum-vulnerability status.

This is well-understood work. The CycloneDX CBOM spec defines a cryptographic-asset component type with structured fields for algorithm family, key material, certificate state, and dependency relationships. Tools like IBM’s CBOMit, the Post-Quantum Cryptography Alliance’s CBOMkit, and Entrust’s Cryptographic Security Platform can discover and report cryptographic assets across an enterprise estate. FedTech Magazine reported in September 2026 that CBOMs are now a foundational federal requirement, with CISA and NIST tasked with defining minimum elements.

What CBOM finds is cryptography in software. What it misses is cryptography in agents.

What AIBOM sees

AIBOM tooling scans for AI system components. It reads model cards, config files, and training pipeline metadata. It records the model name, version, hash, architecture, training data provenance, fine-tuning lineage, framework dependencies, and licence. The CycloneDX ML-BOM guide, published in June 2026, defines a machine-learning-model component type with a PURL identifier (e.g., pkg:huggingface/org/model@commit), model card metadata, and a pedigree graph tracing fine-tuning ancestors.

The G7 framework’s seven clusters cover the AI system comprehensively at the model and dataset level. The Models cluster captures identity, lineage, and properties. The Dataset Properties cluster captures provenance and sensitivity. The Security Properties cluster captures security controls and vulnerability references. The Infrastructure cluster captures the software and hardware the system runs on.

What AIBOM finds is the AI supply chain. What it misses is the cryptographic layer that AI agents use to authenticate, authorise, and prove what they did.

The gap

Here is what falls between the two inventories.

An AI agent that signs capability receipts holds an Ed25519 private key. That key is a cryptographic asset. It should be in a CBOM. But CBOM discovery tooling scans binaries and network traffic, not agent identity stores. The key lives in a file on the agent’s host, or in an HSM, or in a secrets manager. It is not embedded in a library or negotiated in a TLS handshake. CBOM scanners walk right past it.

That same agent appears in an AIBOM as part of the system-level properties cluster. The AIBOM records the model, the framework, the inference runtime. But it does not record the agent’s signing key, its key rotation history, its quantum-vulnerability status, or the certificate chain that anchors its identity. Those are cryptographic assets, and the AIBOM spec doesn’t inventory cryptographic assets. That’s CBOM’s job.

So the agent’s cryptographic identity sits in a gap between the two inventories. Neither one captures it. And the gap is not small.

Consider what a production AI agent deployment now involves cryptographically:

• Agent identity keys. Every emerging agent identity system uses Ed25519. Microsoft’s Agent Governance Toolkit chose Ed25519 in its architecture decision record. The Clawdentity protocol, an IETF draft, mandates Ed25519 as the sole signing algorithm. The Agent Passport System, another IETF draft, uses Ed25519 for agent passports. My own project, raucle, uses Ed25519 for capability tokens, provenance receipts, and trust registry signatures. These are real keys doing real cryptographic work in production, and none of them show up in a CBOM unless someone manually adds them.

• Capability tokens. A signed token binding an agent identity, a tool, a constraint set, and an expiry is a cryptographic artefact. The signing key is a cryptographic asset. The token verification key is a cryptographic asset. The trust registry that publishes those keys is a cryptographic infrastructure. CBOM doesn’t see any of it because the keys aren’t in libraries or TLS configs.

• Provenance receipts and audit chains. Hash-chained, Ed25519-signed audit logs are cryptographic artefacts. The signing key for the checkpoint is a cryptographic asset. The chain itself depends on Ed25519 for tamper-evidence. If that key is quantum-vulnerable, every receipt it signed is potentially forgeable in the future. That’s a CBOM concern. But the audit chain is generated by the agent framework, not by a cryptographic library that CBOM tooling knows how to scan.

• Cross-organisation trust registries. An append-only, hash-chained, operator-signed directory of issuer keys is a cryptographic infrastructure. The operator key is a cryptographic asset. Each published issuer key is a cryptographic asset. Revocation is a cryptographic operation. None of this appears in standard CBOM discovery because it lives in application-layer protocols, not in system-level cryptographic libraries.

• Model-serving infrastructure. The TLS certificates on your inference endpoints, the API gateway credentials your agent presents, the mutual TLS between your agent and your model server. These are closer to what CBOM tooling does find, but the agent-side credentials are often managed by the agent framework’s own identity system, not by the infrastructure’s certificate management. The CBOM sees the server certificate. It doesn’t see the agent’s client certificate.

Why this matters for post-quantum migration

Ed25519 is an elliptic-curve signature scheme. It is quantum-vulnerable. Shor’s algorithm breaks it.

This is not a theoretical concern. The entire post-quantum migration programme is built on the premise that quantum-vulnerable cryptography must be found before it can be replaced. The US executive order, NIST’s PQC standardisation work, NSA’s CNSA 2.0 timeline, and the EU’s DORA and NIS2 regulations all assume you have an inventory of your cryptographic assets. That inventory is the CBOM.

If your agent identity keys are not in the CBOM, they will not be in the migration plan. They will sit there, quantum-vulnerable, while everything around them gets upgraded. And because agent signing keys are long-lived identity keys, not session keys, the harvest-now-decrypt-later threat applies differently than it does to TLS. A harvested TLS session key exposes one session. A harvested agent identity key exposes every receipt, every token, and every audit entry that key ever signed. The blast radius is the entire accountability history of that agent.

The post-quantum research community has started to notice this. A March 2026 paper from PwC, “Quantum-Secure-By-Construction,” argued that agentic AI systems need post-quantum cryptographic design at the protocol level, not just at the transport level. But the operational translation of that argument, the part where someone has to find every agent signing key in the estate and plan its migration, has not been written. That work starts with the inventory. And the inventory has a gap.

What the G7 framework missed

The G7 SBOM for AI framework is a strong document. It was co-authored by the cybersecurity agencies of all G7 nations plus the EU Commission, and it represents genuine expert consensus. The seven clusters cover the right territory for AI supply chain transparency.

But the framework explicitly considered adding an element for “the level of decision making or autonomy of an AI system” and decided not to include it. The reasoning was that autonomy “may be addressed differently across different jurisdictions, including through safety requirements.” That is a reasonable policy call. It is also a missed security call.

Autonomous agents are where the cryptographic exposure is concentrated. A chatbot doesn’t need a signing key. An agent that calls tools, signs receipts, presents credentials, and participates in cross-organisation handshakes needs several. The more autonomous the agent, the more cryptographic assets it carries, and the more important it is that those assets are inventoried, tracked, and included in the post-quantum migration plan.

The Security Properties cluster in the G7 framework covers “security controls, security compliance, cybersecurity policy information, and vulnerability referencing.” That is the right home for agent cryptographic asset information. But the minimum elements don’t name agent identity keys, capability tokens, or provenance signatures as specific elements. They fall under the general category of security properties, which means they will be included if someone knows to include them, and omitted if nobody does.

What should happen

CycloneDX technically already supports this. A single CycloneDX document can contain both cryptographic-asset components and machine-learning-model components. The spec’s cross-BOM reference mechanism, BOM-Link, lets one BOM reference components in another BOM by serial number and version. So an AIBOM could reference a CBOM that contains the agent’s signing keys, or a unified BOM could contain both in the same document.

The architecture is ready. The tooling is not.

CBOM discovery tools need to learn how to scan agent identity stores, secrets managers, and agent framework configuration for cryptographic material. That is a different scanning problem from binary analysis or network traffic inspection. It requires understanding agent framework internals: where LangChain stores its callback credentials, where the Microsoft Agent Framework keeps its middleware keys, where raucle’s trust registry publishes its operator key, where an MCP server stores its authentication tokens.

AIBOM generators need to emit cryptographic-asset components alongside model components. When the AIBOM records that a system includes an agent with a raucle capability gate, it should also record the Ed25519 key pair that gate uses, the trust registry it resolves against, and the quantum-vulnerability status of the signing algorithm. That information belongs in the same BOM, cross-referenced to the model component it protects.

And the G7 framework, in its next revision, should name agent cryptographic assets as a specific element under the Security Properties cluster. Not as a future consideration. As a current requirement. The agents are already in production. Their keys are already in use. The inventory gap is not a future problem.

The practical version

If you are running AI agents in production today and you have a CBOM programme, a AIBOM programme, or both, here is what I would check:

Pull the list of cryptographic assets your CBOM tooling has discovered. Search it for any key that is associated with an agent identity, a capability token, a provenance receipt, or a trust registry. If none appear, you have the gap. Your CBOM knows about the TLS on your inference endpoint. It does not know about the Ed25519 key your agent uses to sign every action it takes.

Pull your AIBOM, if you have one. Look at the Security Properties cluster. Check whether it includes any cryptographic-asset entries for the agent’s signing keys, token verification keys, or audit chain checkpoints. If it doesn’t, your AIBOM knows what model is running but not what cryptography the agent uses to prove what it did.

Then do the cross-reference exercise. For each agent in production, list the cryptographic assets it carries: identity keys, token signing keys, receipt signing keys, trust registry keys, client certificates, API credentials. For each asset, check whether it appears in the CBOM, the AIBOM, or neither. The ones in neither are your blind spot. And every one of them is quantum-vulnerable if it uses Ed25519, ECDSA, or any other elliptic-curve scheme.

This is not a hypothetical exercise. The post-quantum migration deadlines are already set. The CBOM is the map for that migration. If the map doesn’t show the agent keys, the migration plan won’t either. And the keys that get missed are the ones that hurt the most, because they are the keys that prove what your agents did. Lose those to a quantum adversary, and you lose the audit trail. Not the logs. The proof.

The CycloneDX specification (ECMA-424) supports both cryptographic-asset and machine-learning-model component types in a single BOM document. The G7 SBOM for AI minimum elements were published in May 2026 by CISA, BSI, ACN, ANSSI, CSE, NCSC, and NCO. The US executive order on quantum cryptography was signed in June 2026. CISA’s 2026 SBOM minimum elements update explicitly names AI as requiring additional elements beyond the baseline.