Policies

Policy creator

Build a DefenseClaw policy section by section. Live OPA-WASM evaluation in the browser, copy-pasteable YAML on the way out.

Two ways in: step through a six-screen wizard and we'll assemble a complete policy (Quick Start), or edit the policy surfaces supported by the creator section by section (Playground). Both tabs share the same draft policy, so you can interview-then-tweak. The browser preview evaluates the OPA/Rego policy domains; the creator separately inventories deterministic detector coverage that is compiled into DefenseClaw.

No data leaves the page

The wizard ships compiled WebAssembly copies of the bundled Rego (admission, guardrail, firewall, audit, skill_actions). OPA evaluation happens entirely in your browser — your draft policy and the inputs you test against are never uploaded. Saved progress lives in localStorage. The Live Test does not execute ActionFacts parsers, CEL, regex, YARA, or bounded tool-call chains.

What posture should we start from?

Picks a base preset. You'll layer your block / allow choices on top.

Step 1 of 6

Current creator coverage

The creator loads its editable rule catalog from the same generated assets as the repository profiles. In this snapshot, Balanced/default exposes 188 declared rules (184 enabled), Permissive 188 (180 enabled), and Strict 187 (all enabled). Each profile carries 81 CEL declarations and 61 tool_call_only rules. The recipe picker exposes every generated rule family, and Quick Start rule and correlator IDs are checked against all three profiles in the Policy Creator test suite.

The Deterministic coverage Playground section is intentionally an inventory rather than an editor. It shows six ActionFacts capability groups, 18 fixed bounded chains (eight enforcement-capable and ten alert-only), five alert-only MCP-description YARA signatures, five selectable high-assurance packs, and the staged SSH integrity contract. Selectable packs can be layered directly into the custom rule pack; the generated asset is checked against the canonical repository YAML. For the proof model and the complete rule inventory, see Deterministic detection reference.

Power features

These small affordances exist on top of the two main tabs to shorten the most common loops:

FeatureWhereWhat it does
Live preview drawerQuick Start (every step except Review)Floating bottom-right pane that evaluates the in-progress admission, guardrail, firewall, audit, or skill-actions Rego policy against canned scenarios.
Custom test inputLive Test pane (in the drawer or on the Review step)Switch the OPA/Rego input source from "canned scenario" to "custom input" and paste your own JSON. Per-domain drafts persist to localStorage. Re-evaluates 250 ms after you stop typing.
⌘K / Ctrl-K palettePlaygroundFuzzy-search every section and knob ("hilt severity", "splunk hec token", "block threshold"). Selecting a result expands the matching section, scrolls to it, and flashes a brief outline.
Syntax-highlighted Rego editorPlayground → Custom RegoZero-dependency editor: transparent textarea over a tokenized overlay. Tab inserts 2 spaces, Shift-Tab dedents. Highlighting is presentation-only — opa check runs on your host at install time.
Copy share linkQuick Start Review + Playground ReviewEncodes the current policy into the URL fragment as gzip + base64url, copies the link to your clipboard. The fragment never leaves your browser as a network request, but the link itself contains the policy — share it like you would the YAML.

When someone opens a share link, the page decodes the fragment, prompts before replacing any in-progress draft, and silently strips the hash. If the payload fails any check (wrong version, larger than 1 MB after decompression, doesn't look like a policy, malformed gzip) the page shows a yellow banner explaining which check failed instead of clobbering your draft.

Quick Start vs. Playground

When you click Open in Playground → at the bottom of the Quick Start, your answers carry over and every Playground section is pre-filled. A blue banner at the top of the Playground reminds you where the state came from, and a Restart Quick Start button lets you start the interview again without losing your in-flight Playground edits.

How the Quick Start works

Step 1 — Posture. Picks the base preset (Permissive / Balanced / Strict). The Balanced default is the sensible production starting point; Permissive is for shadow-mode evaluation (only CRITICAL findings block installs); Strict is for regulated workloads where false-positive cost is acceptable.

Step 2 — What to block. Ten cards grouped under five headers (Data leaks, Network exfiltration, Code execution, LLM-layer attacks, Multi-step attack patterns). Multi-select. Each card lists the bundled rule IDs, firewall destinations, guardrail patterns, or editable session-correlator patterns it enables — deep-link to the regex cookbook to see the patterns it ships.

Step 3 — What to allow. Multi-select cards for the most common alert-volume reducers: cosmetic shell commands (git status, ls, pwd), first-party plugins, internal domains, known dev tools. Free-form text inputs let you add your own globs and domains. Deep-links to the suppression cookbook explain when each layer is right.

Step 4 — Response. Pick how aggressive enforcement should be: log silently, alert on HIGH+, ask first (HILT) on MEDIUM+, or hard block on MEDIUM+. Drives the guardrail thresholds, the HILT configuration, and the skill_actions matrix.

Step 5 — Sinks. Toggle local audit log, stdout, Splunk HEC, Slack webhook, or a generic webhook. Secrets are referenced by env var name only — never typed inline.

Step 6 — Review. Inline policy summary plus the OPA/Rego-only Live Test pane: pick a canned scenario (a CRITICAL secret in a skill, an MCP install with a sketchy domain, a quarantined plugin), see the verdict (blocked / allowed / quarantined), and tweak earlier steps until it matches intent. Then Open in Playground → hands you off to the full editor with everything pre-filled. The Review section there renders every YAML file plus data.json; copy them into ~/.defenseclaw/policies/ (or run the bundled install script) and activate with:

defenseclaw policy activate my-policy

What lives behind each Playground section

SectionBacked by
Basicsname, description, basedOn keys in the top-level policy YAML.
Severity matrixskill_actions.<sev> (runtime/file/install) plus per-scanner scanner_overrides.<scanner>.<sev>.
Admissionadmission.scan_on_install, admission.allow_list_bypass_scan, and first_party_allow_list entries.
Guardrailguardrail.block_threshold / alert_threshold, guardrail.hilt, guardrail.patterns, severity_mappings, Cisco trust level.
Rule packPer-file regex rules and CEL candidate expressions, including tool_call_only scoping (policies/guardrail/<pack>/rules/<filename>.yaml).
SuppressionsThe three layers: pre_judge_strips, finding_suppressions, tool_suppressions.
Sensitive toolssensitive_tools array — per-tool result inspection and judge-result toggles.
LLM judgesjudges.<name> (pii / injection / tool-injection / exfil) — system prompts and category mappings.
Session correlator (Layer 5)The two editable post-event correlator patterns bundled in correlation-patterns.yaml. These are distinct from the 18 fixed ActionFacts chains.
Deterministic coverageRead-only inventory of code-owned ActionFacts capabilities, the 18 bounded tool-call chains, and the five MCP-description YARA signatures; also applies selectable high-assurance rule packs to the custom pack.
Firewallfirewall.default_action, blocked_destinations, allowed_domains, allowed_ports.
Webhookswebhooks array — Slack / Webex / PagerDuty / generic, signed via env-var secrets.
Watch (rescan)watch.rescan_enabled, watch.rescan_interval_min.
Enforcementenforcement.max_enforcement_delay_seconds.
Auditaudit.log_all_actions, audit.log_scan_results, audit.retention_days.
Scanner profilesscanners.<scanner> profile selection (codeguard / plugin-scanner / skill-scanner).
Cisco AI Defense (optional · enterprise)cisco_ai_defense.enabled / endpoint / api_key_env / scan_hook_surface — the optional remote lane read by internal/config.
Custom RegoPer-snippet package defenseclaw.custom.<name> modules emitted into policies/rego/custom-<name>.rego.
Review & exportRenders every YAML file the engine needs + policies/rego/data.json + a copy-pasteable bash install script.

Limits to know about

  • Live Test is OPA/Rego-only. It evaluates the five bundled WASM policy domains: admission, guardrail, firewall, audit, and skill actions. It does not run the Go ActionFacts parser, compile CEL, execute RE2 rules, scan MCP descriptions with YARA, or replay bounded chains. Use the exported policy on a DefenseClaw host and run the repository test/benchmark harness for those lanes.
  • Fixed deterministic detectors are read-only. The 18 bounded chains and five YARA signatures shown by the creator are repository-owned runtime/scanner capabilities, not arbitrary policy programs. The creator can display their coverage and the active posture, but it does not rewrite their implementations. The two Layer-5 session correlator patterns remain separately editable.
  • CEL does not grant block authority. A custom CEL expression is a bounded detection selector evaluated at an authenticated tool-call boundary. A match cannot make itself enforcement-safe. Blocking still requires an eligible synchronous connector, the active profile's disposition, and a complete code-owned proof pinned to the same rule ID. Unsupported, ambiguous, conditional, or over-budget facts remain detection-only. Browser validation is preflight only; final CEL compilation and admission happen on the DefenseClaw host.
  • Rego compilation is offline. The wizard exports data.json (read by the bundled Rego at runtime) and any custom snippets you author. It does not recompile the shipped Rego — for that you still need opa build on the host. The lint in the Custom Rego section catches the obvious shape mistakes (package header, balanced braces, := vs =).
  • Regex parity. The browser uses V8 regex; the engine uses Go's regexp (RE2). The validator flags RE2 incompatibilities (lookaround, backrefs) inline so you catch them before exporting. Inline flag groups ((?i), (?ims)) are translated to JS flags transparently so bundled rules don't false-error.
  • Pre-existing rule packs. When you switch the base preset, the wizard reloads the bundled rule pack so you can see (and edit) the patterns that ship with that pack.