Policy decisions

Every governed action passes a decision point before its side effect: the gateway for models and connector tools, the egress proxy for external hosts, the control plane for delegation, the runtime for approvals. Each decision is recorded once, and the Console lists them under Policies → Activity.

At a glance

• A decision record names the subject, the action, the resource, the verdict, and the policy or ceiling that decided it.
• Verdicts are allow, deny, or require-approval. An approval that was asked for is a decision; the person’s answer is a second record.
• A verdict is not an outcome. Each record also carries the enforcement outcome (allow, would-deny, deny, configuration-deny, error-open) and the posture it was decided under (shadow or enforce). A deny recorded as would-deny under shadow stopped nothing: the Console reads it as “Would have blocked · the request ran anyway”.
• A decision that could not be made, for example because facts were missing, is recorded as such rather than silently allowed.

Where decisions are made

Action	Decided at	Typical refusal
Model call	The LLM gateway	Model outside permitted_models or tenant policy
Connector tool call	The connector gateway	Tool outside the declared allowlist, connection not ready, current grant revoked
External connection	The egress proxy	Host outside network.egress or the tenant ceiling
Delegation	The control plane	No grant, or scope outside both ceilings
Approval-required tool	The runtime	Waits for a person; the answer is the decision

Read a decision

Open Policies → Activity in the Console, or open the Decisions tab of Assurance. Each record shows the verdict, the reason, and the identifiers of the policy or ceiling behind it, plus the run and session it belongs to. A refusal in a run’s event stream and its decision record share the run id.

From a refusal to its cause

1. Read the decision’s reason and the control it names.
2. If it names the version’s own contract, the fix is a new version: widen permitted_models, network.egress, or the connector allowlist, and deploy.
3. If it names a tenant ceiling or tenant policy, the fix is administrative: the ceiling must change before any version can pass.
4. If it is an approval, nothing is wrong: a person must answer. See Approval-required actions.

Do not “fix” a transient platform error by widening a ceiling; a policy denial and an infrastructure failure are different records.

Where to go next

• Policy, approvals, and evidence: the ceilings in one map.
• Read the audit trail