AI Control Library / CF-11: Objective & Policy Constraints
Designation: Core | Control types represented: Operational and Technical
Control requirement
Limit AI requests, execution, tool activity and resource consumption according to approved budgets and consequences. Enforce relevant aggregate limits across identities, retries and delegated tasks, with controlled exceptions.
Why this matters
Per-request limits may leave a system able to loop, spawn work or repeatedly trigger expensive actions. Resource control needs to reflect the complete workflow and cumulative effects.
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
Inference, tokens, compute, memory, storage, tool calls, external spending and task duration where material to safe operation.
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 service owner sets budgets with operations and risk input; platform and tool owners enforce them.
Implementation guidance
- Define limits and aggregation boundaries by user, tenant, task or service, tying them to impact and operational needs.
- Enforce quotas and concurrency or duration controls outside the model, including delegated work and retry behavior.
- Define safe exhaustion, escalation and temporary increase authority, preventing uncontrolled fallback or repeated action.
- Test burst, loop, parallel and partial-failure cases, monitoring both resource use and resulting service quality.
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 |
|---|---|
| Create a controlled repeated-call workload | Aggregate limits prevent excessive consumption. |
| Delegate or parallelize work | The parent budget remains effective where required. |
| Exhaust a budget | The task stops or follows its approved restricted path without bypassing the limit. |
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
- Resource and action budgets
- Quota and aggregation configuration
- Stress and loop tests
- Exceptions and operating reviews
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 runaway activity and notify operations and the service owner. Reconcile cost and external effects before granting additional resources or restarting tasks.
Example in practice
Hypothetical example: An agent repeatedly retries a failing API. A shared task budget limits calls across workers and triggers review instead of allowing each worker its own unrestricted retry allowance.
Related controls
- CF14-006: Autonomous Resource Acquisition Prevention
- CF09-009: AI Model Failure & Infrastructure Monitoring
- CF07-007: AI Autonomy Level Constraints
Framework mappings
- CSA AICM
- NIST AI RMF (GOVERN 5.1)
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