Defaults

DefenseClaw ships with opinionated defaults that are immediately useful without tuning, and stay out of your way until you opt into stricter behaviour. This page documents what actually ships — grounded in the policy YAMLs in policies/, the schema in internal/config/config.go, and what defenseclaw setup guardrail actually writes.

The two layers you can swap

DefenseClaw separates admission policy from runtime guardrail rules. They ship as matching triples but are independent knobs.

Both layers ship in three named profiles — default, strict, permissive — and you flip them independently:

defenseclaw policy activate default                                # OPA layer
defenseclaw setup guardrail --rule-pack default                    # Guardrail layer

OPA admission policy — what each profile ships

The OPA policy file (policies/<name>.yaml) drives admission decisions: what happens to a finding by severity, whether the allow-list lets first-party assets bypass scanning, and what threshold a Cisco AI Defense verdict has to clear before it blocks.

Severity ranks are the rego convention from policies/rego/guardrail.rego: 1 = LOW, 2 = MEDIUM, 3 = HIGH, 4 = CRITICAL. cisco_trust_level: advisory means even Cisco AI Defense's own verdicts are surfaced but never escalated to a block.

The columns are deliberately conservative. We'd rather you opt into stricter behaviour than have an upgrade silently start blocking your traffic.

Guardrail rule pack — what each profile ships

The rule pack directory (policies/guardrail/<name>/) holds the regex YAMLs, judge prompts, sensitive-tool definitions, and suppressions the in-flight scanner consumes.

All three packs share the same severity rubric and the same signal_strength output schema — only the per-category thresholds and suppression scope differ between packs. Switching the rule pack does not enable the LLM judge — that's a separate guardrail.judge.enabled toggle in your operator config (default: false). Flipping the rule pack only changes which prompt YAMLs the judge will run if you've enabled it.

What setup guardrail actually writes

After defenseclaw init, an explicit defenseclaw setup guardrail --connector openclaw --mode action --rule-pack default --non-interactive produces the relevant configuration below (unrelated generated fields omitted):

claw:
  mode: openclaw

guardrail:
  enabled: true
  mode: action
  rule_pack_dir: /Users/<you>/.defenseclaw/policies/guardrail/default
  hook_fail_mode: closed
  judge:
    enabled: false                    # opt in via --judge-model
  hilt:
    enabled: false                    # opt in via --human-approval
    min_severity: HIGH

observability: {}                       # all signals collected; local SQLite logs unredacted
webhooks: []                           # add via `defenseclaw setup webhook add ...`

claude_code:
  enabled: false                       # toggled when you pick claude-code in setup guardrail
codex:
  enabled: false

Three things to notice that contradict folklore:

• The LLM judge is OFF by default. It only flips on if you pass --judge-model to setup guardrail or answer "yes" to the interactive judge prompt. The schema default is guardrail.judge.enabled = false in internal/config/config.go. Keeping it off keeps cost predictable; flip it on once you have a DEFENSECLAW_LLM_KEY configured.
• HILT is OFF by default. The shipped severity floor is HIGH, but enabled: false means it never prompts. --human-approval flips it on; --hilt-min-severity adjusts the floor.
• The built-in local store still writes. observability: {} means no optional destination, not no telemetry. V8 collects every registered signal and mandatory SQLite stores every collected log unredacted. Add a kind: jsonl destination if a file stream is required; add remote destinations via setup splunk or setup local-observability.
• Fresh v8 telemetry is unredacted. An enabled destination with omitted policy sends every capability and bucket under profile none. Configure sensitive, content, strict, or a custom profile before exporting into a less-trusted boundary.

Tuning by risk tolerance

You usually don't need a custom policy or rule pack — just a few knob changes.

"I'm in pilot, just observe"

defenseclaw policy activate permissive
defenseclaw setup guardrail \
  --connector openclaw \
  --mode observe \
  --rule-pack permissive \
  --restart \
  --non-interactive

Observe mode prevents enforcement even though the permissive policy's action-mode block threshold remains CRITICAL. Everything still flows to mandatory SQLite and any matching configured destinations so you can review what would have happened. Recommended first week of any rollout.

"Move fast, stop only the obvious harm"

defenseclaw policy activate default
defenseclaw setup guardrail \
  --connector openclaw \
  --mode action \
  --rule-pack default \
  --human-approval \
  --hilt-min-severity high \
  --restart \
  --non-interactive

Default rules; CRITICAL blocks and HIGH can prompt on OpenClaw's native ask surface. Most engineering teams in the early/middle phase land here.

"Regulated workload, lock it down"

defenseclaw policy activate strict
defenseclaw setup guardrail \
  --connector openclaw \
  --mode action \
  --rule-pack strict \
  --detection-strategy regex_judge \
  --judge-model openai/gpt-4o-mini \
  --restart \
  --non-interactive

Strict policy (block ≥ MEDIUM, no allow-list bypass), strict rule pack (stricter profile variants and minimal suppressions), and the LLM judge enabled. Because the strict block threshold runs before HITL, MEDIUM-and-higher findings block rather than prompt. Combine this with the bundled OpenShell sandbox profile and a reviewed first-party allow-list.

"I trust the scanner, raise its bar specifically"

The asset-class behavior is independent of the rule pack. Edit the active policy YAML directly:

```yaml title="policies/default.yaml override (apply with defenseclaw policy activate default)" scanner_overrides: mcp: medium: # was none/enable/none file: quarantine runtime: disable install: block

Then re-activate so OPA picks up the change:

```bash
defenseclaw policy activate default

Defaults defenseclaw init does not ask about

init does not prompt for the following lower-level defaults. Use the documented setup/guardrail command when it exposes the knob; otherwise edit ~/.defenseclaw/config.yaml and validate the result.

defenseclaw setup llm --max-retries, defenseclaw setup guardrail --detection-strategy, and defenseclaw guardrail fail-mode provide supported CLI paths for three of these controls. Run defenseclaw config validate after any direct edit.

Per-connector overrides (guardrail.connectors)

When you run more than one hook connector from a single gateway, override guardrail policy per connector under guardrail.connectors.<name> in ~/.defenseclaw/config.yaml. Every field is optional and inherits the global guardrail.* value when unset, so a connector block only carries what differs:

guardrail:
  mode: action                   # global default
  hook_fail_mode: closed

  connectors:
    claudecode:
      mode: action               # enforce for Claude Code
    codex:
      mode: observe              # softer for Codex than for Claude Code
      hook_fail_mode: open         # explicit softer override for Codex

claw.mode flips to multi automatically once more than one connector is active. Manage these blocks with defenseclaw setup <connector> (choosing Add) and the defenseclaw guardrail ... --connector X command group — see Setup → Multi-connector and Reference → Configuration. The OPA admission policy is still global — there's no per-connector policy override surface yet.

claude_code:
  enabled: true
  mode: action
  fail_mode: open                # LEGACY hint, NOT consumed by hooks; see Reference → Fail modes

Inspect the active defaults

defenseclaw config show                  # rendered ~/.defenseclaw/config.yaml (secrets masked)
defenseclaw policy list                  # all policies on disk + which is active
defenseclaw policy show default          # normalized summary of one named policy

For configuration v8, config show renders the canonical effective observability view by default; use --source for the masked source document, or --effective --provenance for explicit compiler annotations. V8 rejects --reveal; neither source nor effective output resolves secret values.

policy show <name> prints a normalized summary of the named file (default, strict, permissive, or any custom policies/<name>.yaml you've added). It does not dump the source YAML or individual guardrail rules. To find a rule by id, search the configured rule-pack directory directly:

grep -rn "rule_id_you_care_about" "$(awk '/rule_pack_dir/ {print $2}' ~/.defenseclaw/config.yaml)"

Reset to defaults

There's no --reset flag. Two real paths exist:

Soft reset (most common) — just re-run setup with the defaults you want. setup guardrail overwrites the relevant guardrail.* keys idempotently:

defenseclaw setup guardrail --rule-pack default --no-human-approval
defenseclaw policy activate default

Reset user state — first make your own private backup if you need one, then use the destructive reset command. It deletes resettable state; it does not create a rollback archive. The managed runtime and installed plugin are retained so quickstart can reinstall. This shell example is for macOS/Linux source installations; native Windows lifecycle is owned by the authenticated Setup package.

umask 077
cp -a "$HOME/.defenseclaw" "$HOME/.defenseclaw.before-reset"
defenseclaw reset
defenseclaw quickstart

See also

• Policies — the layered architecture (regex → judge → suppressions → OPA admission)
• Setup Guardrail — the CLI that consumes these defaults
• HITL — what guardrail.hilt.enabled and min_severity actually change for the operator
• Reference → Fail modes — the three "fail open vs closed" knobs disambiguated
• Reference → Configuration — every key surfaced here, with type and default