AI Control Library / CF-03: AI Supply Chain & Third-Party Risk
Designation: Core | Control types represented: Operational and Technical
Control requirement
Approve model formats and loading paths that minimize code execution during deserialization, validate artifact structure and restrict required custom code. Treat format choice, loader configuration and dependency maintenance as a combined control.
Why this matters
Some serialization mechanisms can execute code while loading an artifact, before inference begins. A data-oriented weight format reduces that particular exposure but does not make repository code, parsers, dependencies or model behavior inherently trustworthy.
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 checkpoints, adapters and serialization or conversion paths used during evaluation, training and deployment, including vendor-supplied loaders.
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 platform owner is accountable; security approves loading exceptions and release teams verify the deployed path.
Implementation guidance
- Inventory accepted formats and loader behaviors; prefer data-oriented formats that avoid embedded executable object reconstruction where compatible.
- Require maintained loader dependencies and explicitly restricted loading options; do not assume defaults or a file extension provide the intended protection.
- Review custom repository code and conversion requirements separately, evaluating unavoidable execution in an isolated, least-privilege environment without production credentials.
- Validate format structure, sizes and expected tensors, preserve approved conversion lineage and reject unapproved loader or artifact substitutions.
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 |
|---|---|
| Inspect an approved loading path | Format, actual parser, dependency versions and execution settings match the intended restrictions. |
| Present an unapproved format or custom loader in an authorized test | The acceptance process rejects or isolates it for review. |
| Review a conversion workflow | Source loading is isolated and resulting artifacts retain traceability and validation. |
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
- Approved format and loader standard
- Loader configuration and dependency evidence
- Custom-code and conversion reviews
- Format validation and rejection tests
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 artifacts requiring unexpected execution and notify security and platform owners. Do not enable unrestricted loading merely to clear an error; assess a controlled exception or alternative artifact.
Example in practice
Hypothetical example: A checkpoint fails under restricted loading. Instead of disabling protections on a production host, the team investigates in isolation and obtains an approved data-oriented artifact with verified provenance.
Related controls
- CF03-014: Model Provenance & Integrity Verification
- CF03-015: Open-Source & Open-Weight Model Risk Assessment
- CF03-017: AI Model Artifact Scanning
Framework mappings
- CSA AICM (MDS-13)
- NIST AI RMF (MAP 1.6)
- 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.
Technical references: Hugging Face: Pickle Scanning; PyTorch: torch.load. Consult the documentation for the exact deployed loader version when configuring restricted loading.
Back to AI Supply Chain & Third-Party Risk
Version 1.0