The policy gate

Concept

The policy gate

The gate sits between every agent turn and every tool it wants to invoke. It reads the active policy bundle, the tool argument, the delegation chain, and the current budget, then returns allow, ask, or deny — and appends an AVAR receipt either way.

Latency

Policy decisions are measured in microseconds, with predictable tail latency across both quiet and mutating workloads:

  • Steady state (warm cache, no rule changes): p99 ≈ 1µs, p999 < 15µs.
  • Continuous policy updates (rules changing under load): p99 ≈ 50µs, p999 well under 100µs.
  • Concurrent workers: p99 stays in the same envelope; no lock contention on the hot path.

The gate is a pure function over local state — no network call, no batching — so it stays invisible next to a single LLM token (10–100ms). The bench harness lives at src/lib/policy/__bench__/gate.bench.ts and re-runs in CI on every push against a p99 ≤ 500µs / p999 ≤ 5ms budget.

We don't make superlative claims here — there's no public, apples-to-apples benchmark across OPA, Cedar, Cerbos, and commercial LLM guardrails. What we claim is what we measure: the numbers above, in CI, with the harness open in this repo.

Sources of a decision

  • The effective policy — every applicable source 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 allow / ask / deny from Permissions
  • 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, and the receipt records which one. DENY means the gate refused the call locally — nothing left the device. BLOCK, stamped enforced_at: upstream, means the gate allowed the call out and the remote service refused it — a token without write access returning 403, for example.

Both are recorded as distinct verdicts 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.