AI Control Library / CF-12: Security & Abuse Resistance
Designation: Core | Control types represented: Operational and Technical
Control requirement
Protect AI processing paths against malware, malicious files and service abuse using controlled ingestion, appropriate detection, safe execution and coordinated response. Cover content entering through tools and integrations.
Why this matters
AI workflows often parse unfamiliar files or execute supporting tools. Malware can target those components independently of the model, while abusive use can harm users or infrastructure.
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 uploads, model packages, generated executable files, document processors and user-accessible AI services. Match scanning and handling to supported file types.
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
Security operations owns threat response; platform teams secure processing; product owners define abuse handling.
Implementation guidance
- Inventory ingestion and execution paths and permitted content.
- Apply safe parsing, scanning and isolation before risky processing.
- Monitor malicious behavior and enforce proportionate abuse restrictions.
- Test detection, quarantine and recovery with authorized safe samples.
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 |
|---|---|
| Known safe test indicator | Configured detection and quarantine occur. |
| Unsupported risky file | Processing is rejected or isolated. |
| Compromised processor simulation | Containment prevents wider access. |
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
- Processing rules
- Detection configuration
- Quarantine records
- Response tests
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
Quarantine affected content and processors, revoke exposed credentials and investigate persistence and downstream effects.
Example in practice
Hypothetical example: A document assistant receives a file that attempts to exploit its converter. The isolated processing service stops the job and prevents access to application storage.
Related controls
- CF12-008: AI Tool & Plugin Sandboxing
- CF12-S16: AI Infrastructure OS Hardening
- CF13-011: Model Supply Chain Tampering Defense
Framework mappings
- CSA AICM (TVM-02)
- 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