AI Control Library / CF-11: Objective & Policy Constraints
Designation: Core | Control types represented: Operational and Technical
Control requirement
Translate approved prohibited AI uses into enforceable deployment, access and action restrictions. Test relevant bypass and alternate-path scenarios, and require reviewed authorization for material capability changes.
Why this matters
A prohibited-use paragraph cannot prevent an application from exposing the very feature it forbids. Enforcement needs to address capabilities and workflows rather than depend only on model refusal.
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
AI capabilities prohibited by organizational policy or applicable external requirements across user, administrator, tool and integration paths.
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 policy and business owners define restrictions; engineering and security implement controls with legal input where applicable.
Implementation guidance
- Identify prohibited uses and concrete enabling capabilities, data and action paths.
- Select effective restrictions such as unavailable functions, scoped permissions, approved data sources and deployment gates.
- Define detection and escalation for suspected misuse, keeping critical enforcement outside the model.
- Test direct, indirect, delegated and administrative paths, reviewing changes that could re-enable prohibited capability.
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 |
|---|---|
| Attempt a prohibited function | The relevant system boundary denies or prevents it. |
| Use an alternate interface or delegated worker | The same restriction remains effective. |
| Change a capability setting | Required review precedes the expanded use. |
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
- Prohibited-use and capability map
- Enforcement configuration
- Bypass and change tests
- Misuse and response 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
Contain enabled prohibited functions and notify policy, security and legal owners as appropriate. Assess actual use and restore only permitted capability.
Example in practice
Hypothetical example: An assistant is not allowed to modify customer balances. The application omits write access and blocks alternate tool routes instead of relying solely on an instruction not to do so.
Related controls
- CF11-006: EU AI Act Prohibited Practice Controls
- CF11-007: AI System Scope Restriction
- CF07-007: AI Autonomy Level Constraints
Framework mappings
- CSA AICM
- NIST AI RMF (MAP 1.1)
- EU AI Act (Art. 5, Art. 9)
- ISO 42001 (Cl. 8.2)
- 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