Highest control. Best for regulated or high-blast-radius environments.
CORDCLAW_PROFILE=strict OPENCLAW_SKIP=true ./install.sh
The hard part is not writing policy text. It is proving your OpenClaw runtime will block dangerous calls before execution.
TL;DR
Teams often have guardrail docs, but no repeatable proof that their OpenClaw runtime will stop risky commands. If your first deny test happens in production, that is not a test plan.
This guide focuses on command-level validation. You install once, run two simulations, and inspect the audit timeline. Then you can tune profile strictness with intent.
| Source | Covers | Misses for OpenClaw teams |
|---|---|---|
| OpenAI Agents SDK Guardrails | Input/output/tool guardrail concepts and where checks execute. | No OpenClaw plugin wiring, local daemon checks, or profile rollout commands. |
| LangChain Guardrails | Middleware patterns, PII checks, and human-in-the-loop hooks. | No pre-dispatch daemon boundary for OpenClaw, and no audit CLI verification flow. |
| Amazon Bedrock Guardrails | Policy types, prompt/response interventions, and runtime behavior. | No local OpenClaw setup path, no command simulations, no profile switching workflow. |
Run this exactly once in a local environment. You should see one ALLOW, one DENY, and fresh audit records.
1. Install CordClaw
From the setup directory run OPENCLAW_SKIP=true ./install.sh to install CordClaw in local mode.
2. Check daemon and plugin health
Verify local daemon and plugin wiring with /health and openclaw cordclaw status.
3. Run allow and deny simulations
Simulate one safe command and one destructive command to confirm ALLOW and DENY behavior.
4. Review decision history
Run openclaw cordclaw audit --limit 20 to inspect decisions and reasons.
cd setup OPENCLAW_SKIP=true ./install.sh # check local health and plugin status curl -sS http://127.0.0.1:19090/health | jq . openclaw cordclaw status # run one allow-path and one deny-path simulation openclaw cordclaw simulate --tool exec --command "echo hello" openclaw cordclaw simulate --tool exec --command "rm -rf /" # inspect recent decisions openclaw cordclaw audit --limit 20
Start with moderate for most teams. Switch to strict for sensitive workloads. Move to permissive only when low risk and strong monitoring are already in place.
Highest control. Best for regulated or high-blast-radius environments.
CORDCLAW_PROFILE=strict OPENCLAW_SKIP=true ./install.sh
Balanced default for teams moving from staging to production.
CORDCLAW_PROFILE=moderate OPENCLAW_SKIP=true ./install.sh
Lower friction for internal automation where speed is the main goal.
CORDCLAW_PROFILE=permissive OPENCLAW_SKIP=true ./install.sh
# apply profile by reinstalling with a profile flag CORDCLAW_PROFILE=strict OPENCLAW_SKIP=true ./install.sh CORDCLAW_PROFILE=moderate OPENCLAW_SKIP=true ./install.sh CORDCLAW_PROFILE=permissive OPENCLAW_SKIP=true ./install.sh # sanity-check profile behavior openclaw cordclaw simulate --tool exec --command "echo profile check" openclaw cordclaw simulate --tool exec --command "rm -rf /"
Strict profile adds friction. Expect slower flow for commands that require human review.
Simulations validate policy decisions, not every downstream system side effect in production.
Pre-dispatch governance helps at decision time. You still need runtime isolation and post-incident review.
Includes rollout phases, simulation payload patterns, and outage-mode checks for CordClaw deployments.
One practical email sequence for install, validation, and production hardening.
No spam. Unsubscribe anytime.
Run the quickstart block above, confirm one DENY decision, then move to the full setup tutorial for profile tuning.
Need broader platform docs? See Cordum quickstart.