AI Control Library / CF-11: Objective & Policy Constraints
Designation: Core | Control types represented: Operational and Technical
Control requirement
Validate AI inputs at the relevant application boundaries, checking structure, size, origin, authorization and permitted content as appropriate. Treat external and retrieved material as untrusted without relying on filtering alone to establish safe behavior.
Why this matters
Inputs can carry malformed data, excessive resource demands or instructions disguised as task content. Validation should reduce relevant exposure while independent authorization protects consequential boundaries.
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
User input, files, retrieved context, API responses and tool inputs entering AI workflows.
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 application owner defines input contracts with security and domain reviewers; engineering implements and tests them.
Implementation guidance
- Identify input sources, formats and trust boundaries, distinguishing trusted configuration from user or retrieved content.
- Apply appropriate schema, length, file, origin and access checks before use, avoiding unsafe parsing or unchecked external references.
- Use content filtering where justified, recording its limits and safe handling of rejected or uncertain inputs.
- Test malformed, oversized, unauthorized and indirect-instruction cases, preserving legitimate-use requirements and controlled errors.
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 |
|---|---|
| Submit an invalid or excessive fixture | The relevant boundary rejects or safely contains it. |
| Retrieve unauthorized material | Access control prevents its inclusion rather than expecting the model to ignore it. |
| Test an indirect instruction | Consequential authority does not expand because the content requests it. |
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
- Input contracts and source map
- Validation and access configuration
- Adverse and legitimate-case tests
- Rejection and failure 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
Escalate bypass or unsafe parsing to security and the application owner. Restrict the affected input path and assess downstream exposure.
Example in practice
Hypothetical example: A document contains instructions to send data elsewhere. Input treatment marks it as task content, and independent tool authorization prevents the requested transfer even if the model repeats it.
Related controls
- CF12-010: Prompt Injection Defense
- CF05-012: AI Sensitive Data Protection
- CF08-007: AI Application Security Testing
Framework mappings
- CSA AICM (AIS-08)
- NIST AI RMF (MEASURE 2.5)
- EU AI Act (Art. 9(4))
- ISO 42001 (Cl. 8.2)
- 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 Objective & Policy Constraints
Version 1.0