AI Control Library / CF-08: Testing & Robustness
Designation: Supplemental | Control types represented: Operational and Technical
Control requirement
Protect AI application source and behaviorally significant configuration through version control, controlled review, attributable changes and secure delivery links. Include prompts and tool definitions where they function as application artifacts.
Why this matters
Unreviewed prompt or permission edits can change behavior as much as code. Source management needs to identify what changed, who approved it and which deployed version contains it.
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
Application code, infrastructure definitions, prompts, tool schemas, evaluation configuration and relevant build scripts.
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 repository owner maintains access and review rules; development and release owners manage approved changes.
Implementation guidance
- Inventory authoritative repositories and versioned artifacts, assigning ownership and appropriate branch or change protection.
- Require attributable identities, proportionate review and protected handling of secrets and sensitive data.
- Link builds and releases to approved revisions, preventing unreviewed artifact substitution.
- Review access and recovery, test bypass conditions and retain history needed to investigate deployed behavior.
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 |
|---|---|
| Inspect a deployed artifact | Its authoritative revision and approval are traceable. |
| Attempt an unreviewed change to a protected path | The defined rule blocks or escalates it. |
| Scan repository handling | Secrets and sensitive evaluation data are not exposed through ordinary source access. |
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
- Repository scope and configuration
- Access and review records
- Revision-to-release links
- Bypass and secret-handling tests
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 unauthorized changes or exposed secrets to security and repository owners. Revoke affected authority, assess deployed impact and restore trustworthy history and artifacts.
Example in practice
Hypothetical example: A tool allowlist is moved from an editable runtime file into protected configuration. Review and release records now show when action authority changes.
Related controls
- CF08-S04: AI Secure Development Lifecycle
- CF01-012: AI System Baseline Management
- CF08-S05: AI Application Secure Deployment
Framework mappings
- CSA AICM (AIS-12)
- NIST AI RMF (MANAGE 4.2)
- 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.
Version 1.0