AI Control Library / CF-12: Security & Abuse Resistance
Designation: Core | Control types represented: Operational and Technical
Control requirement
Secure AI APIs with authenticated identities, object- and function-level authorization, validated inputs, protected transport, bounded consumption and accountable logging. Cover all supported versions and alternate endpoints.
Why this matters
AI-specific risks coexist with ordinary API failures such as cross-tenant object access and exposed administrative functions. A model safety layer does not repair these application vulnerabilities.
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 inference, retrieval, training, administration, batch and tool APIs, including internal integrations and supplier gateways.
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 API owner maintains the interface; application security tests boundaries; operations monitors access and abuse.
Implementation guidance
- Inventory endpoints, versions, callers and exposed operations.
- Enforce authentication and authorization for each object and function.
- Validate schemas, protect transport and limit size, rate and execution.
- Test tenant isolation, error handling and deprecated endpoints.
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 |
|---|---|
| Another tenant’s object ID | Access is denied. |
| Malformed or oversized request | Request is safely rejected. |
| Deprecated endpoint | Equivalent controls apply or endpoint is disabled. |
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
- API inventory
- Authorization rules
- Security test results
- Access and abuse logs
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
Isolate vulnerable endpoints, revoke exposed credentials and investigate affected objects and callers before reopening access.
Example in practice
Hypothetical example: An inference API correctly authenticates a user but initially accepts another tenant’s job identifier. Object-level authorization is added and tested on every job endpoint.
Related controls
- CF12-003: AI System Strong Authentication
- CF12-S12: AI System Authorization Mechanisms
- CF13-009: Model Inference API Abuse Detection
Framework mappings
- CSA AICM (AIS-10)
- NIST AI RMF (MEASURE 2.5)
- MITRE ATLAS
- OWASP LLM Top 10
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