AI Control Library / CF-12: Security & Abuse Resistance
Designation: Supplemental | Control types represented: Operational and Technical
Control requirement
Assign unique, traceable identities to AI users and administrative actors. Preserve attribution through shared interfaces and delegated actions without exposing unnecessary personal information.
Why this matters
Shared accounts prevent reliable access review and incident reconstruction. A generic application identity can also hide which user authorized a consequential action.
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 employees, contractors, suppliers and support personnel. Use distinct workload identities with recorded ownership for automated services.
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 establishes identifiers; application teams propagate actor context; service owners maintain identity ownership.
Implementation guidance
- Prohibit shared human accounts except controlled justified exceptions.
- Use stable identifiers and protect identity-to-person mappings.
- Record initiating user and executing workload for delegated actions.
- Test attribution across authentication, tool calls and audit records.
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 |
|---|---|
| Action trace sample | Initiator and executor can be identified. |
| Shared human account discovery | Exception is resolved or controlled. |
| Identity lifecycle change | Historical attribution remains interpretable. |
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
- Identity standard
- Account inventory
- Attribution tests
- Exception 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
Replace unaccountable access, preserve available attribution evidence and investigate consequential activity under shared identities.
Example in practice
Hypothetical example: A tool call records both the employee who authorized the request and the agent service that executed it, allowing reviewers to reconstruct responsibility.
Related controls
- CF12-S02: AI System Identity Inventory
- CF12-003: AI System Strong Authentication
- CF12-S09: AI Audit Log Infrastructure Protection
Framework mappings
- CSA AICM (IAM-13)
- 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