AI Control Library / CF-03: AI Supply Chain & Third-Party Risk
Designation: Core | Control types represented: Operational and Technical
Control requirement
Verify the source, identity and integrity of model artifacts before accepting and deploying them. Preserve evidence tying approved artifacts, adaptations and configurations to an attributable origin and to the exact version assessed.
Why this matters
A familiar model name or matching file checksum does not establish a trustworthy origin. Integrity checks need a trusted reference, and provenance must account for repackaging, conversion and adaptation.
How the control types work together
Operational controls define acceptance, responsibility and response. Technical controls verify artifacts, observe actual use or enforce data and action boundaries. The process must cover the same deployment that the technical mechanisms protect.
When it applies
Model downloads, supplied artifacts, adapters, quantized or converted derivatives and deployment transfers; hosted services require identifiable provider and version evidence within available visibility.
Tailor review depth to information sensitivity, granted authority and business dependence. Record what the organization can test directly, what relies on provider evidence and how material visibility gaps affect the acceptance decision.
Ownership
The model supply chain owner coordinates; platform and security teams verify artifacts and release owners accept limitations.
Implementation guidance
- Obtain artifacts from approved sources and record publisher identity, repository revision, acquisition route and derivation history.
- Compare hashes or signatures against independently trusted references where available, validating the signer or reference origin rather than file consistency alone.
- Record conversions, adapters and local changes, linking their output integrity references to the assessed deployment baseline.
- Protect approved artifacts from substitution during storage and deployment, and reverify after transfers or material modifications.
How to verify it
Use representative deployment records and authorized controlled tests. Establish the assessed service, artifact version and acceptance conditions before interpreting results; do not extend evidence beyond the boundary it covers.
| Test | Expected result |
|---|---|
| Substitute a model artifact in a controlled test | Verification detects that the deployed bytes differ from the approved reference. |
| Inspect the reference origin | The organization can explain why it trusts the publisher, signature or digest source. |
| Trace a converted derivative | Its parent, conversion process and assessed output are attributable. |
Record a finding when a required result cannot be demonstrated or actual practice differs materially from the accepted conditions. Assign corrective action and verify the affected boundary before closing the issue.
Evidence to retain
- Acquisition and publisher records
- Trusted integrity references
- Verification and derivation records
- Approved-artifact and deployment links
Protect supplier-confidential information, credentials and personal data in these records. Preserve enough version and scope information to establish which service or artifact the evidence supports.
If the control fails
Quarantine mismatched or unattributable artifacts and notify security and release owners. Do not bypass an integrity failure because the file carries an expected model name.
Example in practice
Hypothetical example: A mirror supplies a file whose checksum matches a digest posted on that same mirror. The team does not treat this as publisher authentication and obtains an independently trusted reference before acceptance.
Related controls
- CF03-013: AI Service Bill of Materials (AI-BOM)
- CF03-015: Open-Source & Open-Weight Model Risk Assessment
- CF13-008: Production Model Integrity Monitoring
Framework mappings
- CSA AICM (MDS-08, MDS-09)
- NIST AI RMF (MAP 1.6)
- EU AI Act (Art. 15(1))
- ISO 42001 (Cl. 8.3, A9.1)
- MITRE ATLAS
Review and maintenance
Review at the interval approved by the control owner and after relevant supplier, component, contract, access or deployment changes. Reassess material incidents and new evidence, updating acceptance conditions and verifying corrective actions where required.
Back to AI Supply Chain & Third-Party Risk
Version 1.0