AI Control Library / CF-13: Model & Adversarial Security
Designation: Core | Control types represented: Operational and Technical
Control requirement
Protect training and fine-tuning pipelines against unauthorized changes to data, code, configuration, dependencies and model artifacts. Preserve a verifiable chain from approved inputs to the released model.
Why this matters
A secure inference service can still serve a compromised model if its build pipeline was altered. Training credentials and intermediate artifacts can expose both intellectual property and sensitive data.
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 internal training, fine-tuning, distillation and externally operated pipelines. Include notebooks, experiment trackers, checkpoints and automated promotion.
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 ML engineering owner secures pipeline execution; data owners approve inputs; release authorities approve deployment.
Implementation guidance
- Inventory pipeline stages, identities, artifacts and dependencies.
- Separate data approval, pipeline changes and release authorization.
- Use controlled builds, protected credentials and verified artifacts.
- Test unauthorized change detection and reconstruction of a released build.
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 |
|---|---|
| Unapproved data or code change | Pipeline rejects or holds the build. |
| Artifact modified after training | Integrity verification blocks promotion. |
| Released model sample | Approved inputs and configuration are traceable. |
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
- Pipeline configuration
- Input manifests
- Build attestations
- Release approvals
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
Stop promotion, isolate suspect artifacts and investigate affected runs before rebuilding from a trusted baseline.
Example in practice
Hypothetical example: A fine-tuning job finds that a dependency differs from the approved build manifest. Release remains blocked while engineers determine whether any checkpoints were affected.
Related controls
- CF13-003: Data Poisoning Attack Prevention & Detection
- CF13-011: Model Supply Chain Tampering Defense
- CF12-S17: AI Production & Non-Production Environment Separation
Framework mappings
- CSA AICM (MDS-01)
- NIST AI RMF (MEASURE 2.5)
- ISO 42001 (Cl. 8.2)
- 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