Policy Guide

Policy Guide

The 12 Built-in Guards

Available Rulesets

Use clawdstrike_policy_show to inspect any ruleset.

How to Check Policies

Show active policy

Call clawdstrike_policy_show with no arguments to see the currently loaded policy, or pass a ruleset name to inspect a specific one.

Evaluate a hypothetical action

Call clawdstrike_policy_eval with an action_type and target to see which guards would fire and what the verdict would be, without actually executing the action.

Policy Inheritance

Policies support inheritance via the extends field:

• Built-in rulesets can be referenced by name (e.g., extends: strict)
• Local files can be referenced by path
• Remote URLs and git refs are supported
• Child policies override parent settings; guards merge by name

Design Philosophy: Fail-Closed

ClawdStrike follows a fail-closed design:

• Invalid policies are rejected at load time (not silently ignored)
• Errors during guard evaluation result in deny (not allow)
• Unknown action types are denied by default
• Missing configuration causes startup failure, not permissive fallback

This means if something goes wrong, the system errs on the side of security rather than availability.

What To Do When Too Strict

If the active policy is blocking legitimate actions, follow these steps to relax it safely:

1. Identify the blocking guard: Call clawdstrike_policy_eval with the denied action to see exactly which guard is blocking it.
2. Check if the action is expected: Verify the action is genuinely needed and not a misconfigured command or wrong path.
3. Try a less restrictive ruleset: If on strict, try default or ai-agent. Use clawdstrike_policy_show to compare what changes.
4. Create a custom override: Extend the current ruleset and override only the specific guard:

   version: "1.5.0"
   extends: strict
   guards:
     ForbiddenPathGuard:
       additional_allowed_paths:
         - "/path/that/was/blocked"
   

5. Add path-specific exceptions: For file guards, add paths to allowlists rather than disabling the guard entirely.
6. Disable a single guard as last resort: Set enabled: false for a specific guard only if the above options do not work. Never disable SecretLeakGuard in production.
7. Re-verify: After changes, run clawdstrike_policy_eval again to confirm the action is now allowed without opening unintended gaps.

Response Guidelines

When this skill is active:

• Use clawdstrike_policy_show and clawdstrike_policy_eval to give concrete answers
• Explain guard behavior in terms of what the user is trying to do
• Recommend the most appropriate ruleset for the user's use case
• When an action is denied, explain which guard blocked it and why