AI Control Library / CF-13: Model & Adversarial Security
Designation: Core | Control types represented: Operational and Technical
Control requirement
Prevent and detect tampering across model acquisition, packaging, distribution and deployment. Verify provenance and integrity of weights, adapters, tokenizers, code and dependencies before execution.
Why this matters
A model package may include executable loaders or dependencies as well as weights. An authentic-looking repository name or matching filename does not establish a trusted supply path.
How the control types work together
Operational controls define scope, authority and the actions required when conditions are not met. Technical controls produce evidence or enforce the relevant boundaries. Both must apply to the same deployment and operating conditions.
When it applies
Apply to purchased, open-source and internally transferred models. Include mirrors, registries, caches and updates delivered by suppliers.
Define the assessed boundary, dependencies and evidence limitations. Tailor depth and review frequency to potential impact, and document why a particular safeguard or exclusion is appropriate to the actual deployment.
Ownership
The model supply-chain owner approves sources; platform engineers verify artifacts; security evaluates suspicious packages.
Implementation guidance
- Approve suppliers and record expected artifacts and versions.
- Verify signed provenance or trusted integrity references where available.
- Inspect unsafe serialization and executable loading paths in isolated environments.
- Protect registries and revalidate artifacts at deployment.
How to verify it
Use representative records and authorized controlled tests. Identify the relevant version, operating conditions and expected result before testing, and retain enough evidence to support the conclusion.
| Test | Expected result |
|---|---|
| Artifact replaced in transit | Integrity verification rejects it. |
| Unapproved loader executes | Isolation prevents production access. |
| Supplier update arrives | Version and provenance review precede promotion. |
Record a finding when required results cannot be demonstrated or practice differs materially from the approved conditions. Missing evidence limits the conclusion; it should not be treated as a successful test.
Evidence to retain
- Source approvals
- Artifact manifests
- Verification results
- Supplier change records
Protect evidence according to its sensitivity, access needs and retention rules. Avoid unnecessary copies of personal information, secrets or confidential material, while preserving the records needed for authorized review.
If the control fails
Quarantine the package, block affected distribution paths and determine whether executed components accessed credentials or production data.
Example in practice
Hypothetical example: A model mirror supplies a package with an unexpected loader script. The team evaluates it in isolation and obtains the approved artifact through a verified supplier channel.
Related controls
- CF13-001: AI Training Pipeline Security
- CF13-006: Backdoor Attack Detection & Prevention
- CF13-008: Production Model Integrity Monitoring
Framework mappings
- CSA AICM (MDS-08, MDS-09)
- NIST AI RMF (MEASURE 2.5)
- MITRE ATLAS
Review and maintenance
Review at the interval approved by the control owner and after relevant changes, incidents or failed assessments. Update affected procedures and configuration, address evidence gaps and verify corrective action before closing findings.
Back to Model & Adversarial Security
Version 1.0