Policies
Org-wide rules layered over every mandate. Each policy matches on a set of conditions and contributes an effect with a reason shown in the decision trail. The most restrictive outcome across all checks wins.
Match conditions
A policy can match on any combination of:
- action type, resource, agent tags, environment
- value range (min / max)
- risk band (min / max behavioral score)
- time window (hours UTC,
[start, end)— end may be 24) and days of week - metadata predicates (
key=globover the action's metadata)
Lower priority numbers evaluate first; the engine still folds to the most-restrictive effect overall.
Staged rollout: draft → shadow → active
Set a policy's rollout to preview it safely: draft is saved but not evaluated; shadow is evaluated and logged but non-enforcing (so you can see what it would do);active enforces on live traffic. Stage a deny/require-approval policy in shadow before it bites.
What-if simulation
From the policy editor, Simulate vs recent actions diffs a candidate policy against your current policies over recent traffic and reports how many decisions would change — the blast radius, before you save.
Version history & rollback
Every edit is versioned. Open a policy to see its version history and roll back to a prior revision (which itself creates a new version, so the trail stays complete).
Examples
- Block sanctioned vendors — match
resource: vendor:sanctioned-*→ deny - Hold large refunds — match
payment.refund, min value €500 → require approval - Off-hours production writes — match
data.writeondb:prod-*, hours 0–7 → require approval