AI Control Library / CF-11: Objective & Policy Constraints
Designation: Core | Control types represented: Operational and Technical
Control requirement
Validate and appropriately filter AI outputs before they are displayed, stored, executed or passed to downstream systems. Enforce destination-specific safety and authorization rather than treating generated content as trusted.
Why this matters
A response that looks reasonable can contain executable markup, unsafe parameters or unsupported instructions. Output controls must match how the next component consumes the result.
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
Generated text, code, queries, file paths, tool arguments and structured results used by AI applications.
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 consuming application owner defines contracts; engineering and security enforce handling at each relevant boundary.
Implementation guidance
- Map output consumers and consequences, defining required structure, permitted values, authorization and content rules.
- Use safe rendering, parameterized interfaces and appropriate validation for the destination; avoid direct execution of generated strings.
- Add content or evidence checks where necessary, with safe handling of invalid, partial or uncertain results.
- Test unsafe markup, invalid arguments, unsupported claims and alternate consumers, checking that retries cannot bypass validation.
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 |
|---|---|
| Pass a malicious-looking safe fixture to a consumer | It is encoded, rejected or constrained according to the destination. |
| Generate unauthorized tool arguments | Independent policy checks prevent execution. |
| Return incomplete output | The application follows its safe handling path rather than using unchecked partial values. |
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
- Output consumer and contract map
- Validation and safe-handling configuration
- Adversarial and regression tests
- Rejection and remediation 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 unsafe consumption and notify application and security owners. Reconcile executed effects and verify all relevant consumers before restoring the path.
Example in practice
Hypothetical example: A model generates a database query. The application uses an approved parameterized operation and scoped identity rather than sending the model’s raw string to an unrestricted execution interface.
Related controls
- CF12-011: AI Output Handling Security
- CF11-009: AI Output Format & Structure Enforcement
- CF08-007: AI Application Security Testing
Framework mappings
- CSA AICM (AIS-09)
- 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