AI Control Library / CF-08: Testing & Robustness
Designation: Core | Control types represented: Operational and Technical
Control requirement
Manage AI security vulnerabilities across models, data, applications, tools and infrastructure through risk-based triage, containment, correction and verified closure. Preserve the distinction between fixing a component and resolving the full exposure.
Why this matters
A vulnerability may require a permission change, model replacement or workflow restriction rather than a patch. Closure needs evidence that the relevant attack path no longer exceeds accepted conditions.
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
AI vulnerabilities identified by tests, advisories, incidents, researchers or operational monitoring across the system lifecycle.
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 AI vulnerability owner coordinates component owners and security; accountable risk authorities approve residual exposure.
Implementation guidance
- Record the affected scope, evidence, prerequisites and consequence, distinguishing duplicates from different paths.
- Prioritize by actual exposure and potential harm, defining interim containment, owners and deadlines.
- Implement controlled remediation across affected deployments and supplier dependencies, checking legitimate-use regressions.
- Retest the relevant failure path and review remaining exposure before closure or time-limited acceptance.
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 |
|---|---|
| Trace a critical vulnerability | Containment and ownership reflect current exposure. |
| Review a claimed correction | The deployed boundary and relevant conditions were retested. |
| Inspect recurring findings | Root causes and related deployments receive treatment rather than repeated isolated closure. |
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
- AI vulnerability register
- Prioritization and containment
- Change and deployment records
- Retest and residual-risk decisions
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
Escalate failed correction or overdue material exposure to security and risk owners. Restrict consequential functions or vulnerable access while acceptable protection is restored.
Example in practice
Hypothetical example: A prompt-injection finding leads to stronger tool authorization. Retest confirms blocked action across both the parent agent and child workers before the system-level finding is closed.
Related controls
- CF08-003: AI System Penetration Testing
- CF08-S06: AI Application Vulnerability Remediation
- CF04-006: AI Audit Finding Remediation
Framework mappings
- CSA AICM (TVM-07, TVM-08)
- NIST AI RMF (MANAGE 2.4)
- 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.
Version 1.0