Managing policy

Policy is the heart of Kilasec: an ordered list of rules that decides what happens to every AI request. This page is how to write, order, test, and ship it. For the exact matching semantics, see Policy semantics; for rule-writing detail, Writing policy rules.

The model: first match wins

Rules are evaluated top to bottom, and the first one that matches decides the verdict. If nothing matches, the policy's default action applies. Order matters — a broad allow above a narrow deny means the deny never fires. Put specific rules above general ones.

Each rule produces one verdict:

• allow — forward unchanged.
• redact — mask matched secrets/PII, then forward.
• deny — stop the request; it never reaches the provider.
• require_approval — hold for a human decision (see Approvals).
• log — allow, but record (observe-only).

What a rule can match on

• Agent — the calling tool/SDK (openai-python, claude-cli, browser, …).
• Destination — host, tool, or model (api.openai.com, a specific model).
• User / AD group — when identity is wired: group:engineering.
• Time window — hours/days, e.g. block off-hours.
• Content — a scan of the request body (secrets, PII, custom arg_regex).
• Cost — daily_cost_over a dollar threshold for an agent.
• Rate — calls_per_minute_over a request-rate threshold for an agent (60s sliding window). The runaway-loop gate: pair with deny for a hard rate limit, or require_approval to hold a hammering agent for a human. Example:

- name: rate_limit_eval_loops
  match:
    calls_per_minute_over: 30
    destination_is_ai_provider: true
  action: deny
  reason: "agent exceeded 30 model calls/min — likely a runaway loop"

Scope vs policy

Two different controls, easy to conflate:

• Scope decides what gets decrypted and inspected at all — the list of AI destinations the collector intercepts. Everything outside scope bypasses the collector entirely.
• Policy decides what happens to the traffic that is inspected.

Widen scope to see more; write policy to act on it. Manage scope on the Scope page.

Test before you ship: the Simulator

Before applying a rule change, run it through the Simulator. It replays recent real traffic against your candidate policy and shows which decisions would flip — so you see that a new deny would have blocked 3 legitimate calls before it blocks them in production. Treat this as your change-review step.

Applying changes

Edit rules on Policy Rules (add/edit/delete/reorder) or the full-YAML editor. Saved changes are versioned in the cloud and pulled by collectors on their next cycle. To apply immediately across the fleet, use Apply now — it restarts collectors to re-read config. Every change is recorded in the Audit Log.

A safe rollout pattern

1. Start permissive — default allow/log, redaction on for obvious secret patterns. Don't block what you haven't observed.
2. Observe — watch Live Traffic, Agents, Incidents for a week to learn the real providers/agents/users.
3. Add targeted rules — one risk at a time (block a shadow provider, require approval over a spend threshold, redact PII to a support agent), simulating each.
4. Tighten the default last — only move the default from allow to deny once your allow rules cover legitimate traffic, or you'll block the business.

A note on rule regexes

Custom arg_regex patterns are yours to author. A malformed regex is a policy bug — test rules that use them in the Simulator, and prefer the built-in secret/PII matchers where they cover your case.