Skip to main content
The Policies page lists every policy in your org as a card. Each card shows the policy name, slug, a Recently active on chip strip (agents that hit this policy in the last 30 days), an “Active” or “Draft” status pill, and a 24h activity sparkline. The chip strip is observational — it shows actual traffic, not the prescriptive scope. The prescriptive list (the set of agents the policy currently enforces against) lives on the detail page.

​
Authoring

Click New policy to open the YAML editor. The editor:
  • Validates against the Policy schema on every keystroke. Errors are highlighted inline.
  • Autocompletes condition fields, operators, and values for known tools.
  • Shows a live diff against the currently-published version on the right.
The form has three required sections: name, slug, and Applied to agents (a multi-select picker over the org’s enrolled agents). You can save a draft with zero agents selected, but you can’t publish until at least one is picked — empty scope means the policy enforces against nobody. When you click Save, a new version is created with status draft.

​
Templates

Click Browse templates for a starter library — common patterns like:
  • Block destructive filesystem operations
  • Block all network egress except an allowlist
  • Block calls carrying high-severity DLP detections
  • Limit tool calls per session
  • Production-only deny rules
Pick one, customize, dry-run, publish.

​
Dry-run

Before publishing, click Dry-run in the editor. Rubric replays the last N (default 1000) audit events through the candidate policy and shows you:
  • Decisions — how many events would have been allowed vs denied.
  • Most affected agents — which agents are most often denied by this rule.
  • Diff vs live — for an existing policy, which audit events change decision compared to the current version.
  • Filters — narrow the replay to a specific agent or environment.
Always dry-run a deny rule before shipping it. The audit replay catches over-broad matchers cheaply.

​
Publishing

Click Publish to make a draft version active. Effects:
  1. The previous active version becomes archived.
  2. The new version becomes active.
  3. The bundle version increments.
  4. Rubric fans out fresh per-agent bundles for every agent in the org (each agent’s bundle is the intersection of the new active policies with that agent’s scope membership).
  5. SDKs see the new bundle on their next 30-second poll.
The publish button is disabled when no agents are in scope. Add at least one agent on the Applied to agents card before publishing. You can roll back by editing the policy and choosing Publish previous version from the version list.

​
Detail page: Applied to agents

The detail page has a dedicated Applied to agents card above the version list:
  • Shows the currently-scoped agents as chips (agent name fallback agent id).
  • Banner reads “Inert — no agents assigned. Add at least one to enforce.” when the policy is published but scope is empty.
  • Click Edit to open the agent picker dialog. Saving writes one audit row per add/remove and fans out fresh bundles to the affected agents only — no version bump, no SDK restart, takes effect on the next ≤30 s pull.
Scope is independent of policy versions. Editing scope doesn’t produce a new draft; it’s operational metadata.

​
Status pill

Each policy card has a pill in the bottom-right:
  • Active (green) — the policy has a published version and is in the bundle.
  • Draft (muted) — only draft versions exist; not in the bundle.