AI Control Library / CF-12: Security & Abuse Resistance
Designation: Supplemental | Control types represented: Operational and Technical
Control requirement
Implement consistent authorization mechanisms that evaluate subject, action, resource and relevant context at each protected operation. Deny access when required identity or policy information is unavailable.
Why this matters
Authentication establishes an identity; it does not establish permission for every object or action. UI-only checks and stale authorization decisions leave alternate endpoints exposed.
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 APIs, tools, retrieval, administrative functions and background jobs. Include tenant, task and delegation context where required.
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 security architecture owner defines policy; resource owners authorize access rules; engineers implement enforcement.
Implementation guidance
- Define policy inputs and default-deny behavior.
- Enforce checks in trusted services before protected effects.
- Propagate authenticated context without accepting caller-supplied privilege claims.
- Test object access, policy updates and unavailable policy dependencies.
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 |
|---|---|
| Changed resource identifier | Authorization is re-evaluated. |
| Policy service unavailable | Protected action follows fail-safe behavior. |
| Revoked permission | Cached decisions expire within approved limits. |
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
- Authorization design
- Policy versions
- Boundary tests
- Denial 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
Block affected operations, inspect unauthorized use and repair inconsistent enforcement before restoring access.
Example in practice
Hypothetical example: A user changes a job identifier in an API request. The backend checks tenant ownership rather than trusting that the interface displayed only authorized jobs.
Related controls
- CF12-002: AI System Least Privilege Access Control
- CF12-007: AI API Security
- CF14-001: Agentic System Security Boundaries
Framework mappings
- CSA AICM (IAM-16)
- 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