The policy gate

Concept

The policy gate

The gate sits between an agent and the tools it invokes through a governed path. For each governed tool call it reads the active policy bundle, the tool argument, the delegation chain, and the current budget, then returns a gate outcome — for example ALLOW, DENY, or STEP_UP when an approval is required — and records that outcome on the receipt.

A gate outcome for a tool call is recorded within the canonical Decision for the proposed Consequence. Authority, the Attempt, its Effect, and the eventual outcome are recorded separately; see the glossary. Calls that do not pass through a governed path are not evaluated here; see coverage and status.

Evaluation path

Evaluation runs over local state, with no network call on the evaluation path. Performance characteristics depend on policy size, workload, and hardware; this page does not publish latency figures.

Inputs to a gate outcome

  • The effective policy — the applicable sources resolved into one artifact with one digest, each surviving clause naming the source that contributed it
  • The resolved delegation chain, admitted before the action itself is evaluated
  • Per-tool permission scopes
  • The capability resolved for the origin that owns the action
  • Rate-limit windows and daily spend ceiling
  • Kill-switch state

Denials come with a stable error code — see /docs/errors — and the "Explain" popover surfaces the exact reason plus the offending rule.

Where a refusal was enforced

A refusal can happen in two places. DENY means the gate refused the call locally — nothing left the device. In the in-app assistant, when the gate allowed the call out and the remote service refused it with an authorization error — a token without write access returning 403, for example — Aarmos records a separate BLOCK decision with source upstream.

Both are recorded as distinct gate outcomes on purpose. A receipt that showed only ALLOW because the vendor happened to say no would misstate who decided. If you see upstream blocks for actions you never meant to permit, tighten the capability grant so the gate — not the vendor — is what enforces your policy.