Evaluate a policy envelope.
Turn a valid authority grant into an action-specific decision using target, purpose, context and operating limits.
- Input
- principal + task + action
- Check
- authority + policy + context
- Output
- decision + evidence
- principal
- Which agent and workload?
- authority
- Which originating task and grant?
- operation
- Which consequential effect?
- boundary
- Where can it be stopped?
Specify the behavior before choosing an interface.
Dimensions to evaluate
An evaluable policy can consider operation, tool, system, data classification, amount, geography, time, counterparty, task purpose and operating state. Approval requirements may be conditional: a low-value action can be automatic while a higher-value or unfamiliar target escalates.
These dimensions explain the public policy model while the private representation remains undisclosed. The control objective is to make the decision repeatable and explainable at the execution boundary.
- Action and target
- Tool and system
- Data and value
- Geography and counterparty
- Time and task purpose
- Operating state and approval
Grant first, then policy
A policy should never create authority that a grant does not contain. Evaluate the grant chain for validity, then intersect it with applicable policy. A principal delegated read-only access cannot perform a write even when a policy rule would allow that write for another role.
Conflicting constraints should not be silently resolved in favor of broader action. The integration needs a clear precedence model and an explicit fallback when required context is missing.
Version and evidence
Policy changes over time. Decision evidence should identify the applicable policy version and relevant context so a later reviewer can reconstruct why the request was allowed or denied. Data minimization still matters: record the facts required for explanation without copying entire sensitive payloads.
Policy input quality
A rule can only be as precise as its inputs. If a tool request omits the counterparty, asset, amount or operating state needed for a high-risk decision, the system should not quietly treat the condition as satisfied. The integration should define required inputs and how they are authenticated or validated.
Policy evaluation also needs a stable view of which rule applied. When conditions change between enqueue and execution, the decision should use the version and context appropriate to the action time, and record that choice for later review.
Integration Review