AI Control Library / CF-13: Model & Adversarial Security
Designation: Core | Control types represented: Operational and Technical
Control requirement
Monitor production model artifacts and serving configuration against approved versions. Detect unauthorized changes to weights, adapters, preprocessing, routing and other components that determine executed behavior.
Why this matters
A model registry can show the approved version while a serving worker loads a different adapter or preprocessing configuration. Integrity must cover what is actually running.
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 self-hosted models and provider integrations to the extent evidence and controls are available. Record visibility limits for externally managed components.
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 serving platform owner maintains approved state; release management authorizes changes; security handles unexplained deviations.
Implementation guidance
- Define integrity baselines for artifacts and serving dependencies.
- Verify artifacts at deployment and monitor actual loaded versions.
- Control configuration updates and record authorized changes.
- Alert on unexplained drift and test isolation or rollback.
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 |
|---|---|
| Modified model artifact | Load is blocked or deviation alerts. |
| Unauthorized routing change | Runtime comparison detects mismatch. |
| Approved update | New baseline is authorized and 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
- Approved manifests
- Runtime attestations
- Change records
- Integrity alerts
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
Isolate affected workers, preserve suspect artifacts and restore verified versions after evaluating any affected outputs.
Example in practice
Hypothetical example: A serving container loads an unapproved adapter from a writable volume. Integrity monitoring removes the worker from service and preserves its configuration for investigation.
Related controls
- CF13-001: AI Training Pipeline Security
- CF13-011: Model Supply Chain Tampering Defense
- CF09-001: AI Monitoring & Drift Detection Policy
Framework mappings
- CSA AICM (MDS-08)
- 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