AI Control Library / CF-13: Model & Adversarial Security
Designation: Core | Control types represented: Operational and Technical
Control requirement
Protect model availability against inputs, request patterns and workload amplification that exhaust compute, memory, queues or dependencies. Enforce bounded resource use and tested overload behavior.
Why this matters
A modest number of expensive requests can exhaust inference capacity. Long contexts, tool loops and repeated retries can amplify demand beyond what ordinary request-per-second limits capture.
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 synchronous, streaming and batch inference, including multimodal processing and agent workflows sharing the same model infrastructure.
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 service owner defines availability objectives; platform teams enforce resource controls; security handles malicious demand.
Implementation guidance
- Model cost drivers and dependency bottlenecks.
- Bound input size, output length, concurrency, execution time and retries.
- Allocate tenant budgets and prioritize essential workloads.
- Load-test expensive valid inputs, queue saturation and recovery.
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 |
|---|---|
| Expensive request flood | Resource ceilings prevent uncontrolled exhaustion. |
| One tenant saturates quota | Other tenants retain defined service. |
| Dependency overload | Backpressure avoids retry amplification. |
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
- Capacity model
- Quota configuration
- Stress-test results
- Recovery 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
Apply overload protection, stop amplifying workflows and restore service in priority order while preserving abuse evidence.
Example in practice
Hypothetical example: A service limits concurrent long-context jobs per tenant. A burst of large documents enters a bounded queue instead of consuming every inference worker.
Related controls
- CF12-S14: AI Infrastructure Capacity Planning
- CF13-009: Model Inference API Abuse Detection
- CF14-006: Autonomous Resource Acquisition Prevention
Framework mappings
- 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 Model & Adversarial Security
Version 1.0