AI Control Library / CF-12: Security & Abuse Resistance
Designation: Supplemental | Control types represented: Operational
Control requirement
Establish infrastructure security requirements for AI compute, storage, networking and management services. Assign owners and define approved baselines, maintenance, monitoring and exception handling.
Why this matters
AI infrastructure often spans cloud services, accelerators, notebooks and managed platforms. Inconsistent ownership leaves gaps between the application and the underlying environment.
How the control types work together
Operational controls establish the assigned responsibilities, review processes and response decisions described here. Their effectiveness depends on performing the work and using evidence to guide action, rather than approving a document alone.
When it applies
Apply throughout development, deployment and retirement, including customer-managed and supplier-managed infrastructure within the service boundary.
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 infrastructure security owner maintains requirements; platform owners implement them; service owners account for provider responsibilities.
Implementation guidance
- Inventory infrastructure services and shared-responsibility boundaries.
- Define hardening, isolation, access, patching and monitoring requirements.
- Approve baselines and time-bound exceptions by risk.
- Assess deployments and track deviations to resolution.
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 |
|---|---|
| Infrastructure sample | Applicable baseline and owner are identified. |
| Provider service | Responsibility for each requirement is documented. |
| Exception sample | Justification, safeguards and expiry are current. |
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
- Infrastructure policy
- Responsibility matrix
- Baseline assessments
- Exceptions
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
Assign missing ownership, restrict exposed services and prioritize deviations that permit access to sensitive assets.
Example in practice
Hypothetical example: A team using managed GPU infrastructure records which security controls the provider operates and which remain its own responsibility, including notebook access and dataset permissions.
Related controls
- CF12-S16: AI Infrastructure OS Hardening
- CF12-S18: AI Infrastructure Segmentation
- CF12-S20: AI Infrastructure Network Documentation
Framework mappings
- CSA AICM (I&S-01)
- NIST AI RMF (MAP 1.1)
- ISO 42001 (Cl. 8.2)
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 Security & Abuse Resistance
Version 1.0