It is 06:42 ET on a Tuesday in Q2 2026 and the Acme CAIO is reading the same alert thirty other Fortune-1000 AI leaders are reading: a major foundation-model provider has disclosed a supply-chain breach. A poisoned dependency injected during the provider's training-data ingestion pipeline tainted a behavioral fine-tune released six weeks earlier; downstream deployers are advised to verify their build-time attestations and roll forward to the patched model card by end of week. The Acme CAIO walks into the 07:00 stand-up and asks the question that decides whether the next thirty days are a controlled patch cycle or a board-level event: "show me our ML-BoM verification log for every deployed system that runs on this provider, and the CDXA signatures attached to each build." The CTO clears his throat. The platform lead opens a Confluence page. The answer is the answer none of them want to give: "we publish ML-BoMs, but we don't have a verification log, and the CDXA signing is still a Q3 roadmap item." The Acme AI Officer logs the gap. The General Counsel logs it twice. This lesson is the L4 capstone, the AI supply-chain attestation architecture that converts ML-BoM publication into a closed verification loop: nine ML-BoM component classes, the CycloneDX 1.7 schema, the CDXA attestation envelope, the 8-layer attestation chain from foundation-model provider down to deployed inference, Sigstore + DSSE + in-toto + SLSA-AI signing infrastructure, deployer-side verification tied to Article 26(5) and Article 43(4), Annex XII downstream-deployer integration, the four maturity tiers procurement screens against in 2026, the seven recurring 2026 failure modes, and the worked Acme.ServiceAssist v1.0 example that achieved SLSA Level 3 with Schellman pre-attestation by Q2 2026. This lesson closes Level 4: the AI Governance Lead's supplier-trust architecture, where vendor due diligence (lessons 070-071), Article 25(2) cooperation (lessons 026, 077), Annex XII downstream-deployer information (multiple), and supply-chain attestation (this lesson) compose into one coherent regulator-grade evidence chain.

Why AI Supply-Chain Attestation Became Unavoidable in 2026

The 2024-2025 SBOM debate was about software dependencies. The 2026 ML-BoM + CDXA debate is about something different: every 2026 enterprise AI system is a supply chain of supply chains, and each layer is independently signable, independently attestable, and, without attestation, independently exploitable. The Acme.ServiceAssist v1.0 system is the canonical example: a foundation-model provider (Anthropic, OpenAI, Meta, Google) supplies the base model under one supply chain; a fine-tune training-data corpus is curated under a second; a fine-tune training run is executed under a third; a RAG corpus is ingested under a fourth; an embedding model is served under a fifth; an eval suite (Promptfoo, Garak, PyRIT, Inspect) is built under a sixth; an inference runtime is shipped under a seventh; a telemetry pipeline runs under an eighth. Each of the eight layers can be poisoned, signed by the wrong party, version-floated, or silently substituted. The OWASP LLM Top-10 (2025 update) lists LLM03 Supply Chain as a top-tier risk explicitly because the attack surface is multiplicative across these layers, not additive across a flat dependency graph.

Three force vectors converged on attestation in 2026. First, lessons from outside the AI stack. The SolarWinds compromise (2020) demonstrated build-system injection. The XZ Utils backdoor (March 2024, CVE-2024-3094) demonstrated multi-year social-engineering supply-chain compromise. The CISA Secure-by-Design pledge (2024 + 2026 updates), ENISA's AI threat-landscape 2026 report, and NIST Secure Software Development Framework (SSDF, SP 800-218 + the SP 800-218A AI generative companion) all push the same conclusion: publishing inventory is not enough; the inventory must be signed by a verifiable party, the verification must be machine-checkable at deployment, and the verification must be re-checked at every substantial-modification event. The pattern that worked for software in 2024-2025, Sigstore + cosign + Rekor for container images, generalizes directly to AI artifacts.

Second, EU AI Act provisions made attestation a regulator-enforceable requirement. Article 15 requires high-risk system providers to design and develop systems achieving an appropriate level of accuracy, robustness, and cybersecurity throughout their lifecycle, including measures protecting against attempts by unauthorized third parties to alter model behavior by exploiting system vulnerabilities. Article 25(2) requires foundation-model providers and downstream system providers to cooperate, exchanging documentation and technical access necessary for downstream conformity. Article 26(5) requires deployers to monitor the operation of deployed high-risk systems and notify the provider where they have reason to consider use to involve risk per Article 79(1). Article 43(4) requires re-conformity assessment for substantial modifications. Annex XII obliges downstream-deployer information packages, increasingly including the ML-BoM and CDXA-signed attestation set as the structured content. Article 99(3) penalty exposure of €15M or 3% of global turnover applies to Articles 10, 15, and 26 supply-chain control failures; reputational and procurement-loss damage in 2026 typically exceeds the statutory penalty by an order of magnitude.

Third, the procurement market made attestation a revenue gate. By Q1 2026 tier-A enterprise procurement (Fortune 1000, healthcare systems, financial-services firms, U.S. federal contractors, EU regulated sectors) requires vendors to ship a ML-BoM at minimum and a CDXA-signed attestation set as a contractual condition. The procurement-tier matrix introduced in lesson 070 hardened in Q1 2026 into a four-tier maturity ladder (defined later in this lesson) where vendors at the lowest tier, no ML-BoM published, are red-flagged at procurement intake and disqualified from tier-A deal flow. The economic incentive for attestation maturity is no longer marginal; it is determinative.

The Nine-Component ML-BoM - CycloneDX 1.7 ML Extensions in Practice

CycloneDX 1.7 (OWASP Foundation; released March 25, 2026) formalized the ML/AI Bill of Materials extensions and the CDXA attestations layer. The ML extension model recognizes nine distinct component classes that an L4 governance leader must catalog completely for any deployed AI system. A 2026 ML-BoM that lists only the foundation model, the single most common failure mode (see lesson 070), is a procurement red flag and an Article 26(5) monitoring gap. The nine classes:

1. Base model. The foundation model itself: Anthropic Claude 4 Opus, OpenAI GPT-5, Meta Llama 4, Google Gemini 2, Mistral Large 2, etc.: pinned by provider, model identifier, API version (where API-served) or weight-set SHA-256 (where weights-shipped), supplier organization, license terms, and reference to the provider's Annex XI model documentation. For API-served foundation models, the BoM line carries the API response-signature digest as the integrity anchor; for weights-shipped, the SHA-256 of the canonical safetensors or GGUF artifact.
2. Fine-tune dataset(s). Every dataset used in any fine-tune, post-training, or alignment pass: with provenance attestation (lawful basis under Article 10), license terms, opt-out compliance per Article 53(1)(d) (the TDM-opt-out training-data summary), Article 53(2) compliance for GPAI providers, datasheet-for-datasets reference (lesson 028), and SHA-256 of the canonical dataset snapshot. For human-feedback datasets (RLHF, DPO, RLAIF), the annotation-protocol reference plus annotator-pool documentation enter the BoM.
3. Embedding model. The model used for RAG retrieval embedding (OpenAI text-embedding-3-large, Cohere embed-v3, Voyage 2, Anthropic embeddings, or in-house), pinned by API version or weight hash. Embedding-space changes alter retrieval recall and downstream eval baselines; the BoM line is what catches the change.
4. Retrieval corpus snapshot. The RAG knowledge-base contents at the snapshot point: pinned by article-set hash, snapshot date, ingestion-pipeline identifier, and provenance/license metadata for the source documents. Reindexing produces a new digest and a new BoM line. The retrieval corpus is the single largest attack surface for prompt-injection and data-poisoning in deployed RAG systems, and the most commonly omitted ML-BoM component in early-2026 audits.
5. Tools / function library. Every tool the agent can invoke, function-calling schemas, MCP servers, API connectors, code-execution sandboxes, with tool identifier, version, declared permissions (read-only, write, network-egress, sensitive-data scope), input/output schemas, and the security-posture reference. The autonomy-tier matrix (lesson 074) cross-references the tools entry.
6. Memory layer + retention policy. Where the agent maintains conversational memory, long-term user memory, or organizational memory: the storage backend, retention-policy identifier, deletion-workflow reference, and the privacy-classification of stored content. For agentic systems the memory layer is a substantial-modification trigger when the retention policy or scope changes.
7. Judge models + eval suites. The judge models used in LLM-as-judge eval patterns (often a separate API call to a frontier model) plus the eval-suite versions (Promptfoo, Garak, PyRIT, Inspect, OpenAI Evals) and the probe-pack hashes. Floating eval-suite versions create a false-security posture: the same artifact may pass yesterday's probe set and fail tomorrow's, or vice versa, with no BoM signal.
8. Inference runtime + serving stack. The serving framework (vLLM, TGI, TensorRT-LLM, SGLang, Triton), the model-server container image (with SBOM via SBOM-AI extension), the orchestration runtime (LangGraph, LlamaIndex, custom), the API gateway, and the network-policy reference. Inference-runtime memory-safety vulnerabilities (the vLLM CVE class throughout 2025-2026) are an attack vector that an ML-BoM without a runtime entry cannot surface.
9. Telemetry pipeline + monitoring agents. The observability stack: log collectors, eval-replay infrastructure, drift-monitoring agents, the retention horizon for inference logs, and the access-control policy on the telemetry corpus. Telemetry-pipeline integrity is itself an attestation requirement because the post-market monitoring evidence Article 72 obliges depends on telemetry the deployer trusts.

The complete 9-component ML-BoM for a non-trivial 2026 RAG-agent system is typically 6,000 to 18,000 lines of CycloneDX 1.7 JSON, generated in CI/CD, signed via CDXA on every build, and diffed against the previous build before promotion. The SBOM-AI extension (CycloneDX 1.7 nomenclature for SBOM with AI-component overlays) and the parallel SPDX 3.0 AI profile both serialize to the same component model; CycloneDX 1.7 ships the integrated multi-type artifact natively (ML-BoM + SBOM + SaaSBOM + VEX in one signed envelope, per lesson 029), which is why it won the format race for AI supply chains by mid-2026.

CDXA, Sigstore, SLSA-AI, and the 8-Layer Attestation Chain

Publishing an ML-BoM is necessary; signing it correctly is what makes it evidence. The CDXA (CycloneDX Attestations) specification, the cryptographic attestation layer added in CycloneDX 1.7, binds typed claims to ML-BoM components: build provenance ("this artifact was built from commit X on CI runner Y at time Z"); component identity ("this component reference resolves to hash H"); evaluation ("this artifact passed probe-pack P at pass-rate R on date D"); policy compliance ("this artifact cleared governance gate G under policy version V"). CDXA statements use the in-toto attestation framework's predicate model, the same predicate format underlying SLSA, and are typically packaged in DSSE (Dead Simple Signing Envelope) wrappers that bind the predicate to a signature without parsing-attack ambiguity.

Signing infrastructure in the 2026 default stack. Sigstore (cosign for container and ML-BoM signing; Fulcio as the certificate authority; Rekor as the public transparency log) is the OSS-default chain of trust, with keyless signing tied to OIDC tokens from the CI provider. KMS-backed alternatives (AWS KMS, Google Cloud KMS, Azure Key Vault) are the enterprise-default with role-scoped signing permissions for the CI runner. The SLSA framework (Supply-chain Levels for Software Artifacts; v1.0 stable; SLSA v1.1 in draft 2026) defines four maturity levels measuring build-provenance rigor: Level 1 (provenance exists and is auto-generated), Level 2 (provenance is signed and tamper-resistant), Level 3 (build platform is hardened, source and build are version-controlled), Level 4 (two-party review, hermetic and reproducible builds). The SLSA-AI working group, active since 2025, is extending SLSA to model artifacts: covering training-data integrity, training-run reproducibility, weight-artifact signing, and model-card attestation provenance. By Q2 2026 SLSA Level 3 for the build pipeline and SLSA-AI draft compliance for the model artifacts is the procurement-tier-A expectation.

The 8-layer attestation chain is the operational frame that converts these building blocks into the closed verification loop the Acme CAIO didn't have. Each layer signs the artifact it produces and the attestation of the layer below; the deployer verifies the full chain at deployment time and at every substantial-modification trigger.

1. Layer 1 - Foundation-model provider attestation. The upstream provider (Anthropic, OpenAI, Meta, Google, Mistral, etc.) publishes a signed attestation of the model build: weight hash (for weights-shipped) or API-version anchor (for API-served), training-data summary per Article 53(1)(d), eval-suite results, safety-mitigation documentation, and the provider's signing key bound to a known organizational identity. Anthropic, OpenAI, and Google have been progressively publishing this attestation set through 2025-2026; the maturity of the upstream attestation determines the maximum maturity achievable downstream.
2. Layer 2 - Fine-tune training-data attestation. The downstream provider attests to the provenance, license, and Article 10 quality-management compliance of every dataset entering the fine-tune. Each dataset is hash-pinned, the lawful-basis reference is signed, the opt-out compliance per Article 53 is asserted, and the datasheet-for-datasets reference is bound. For human-feedback datasets, the annotation protocol and annotator-pool documentation are part of the attestation.
3. Layer 3 - Fine-tune training-run attestation. The training-execution environment is attested: compute provider, hardware fingerprint (where confidential-compute attestation is available), container-image SHA-256, training-framework version, hyperparameter set hash, random-seed pinning, and the SHA-256 of the resulting weights. Reproducibility, the SLSA Level 4 requirement extended to AI artifacts, is the long-horizon target; bit-exact reproducibility for large training runs remains experimental in 2026 but the attestation contract holds even where bit-exactness does not.
4. Layer 4 - Eval-suite attestation. The eval pipeline is itself attested: Promptfoo / Garak / PyRIT / Inspect / OpenAI Evals versions are pinned, the probe-pack content hash is asserted, the eval inputs and outputs are recorded, the pass-rate is signed, and the eval thresholds are bound to the policy reference that authored them. The evaluation-attestation layer is where the LLM03 Supply Chain risk meets the LLM09 Misinformation risk: an artifact that passes a stale or floated probe pack creates false security.
5. Layer 5 - Deployment-pipeline attestation. The deployment artifact (container image, model-server bundle, orchestration code) is built under a SLSA-conformant pipeline: signed build provenance via cosign keyless or KMS-backed signing, source-and-build version control, hardened build platform, no human commit between build and deployment without two-party review. The deployment attestation binds the deployed bits to the trained weights and the eval pass-rate.
6. Layer 6 - RAG corpus attestation. The retrieval corpus snapshot is attested at ingestion: every source document is provenance-tracked, the ingestion pipeline integrity is signed, the snapshot hash binds the article set, and the curation-policy reference (KB editorial governance) is bound. This is the layer most commonly omitted in 2026, and the layer most consequential to attack-surface management because prompt-injection attacks against indexed content are the dominant exfiltration vector for RAG-agent systems.
7. Layer 7 - Inference-runtime attestation. The serving stack (vLLM, TGI, TensorRT-LLM, SGLang, Triton) is built and signed under SBOM-AI; the model-server container image is signed; the runtime security posture (memory-isolation policy, network-egress policy, sandbox boundary) is attested; CVE applicability is recorded via VEX. Memory-safety CVEs in serving frameworks have been a recurrent attack vector throughout 2025-2026; the inference-runtime attestation is what makes the patching status verifiable to the deployer.
8. Layer 8 - Observability attestation. The telemetry pipeline integrity is attested: log-collector versions, eval-replay infrastructure, drift-monitoring agents, retention-horizon enforcement, and access-control on the telemetry corpus. Article 72 post-market monitoring depends on telemetry the deployer trusts; observability attestation is what gives the monitoring evidence its own evidentiary weight.

The 8 layers compose: Layer 1's signature anchors Layer 2's training-data attestation; Layers 2 and 3 anchor Layer 4's eval claims; Layers 1-5 anchor the deployment artifact; Layer 6 attests the corpus the deployment will query; Layers 7-8 attest the runtime and observability the deployment will execute under. The 8-layer chain is the regulator-grade evidence package an Article 73 incident investigation, an Article 26(5) monitoring inquiry, an Annex XII downstream-deployer request, or a Schellman / A-LIGN / BDO / KPMG SOC 2 + AI fieldwork engagement will request.

Deployer-Side Verification, Annex XII Integration, and the 2026 Maturity Tiers

An attestation chain published by the provider that no deployer ever verifies is theater. The closed loop requires deployer-side verification at two events: (1) at deployment time, before the artifact is promoted to production, the deployer's CI/CD pipeline reads the CDXA signature envelope, verifies each layer's signature against the expected signing identity, verifies the inclusion proof in the public transparency log (Rekor or equivalent), checks the SLSA level meets the procurement-policy minimum, and blocks promotion if any check fails; and (2) at every substantial-modification trigger per Article 43(4), the deployer re-reads the CDXA envelope, diffs against the prior verified state, and routes any layer-change to the substantial-modification workflow.

Article 26(5), the deployer's monitoring obligation, anchors the verification cadence. A deployer that monitors operation but does not verify the supply-chain attestation behind that operation cannot evidence that the system under monitoring is the system under attestation. A mismatch flags one of two conditions: vendor breach (the provider shipped a substantially modified artifact without re-attestation) or substantial modification under Article 43(4) (the deployer's own integration shifted in a way that warrants re-conformity). Either condition routes to the AI Risk Office for triage.

Annex XII downstream-deployer information. Annex XII obliges providers to make information available enabling deployers to discharge their own Article 26 obligations. By Q2 2026 the de facto Annex XII content package includes: the ML-BoM (CycloneDX 1.7 JSON or canonical equivalent); the CDXA attestation envelope covering all 8 layers; the SLSA level achieved for the deployment pipeline; the SBOM-AI for the inference runtime; the VEX statement set for the SBOM dependencies; the most recent eval pass-rate attestation with probe-pack hash; the Article 53(1)(d) training-data summary reference; the model-card reference; the datasheet-for-datasets references; the substantial-modification log since the prior Annex XII issuance; and the provider's named contact for deployer follow-up. An Annex XII package without the ML-BoM + CDXA in 2026 is increasingly insufficient, both as a regulator-defensible artifact and as a procurement-acceptable artifact.

The Four 2026 Maturity Tiers

Tier-A enterprise procurement converged in Q1 2026 on a four-tier maturity model for supplier supply-chain attestation. The tier assignment is a procurement-intake screen and a contract-renewal screen.

• Tier A - Full ML-BoM + CDXA signed by a certified third-party attestor. The supplier publishes a complete 9-component ML-BoM, signed via CDXA, with the 8-layer chain fully populated, with SLSA Level 3+ for the deployment pipeline, with SLSA-AI draft conformance for the model artifacts, and with at least one third-party attestation overlay: Schellman, A-LIGN, BDO, KPMG, BSI, or a comparable AICPA peer-reviewed CPA firm pre-attesting either the fine-tune dataset provenance, the training-run reproducibility claim, or the eval-suite probe-pack integrity. Tier-A vendors clear procurement intake at the speed-of-light path and command pricing premium.
• Tier B - ML-BoM + self-signed CDXA attestation. The supplier publishes the ML-BoM and signs the CDXA envelope with its own organizational key (KMS-backed or Sigstore keyless), without third-party attestor overlay. The 8-layer chain may be partially populated. SLSA Level 2 for the deployment pipeline is typical. Procurement intake accepts Tier B with contractual flow-down obliging Tier A within 12-18 months; ongoing monitoring is more intensive than for Tier A.
• Tier C - ML-BoM only, no signed attestation. The supplier publishes a ML-BoM (often as a static JSON in the repository) but ships no CDXA signatures or only software-level cosign signatures on the container. Procurement intake accepts Tier C only for non-critical, sub-tier deployments; multi-year tier-A enterprise deals are not signed against Tier C.
• Tier D - No ML-BoM published. The supplier publishes no AI-component inventory. Tier D is a 2026 procurement red flag per the procurement-tier matrix established in lesson 070. Tier D vendors are disqualified from tier-A enterprise deal flow and increasingly from tier-B mid-market deal flow; they remain accessible to internal-only / non-regulated / startup-tier deployments where the buyer absorbs the supply-chain risk.

Seven Common 2026 Supply-Chain Attestation Failures

By Q2 2026 the first wave of ~400-600 supply-chain attestation programs across foundation-model providers, mid-market AI vendors, and enterprise deployer-providers has produced seven recurrent failure modes. Each maps to a remediation and a procurement-intake red flag.

Failure 1 - ML-BoM Published but Never Signed

The most common Tier-C state: a static CycloneDX 1.7 JSON in the repository, refreshed quarterly, never signed via CDXA. The artifact has no cryptographic distinguishability from a tampered copy; a downstream deployer cannot rely on the BoM as evidence. Remediation: add CDXA signing to the CI pipeline; require Sigstore keyless or KMS-backed signature for every BoM artifact leaving the build; require signature-verification at every consumption point.

Failure 2 - Sigstore / KMS Signing Keys Held by the Engineering Team That Built the Model

An independence breach: if the same team that produced the artifact also signs the attestation, the signature attests to the artifact's existence but not to its independent validation. Remediation: separate signing-key ownership from build-team ownership; require third-party attestor co-signature for Tier-A; route Sigstore keyless to a CI runner identity bound to organizational OIDC (not individual engineer accounts); document the independence boundary in the AI governance committee charter.

Failure 3 - CDXA Not Refreshed at Substantial-Modification Events

The supplier signs a CDXA envelope at v1.0 release and never re-signs through v1.1, v1.2, v2.0. The deployed system is no longer the attested system. The Article 43(4) substantial-modification trigger fires for the deployer; the supplier breach is the failure to re-attest. Remediation: tie CDXA refresh to the substantial-modification gate in CI/CD (lesson 029 + lesson 077); fail the build promotion if the CDXA envelope is stale.

Failure 4 - RAG Corpus Snapshot Omitted from the BoM (the Largest Attack Surface)

The ML-BoM lists the base model, the embedding model, and the eval suite, and omits the retrieval-corpus snapshot. Prompt-injection attacks against indexed content are the dominant exfiltration vector for RAG-agent systems; without the corpus-snapshot BoM line, the substantial-modification gate is blind to corpus-poisoning events. Remediation: add the retrieval-corpus snapshot as a required component class in the CI pipeline; hash the article set on every ingestion; fail the build if the snapshot hash is missing or unchanged-but-reindexed.

Failure 5 - Eval-Suite Versions Floated (False-Security Posture)

The ML-BoM lists "Promptfoo latest" or "Garak v0.14.x" instead of a pinned version with a probe-pack content hash. The same artifact may pass yesterday's probe set and fail tomorrow's, with no BoM signal. The CDXA evaluation attestation loses its claim integrity. Remediation: pin every eval-suite version to a specific release tag; hash the probe-pack contents; bundle the probe-pack hash into the CDXA evaluation attestation; treat eval-suite version changes as substantial-modification triggers.

Failure 6 - Inference-Runtime SBOM-AI Missed (Memory-Safety Attack Vector Ignored)

The ML-BoM covers the model components and ignores the serving stack. Memory-safety CVEs in vLLM, TGI, TensorRT-LLM, and SGLang have been a recurrent attack vector throughout 2025-2026; without an inference-runtime SBOM-AI entry plus VEX exploitability statements, the deployer cannot verify the patching posture. Remediation: require the inference-runtime SBOM-AI as a required component class; cross-reference VEX statements for the runtime's dependency tree; gate deployment on no-open-affected-with-no-workaround CVE state.

Failure 7 - No Verification by the Deployer (the Loop Never Closes)

The provider publishes the ML-BoM, signs the CDXA, refreshes on substantial modification, and the deployer never verifies. The attestation is theater. The Article 26(5) monitoring obligation is unmet because the monitored system cannot be evidenced as the attested system. Remediation: wire CDXA verification into the deployer's CI/CD pipeline at deployment time; verify each layer's signature against the expected signing identity; verify the inclusion proof in the public transparency log; block promotion if any check fails; log the verification event for audit retention per Article 18 (10 years).

Worked Example - Acme.ServiceAssist v1.0 Tier-A Attestation, and the L4 Capstone Frame

Acme.ServiceAssist v1.0, the worked example threaded throughout this program, published its full ML-BoM + CDXA attestation set in Q2 2026 at Tier-A maturity. The composition:

• 9 components signed via cosign keyless with Sigstore Fulcio CA and Rekor transparency log inclusion proofs. Base model (Anthropic Claude 4 Opus API-version anchor); fine-tune dataset (Acme customer-service transcripts v2026-04-15 with Schellman pre-attestation of the lawful-basis chain); embedding model (OpenAI text-embedding-3-large 2025-09 version); retrieval corpus (Acme KB v2026-05 with article-set hash and ingestion-pipeline integrity attestation); tools (ServiceNow connector v2.3, AD MCP server v1.2, M365 Graph connector v3.1, each with permission scopes and tool-card references); memory layer (Redis-backed conversational memory with 30-day retention policy); judge models + eval suite (Promptfoo v0.95.1 post-OpenAI-acquisition, Garak v0.14.3, PyRIT v0.5.0, Inspect v0.3.2, OpenAI Evals v2026-04, all probe-pack hashes pinned); inference runtime (vLLM v0.6.x container with SBOM-AI overlay and VEX exploitability statements); telemetry pipeline (OpenTelemetry collector + custom eval-replay agents, 18-month retention horizon).
• SLSA Level 3 achieved for the deployment pipeline. Build platform hardened; source-and-build version-controlled in GitHub with required two-party review; provenance signed via cosign keyless with the Acme CI runner's OIDC identity binding; Rekor inclusion proof for every build.
• Schellman pre-attestation overlay on Layer 2 (fine-tune training-data attestation). Schellman issued a SOC 2 + AI bridge-letter style pre-attestation on the lawful-basis chain for the Acme customer-service transcript corpus: covering Article 10 quality-management compliance, Article 53(1)(d) training-data summary content, the datasheet-for-datasets reference, and the opt-out compliance for any in-scope training-data subjects. The Schellman attestation is itself signed and bundled into the CDXA envelope.
• Annex XII downstream-deployer information package. Includes the ML-BoM SHA-256 (with full JSON downloadable from the signed Acme artifact registry); the CDXA envelope; the SLSA level achieved; the SBOM-AI for the inference runtime; the VEX statement set; the most recent eval pass-rate attestation; the Article 53(1)(d) training-data summary reference; model-card reference; datasheet-for-datasets references; the substantial-modification log since the prior Annex XII issuance; and the named provider-side contact for deployer follow-up.
• Verification by 27 enterprise deployers via signed transparency log. By end of Q2 2026, 27 of Acme's enterprise customers had wired CDXA verification into their own CI/CD pipelines, pulling the Acme attestation envelope, verifying each layer's signature against the Acme signing identity, verifying the Rekor inclusion proof, checking SLSA Level 3, and logging the verification event for their own Article 18 retention. The closed loop, provider attestation + deployer verification, was operational.

The L4 capstone frame. This lesson closes Level 4 (the AI Governance Lead tier). The L4 governance leader's supplier-trust architecture is the synthesis of five lesson tracks that have been built across L3 and L4: vendor due diligence (lessons 070 third-party diligence + 071 review of vendor model card / SOC 2 + AI / ML-BoM); Article 25(2) cooperation mechanics (lesson 026 Article 25 substantial-modification baseline + lesson 077 GPAI provider cooperation operational); Annex XII downstream-deployer information (referenced across the Annex XII lessons); supply-chain attestation (this lesson 096); and SOC 2 + AI / ISO 42001 attestation programs (lessons 091-092 attestation program design + 093 internal audit). The L4 leader does not run each in isolation; she composes them into one coherent supplier-trust architecture: one ML-BoM that serves Article 11 + Annex IV technical documentation, Article 53 GPAI provider documentation, Article 26 deployer monitoring, Annex XII downstream-deployer information, ISO 42001 A.10 third-party relationships, NIST AI RMF Govern 6 + Manage 4.3, NIST SSDF SP 800-218 / SP 800-218A, SR 11-7 supply-chain risk for financial services, and the CDXA / SLSA / SLSA-AI / Sigstore signing infrastructure that makes the whole evidence package cryptographically verifiable. The L5 leader (lessons 097-110, beginning with the Chief AI Risk Officer mandate) inherits this architecture and operates it across the multi-year enterprise risk-appetite cycle.

Key Takeaways

• 2026 AI systems are supply chains of supply chains. Foundation-model providers + fine-tune layers + RAG corpus + eval suites + tools + inference runtime + telemetry compose a multi-layer attack surface. OWASP LLM03 Supply Chain, CISA Secure-by-Design, ENISA AI threat-landscape 2026, NIST SSDF SP 800-218 + 800-218A, and EU AI Act Articles 15 + 25(2) + 26(5) + 43(4) + Annex XII converge on signed attestation as the regulator-enforceable answer.
• The nine-component ML-BoM is the L4 baseline. Base model; fine-tune dataset(s); embedding model; retrieval corpus snapshot; tools / function library; memory layer + retention policy; judge models + eval suites; inference runtime + serving stack; telemetry pipeline + monitoring agents. CycloneDX 1.7 ships the integrated model natively; SBOM-AI is the SBOM-with-AI-overlay sibling; SPDX 3.0 AI profile is the parallel SPDX serialization. A ML-BoM that lists only the foundation model is a Tier-C or Tier-D failure.
• CDXA + Sigstore + DSSE + in-toto + SLSA / SLSA-AI is the 2026 signing-infrastructure default. CDXA binds typed claims (build provenance, component identity, evaluation, policy compliance) to ML-BoM components; in-toto provides the predicate model; DSSE provides the signing envelope; Sigstore (cosign + Fulcio + Rekor) is the OSS-default chain of trust; KMS-backed signing is the enterprise alternative; SLSA Level 3+ for the deployment pipeline and SLSA-AI draft conformance for the model artifacts is the procurement-tier-A expectation.
• The 8-layer attestation chain is the regulator-grade evidence package. Layer 1 foundation-model provider + Layer 2 fine-tune training-data + Layer 3 fine-tune training-run + Layer 4 eval-suite + Layer 5 deployment-pipeline + Layer 6 RAG corpus + Layer 7 inference-runtime + Layer 8 observability. Each layer signs the artifact it produces and the layer below; the deployer verifies the full chain at deployment time and at every substantial-modification trigger per Article 43(4).
• Deployer-side verification is what closes the loop. Article 26(5) monitoring obligation requires the monitored system to be evidence-bound to the attested system. CDXA verification at deployment time + at every substantial-modification trigger + audit-retention logging per Article 18 (10 years) is the operational pattern. An attestation chain no one verifies is theater.
• Annex XII downstream-deployer information now includes ML-BoM + CDXA by default. ML-BoM SHA-256, CDXA envelope, SLSA level, SBOM-AI for the inference runtime, VEX statement set, eval pass-rate attestation, Article 53(1)(d) training-data summary reference, model-card and datasheet references, substantial-modification log, named provider-side contact. An Annex XII package without these is increasingly procurement-rejected and regulator-insufficient.
• The four 2026 maturity tiers are the procurement-intake screen. Tier A (full ML-BoM + CDXA signed by certified third-party attestor; SLSA Level 3+; SLSA-AI draft conformance); Tier B (ML-BoM + self-signed CDXA); Tier C (ML-BoM only, no signed attestation); Tier D (no ML-BoM, 2026 red flag per lesson 070). Tier-D vendors are disqualified from tier-A enterprise deal flow.
• Seven recurring 2026 failure modes. ML-BoM published but never signed; signing keys held by the build team (independence breach); CDXA not refreshed at substantial-modification events; RAG corpus snapshot omitted (largest attack surface); eval-suite versions floated (false security); inference-runtime SBOM-AI missed (memory-safety attack vector ignored); no verification by the deployer (the loop never closes). Each maps to a CI-pipeline policy fix and a governance-workflow gate.
• L4 capstone, the supplier-trust architecture. The L4 governance leader synthesizes vendor due diligence (lessons 070-071), Article 25(2) cooperation (lessons 026, 077), Annex XII downstream-deployer information (across), supply-chain attestation (this lesson), and SOC 2 + AI / ISO 42001 attestation programs (lessons 091-093) into one coherent evidence chain. One ML-BoM serves Article 11 + Annex IV + Article 53 + Article 26 + Annex XII + ISO 42001 A.10 + NIST AI RMF Govern 6 + NIST SSDF SP 800-218A + SR 11-7 supply-chain risk, cryptographically verifiable via CDXA / SLSA / SLSA-AI / Sigstore. The L5 Chief AI Risk Officer inherits this architecture and operates it across the multi-year enterprise risk-appetite cycle.