Series 2 of 2
A cryptographic inventory can report that an AI agent uses an elliptic-curve certificate. It cannot tell you whether a change to that certificate will stop the agent from reaching a tool. It also cannot identify every token verifier, trust bundle, library, proxy, or external service that must accept the change.
That distinction separates discovery from migration. Series 1 described the cryptographic supply chain that forms around every AI agent. This sequel presents a practical way to connect that supply chain to running workloads and migration decisions.
The design uses four evidence sources. SPIFFE provides a stable workload identity. An AI or machine learning bill of materials describes the AI system. A cryptography bill of materials describes its cryptographic assets. Runtime telemetry shows which trust paths the agent actually uses.
None of these sources can answer the migration question alone. Their correlation can.
Start with a workload identity
Application names make weak correlation keys. The same agent can run in several clusters, accounts, or regions. A service name can change between deployment systems. A shared service account can also represent several unrelated workloads.
SPIFFE gives a workload a URI-form identity such as spiffe://example.test/ai/procurement-agent. A SPIFFE implementation can issue that identity as an X.509-SVID or JWT-SVID. The workload receives its credentials and trust information through the SPIFFE Workload API.
An X.509-SVID places one SPIFFE ID in the certificate URI subject alternative name. A workload can use that certificate for mutual TLS. A JWT-SVID places the SPIFFE ID in the sub claim and requires an audience and expiration time. Trust bundles let other workloads validate identities from the relevant trust domain.
This model removes the need to place a long-lived identity secret inside the workload. It also creates an identity anchor that inventory systems can share. The anchor can connect a running process to its deployment, certificates, tokens, libraries, network peers, owners, and BOM records.
SPIFFE does not provide a complete authorization system. It proves workload identity. Policy systems must still decide which resources that identity can access.
Follow one delegated agent request
Consider a procurement agent that reviews supplier data. An employee signs in through an identity provider and asks the agent to assess a supplier. The agent calls an MCP server, and the MCP server queries an external enterprise resource planning API.
The human and the workloads need separate identities. The human authorizes the task. The agent performs the task. The MCP server performs a narrower action for the agent. The external API must know which subject authorized the request and which workloads participated.
OAuth 2.0 Token Exchange defines subject and actor tokens for this type of delegation. An authorization server can issue a composite token that retains the user as the subject and records the acting workload in the act claim. A deployment can use a JWT-SVID as evidence of the actor identity when the authorization server trusts that SPIFFE identity. That integration remains a deployment decision because RFC 8693 does not prescribe one trust model.
The agent can also use its X.509-SVID for mutual TLS with the MCP server. The MCP server validates the certificate against the correct trust bundle and applies policy to the SPIFFE ID. It then uses its own identity for the next hop.
Interactive example using synthetic data
Follow one delegated agent request
- Path
- Protocol
- Evidence
- Cryptography
- Observed
Text view of the complete flow
- 1. Human sign-in. OIDC over TLS 1.3. User identity and authorization context. ECDSA P-256 server certificate.
- 2. Delegated task. OAuth access token over TLS 1.3. User remains the subject. ES256 token signature.
- 3. Agent identity. SPIFFE Workload API. Agent receives an X.509-SVID and trust bundle. ECDSA P-256 SVID signature.
- 4. Token exchange. OAuth 2.0 Token Exchange. Subject is the user and actor is the agent. JWT-SVID with ES256 signature.
- 5. Tool request. MCP over HTTPS and mutual TLS. Agent SPIFFE ID and delegated user scope. TLS 1.3 with X25519 and ECDSA P-256.
- 6. MCP identity. SPIFFE Workload API. MCP server receives its own X.509-SVID. ECDSA P-256 SVID signature.
- 7. Scope reduction. OAuth 2.0 Token Exchange. Actor chain records the agent and MCP server. JWT access token with ES256 signature.
- 8. ERP query. HTTPS with scoped bearer token. API verifies user, actor chain, audience, and scope. TLS 1.3 and ES256 token verification.
The example shows more than an authentication design. It reveals the cryptographic dependency set. The workflow depends on human sign-in, TLS, mutual TLS, workload certificates, JWT signatures, trust bundles, token exchange, JSON Web Key Sets, cryptographic libraries, and external verification.
Every item can affect PQC migration. The important unit is the complete request path.
Connect composition, cryptography, and runtime evidence
An AI/ML-BOM and a CBOM answer different questions. CycloneDX uses AI/ML-BOM records to describe models, datasets, configurations, and their dependencies. Its CBOM capability describes algorithms, keys, certificates, and relationships to software components.
The BOM records describe what teams built or packaged. They do not prove that a component runs in production. They also do not prove which network path an agent used for a specific task.
Runtime identity and telemetry close part of that gap. OpenTelemetry resource data can identify a service and its instance. Network attributes can record remote addresses, ports, and transport details. TLS observations and platform records can add the negotiated protocol, certificate metadata, and implementation context.
The correlation model should preserve each source instead of merging every field into one ambiguous record.
| Evidence source | Question it answers | Useful correlation field |
|---|---|---|
| Agent inventory | Which agent exists and who owns it? | Agent ID and service owner |
| AI/ML-BOM | Which models, data, frameworks, and software form the system? | BOM reference |
| CBOM | Which algorithms, certificates, keys, and protocols exist? | Cryptographic asset reference |
| SPIFFE | Which workload is running? | SPIFFE ID and trust domain |
| Runtime telemetry | Which peers and trust paths did it use? | Service instance, peer, and observation time |
| Service catalog | Who can approve and execute a change? | Service ID and accountable team |
The following overlay illustrates the joined record. It is not an official SPIFFE or CycloneDX schema.
agent:
id: procurement-agent
serviceId: svc-ai-procurement
owner: procurement-platform
runtime:
spiffeId: spiffe://example.test/ai/procurement-agent
serviceInstance: procurement-agent-7f54c
environment: production
lastObserved: 2026-08-06T16:42:15Z
composition:
aiBomRef: urn:cdx:example/1#procurement-agent
modelRef: urn:cdx:example/1#supplier-risk-model
cryptography:
cbomRef: urn:cdx:example/1#agent-mcp-mtls
x509SvidSignature: ECDSA-P256
tlsKeyEstablishment: X25519
jwtSignature: ES256
trustPath:
peerSpiffeId: spiffe://example.test/mcp/supplier-tools
protocol: MCP-over-HTTPS
authorization: delegated-user-token
migration:
readiness: unknown
blockingOwner: supplier-tools-platformThe common identity makes the record actionable. A certificate observation can now lead to the workload, workflow, peer, library, and owner that depend on it.
Convert the inventory into an impact query
The migration team should be able to select one vulnerable dependency and traverse the graph. A query for ECDSA workload certificates should return the issuing authority, every active SVID, each trust bundle, every certificate verifier, the relevant TLS libraries, and the owners of all affected services.
The query must also preserve uncertainty. A discovered dependency can have an unknown owner. A library can support a target algorithm while an adjacent proxy rejects the new certificate. An external API can remain outside the organization’s migration control.
Interactive example using synthetic data
Test the migration blast radius
- Current dependency
- Owner
- Overall state
- Why it matters
The readiness states should remain simple. Ready means the team has tested the relevant target profile. Blocked means a known dependency cannot accept it. Unknown means the team lacks evidence. External owner means another organization controls the decision.
These states describe migration evidence. They are not generic risk scores.
PQC migration is a compatibility exercise
NIST standardized ML-KEM for key establishment and ML-DSA and SLH-DSA for digital signatures in 2024. Those standards provide the algorithms. They do not make every workload identity, TLS, token, certificate, HSM, KMS, proxy, or application implementation ready for them.
A change to workload certificate signatures can affect the workload CA, certificate profile, Workload API implementation, agent, MCP server, sidecars, trust bundles, and every relying party. A change to JWT signatures can affect token issuers, JSON Web Key Sets, validation libraries, caches, gateways, and external APIs. A change to TLS key establishment can affect both endpoints and every network device that processes the connection.
PQC objects can also be larger than their classical counterparts. Protocol messages, certificate chains, buffers, logs, and hardware interfaces may need different limits. The test plan must therefore validate the complete protocol path instead of checking only an algorithm list.
SPIFFE helps because it gives the team a stable map of workload identities and trust domains. It does not remove the compatibility work. The current issuer, verifier, bundle, library, and protocol profile remain part of the migration scope.
Run a bounded four-week pilot
Start with one business workflow. Choose one agent, one MCP server, and one external API. Avoid a broad enterprise discovery program until the team proves that the correlation model can answer an impact question.
| Week | Work | Required evidence |
|---|---|---|
| 1 | Define the workflow and assign stable workload identities | Named nodes, owners, trust boundaries, and expected paths |
| 2 | Collect AI/ML-BOM, CBOM, certificate, token, and runtime observations | Source, time, environment, and confidence for each observation |
| 3 | Join the records through workload, service, and BOM identifiers | One traversable dependency graph with known gaps |
| 4 | Test one certificate, token, or TLS profile change outside production | Affected participants, blockers, external dependencies, and test results |
The pilot succeeds when the team can answer four questions with evidence. Which workflow uses the dependency? Which components must change together? Who owns each change? What proof supports each readiness state?
The team should also test freshness. A new agent deployment or trust relationship must cause a detectable inventory change within the organization’s defined observation target. Otherwise, the graph becomes another static catalog.
Know what the design cannot prove
Runtime telemetry only records executed paths. It can miss a dormant disaster-recovery flow or a rarely used administrative action. A BOM can also become stale when a model, library, or configuration changes without a new record.
Encrypted traffic limits passive inspection. Privacy and security controls should also prevent the inventory from collecting prompts, payloads, bearer tokens, private keys, or complete credential bodies. The inventory needs metadata and relationships, not sensitive content.
External services create another limit. An organization can identify the dependency and its owner, but it cannot declare that service ready without evidence from the provider. Unknown and external states must remain visible because they determine migration timing.
Make the workflow the migration unit
AI inventory, AI/ML-BOM, CBOM, SPIFFE, and telemetry each solve a defined part of the problem. The operating model connects them without pretending that one source provides complete truth.
Begin with one agent workflow. Give each workload a stable identity. Record the cryptography on every active trust path. Connect that evidence to composition records and owners. Then change one dependency and observe what fails.
If the inventory can predict that result, it can guide migration. If it cannot, the organization still has a list.
References
- SPIFFE, “SPIFFE Workload API,” version 1.15.2, reviewed August 6, 2026.
- SPIFFE, “X.509-SVID,” reviewed August 6, 2026.
- SPIFFE, “JWT-SVID,” reviewed August 6, 2026.
- IETF, “OAuth 2.0 Token Exchange,” RFC 8693, January 2020.
- Model Context Protocol, “Authorization,” specification dated November 25, 2025.
- OWASP CycloneDX, “Machine Learning Bill of Materials,” reviewed August 6, 2026.
- OWASP CycloneDX, “Cryptography Bill of Materials,” reviewed August 6, 2026.
- OpenTelemetry, “Semantic Conventions,” version 1.44.0, reviewed August 6, 2026.
- NIST, “Post-Quantum Cryptography,” reviewed August 6, 2026.
- NIST NCCoE, “Migration to Post-Quantum Cryptography,” reviewed August 6, 2026.