Policy / rules endpoints

The cloud is the source of truth for policy — read and write. Collectors pull the published policy and enforce it locally. All paths are tenant-scoped and under /api.

GET /policy

The currently active policy bundle, with per-rule hit counts in the last window:

{
  "name":           "default",
  "version":        1,
  "default_action": "allow",
  "rules": [
    {
      "name":        "redact_secrets_on_egress",
      "action":      "redact",
      "match":       { "contains_secret": true },
      "reason":      "credential detected in outbound payload — masking before send",
      "hit_count":   1842
    }
  ],
  "lints": [
    {
      "rule":     "block_unknown_hosts",
      "code":     "deny_no_direction",
      "severity": "warning",
      "message":  "This deny matches by destination/identity and has no direction, so it also runs on the RESPONSE leg…"
    }
  ]
}

lints lists rules that behave differently from how the ordered list reads — the same warnings the Policy Rules page shows. code is one of deny_no_direction (warning), shadowed_dead (warning — a catch-all above already decides every leg this rule covers), or shadowed_partial (info — it only fires on the leg the catch-all above doesn't cover). Empty when there's nothing to flag.

Writes

• PUT /policy — replace the whole policy bundle.
• POST /policy/rules — add a rule.
• PUT /policy/rules/{name} — update a rule.
• DELETE /policy/rules/{name} — remove a rule.
• POST /policy/rules/reorder — reorder by name.

The Policy Rules and rule-editor pages in the console call these. Saved changes are pulled by collectors on their next cycle.