AI Control Library / CF-12: Security & Abuse Resistance
Designation: Supplemental | Control types represented: Operational and Technical
Control requirement
Define and enforce credential requirements for AI users, workloads and integrations, including secure issuance, storage, recovery and replacement after compromise. Use managed identities where supported.
Why this matters
Shared or embedded credentials obscure accountability and spread exposure across models, tools and environments. A written password rule cannot protect a secret stored in a notebook or prompt.
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 passwords, API keys, access tokens and service credentials. Align human password requirements with the deployed authentication method and current identity standards.
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 identity owner sets requirements; service owners remove embedded credentials; security manages compromise response.
Implementation guidance
- Inventory credential types and approved authentication methods.
- Enforce suitable password controls and prohibit shared human credentials.
- Use managed identities or protected secret storage for services.
- Test recovery, compromised-credential replacement and residual access.
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 |
|---|---|
| Credential discovered in code | It is revoked and replaced securely. |
| Shared account review | Individual accountability is restored. |
| Compromised credential revoked | Dependent access no longer succeeds. |
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
- Credential policy
- Inventory
- Recovery tests
- Revocation records
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
Revoke exposed credentials, inspect dependent systems and eliminate the storage or sharing practice that caused exposure.
Example in practice
Hypothetical example: A team replaces a shared model-provider key in a notebook with a managed secret and separate service identities for production and testing.
Related controls
- CF12-003: AI System Strong Authentication
- CF12-S11: AI System Secrets Management
- CF12-S10: AI System Unique User Identification
Framework mappings
- CSA AICM (IAM-02)
- 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