AI Control Library / CF-11: Objective & Policy Constraints
Designation: Core | Control types represented: Operational and Technical
Control requirement
Enforce the approved AI task and access scope across tools, data, environments and delegation, with safe handling of requests that exceed it. Prevent the system from extending its own authority through planning or generated instructions.
Why this matters
A well-defined objective is insufficient when the deployed identity can do much more. Scope restriction turns the approved purpose into boundaries at the points where effects occur.
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 workflows with access to organizational data or actions, including autonomous and multi-agent systems.
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 system owner approves scope; identity, tool and platform owners enforce it.
Implementation guidance
- Map approved tasks to specific data, operations, identities and deployment contexts.
- Apply least authority and independent checks at retrieval and execution boundaries, including tenant and environment separation.
- Propagate scope limits to delegated work and require reviewed escalation for out-of-scope needs.
- Test direct, indirect and combined requests, correcting overly broad permissions and unsafe fallback behavior.
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 |
|---|---|
| Request an out-of-scope resource | The underlying boundary denies access or action. |
| Delegate a task | The child cannot acquire broader scope without authorization. |
| Trigger an unavailable approved tool | Fallback does not silently use an unrestricted alternative. |
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
- Scope-to-permission specification
- Enforcement and delegation configuration
- Boundary and fallback tests
- Scope-change decisions
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 scope escape and notify security and the system owner. Assess completed effects and narrow actual permissions before resuming affected activity.
Example in practice
Hypothetical example: A research agent can read approved public sources but cannot access internal files. A returned webpage asking for local credentials does not change the independently enforced data scope.
Related controls
- CF11-001: AI System Objective & Scope Definition
- CF07-007: AI Autonomy Level Constraints
- CF14-003: Agentic Scope Containment
Framework mappings
- CSA AICM
- NIST AI RMF (MAP 1.1)
- EU AI Act (Art. 9(2))
- ISO 42001 (Cl. 8.2)
- MITRE ATLAS
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