How to Secure OpenClaw Agents in Production

The production problem

OpenClaw security failures rarely start with one dramatic exploit. They start with small assumptions. A bot can run `exec`, read files, install skills, and act with real credentials. Teams often secure the host, then forget to secure the decision path that decides whether actions should run at all.

That gap matters. If policy runs only in prompts or after execution, unsafe actions already crossed the line. Real production security needs a hard pre-dispatch decision point: policy check first, execution second.

Microsoft's OpenClaw runtime analysis from February 19, 2026 makes the same boundary problem explicit. Their guidance is clear: do not run OpenClaw on normal workstations and treat it as untrusted code execution with persistent credentials.

Top 3 articles: coverage vs gaps

I reviewed the top external references operators currently encounter for secure OpenClaw deployments (checked on April 1, 2026). They give useful guidance, but they stop before the governance mechanics most production teams need.

This guide fills that gap with code-accurate pre-dispatch governance wiring from CordClaw and Cordum.

Reference architecture

The architecture that consistently works has two boundaries: runtime isolation and governance control. Isolation limits blast radius. Governance decides if an action executes.

OpenClaw Gateway
  -> CordClaw plugin (before_tool_execution)
  -> POST http://127.0.0.1:19090/check
  -> cordclaw-daemon (mapper + cache + circuit breaker)
  -> gRPC Safety Kernel check
  -> decision: ALLOW | DENY | THROTTLE | REQUIRE_HUMAN | CONSTRAIN
  -> plugin enforces outcome before tool execution

The plugin also hooks `after_tool_execution` and sends audit events to the daemon. That gives fast local observability, while Cordum provides durable governance records for team-scale operations.

5-minute secure setup

This uses the current `setup/install.sh` flow in `D:\\Cordum\\Cord-Claw`. Start with the installer, then verify one allowed and one denied decision before any real production workflow.

cd setup
OPENCLAW_SKIP=true ./install.sh

# Standalone mode (no local Cordum stack)
CORDUM_UPGRADE=false OPENCLAW_SKIP=true ./install.sh

# Full stack mode (recommended for teams)
CORDUM_UPGRADE=true OPENCLAW_SKIP=true ./install.sh

# Pick baseline profile during install
CORDCLAW_PROFILE=moderate OPENCLAW_SKIP=true ./install.sh

After install, run a deterministic smoke test. A safe command should pass. A destructive command should deny. If both pass, your policy path is not active.

curl -sS http://127.0.0.1:19090/health | jq .
openclaw cordclaw status

openclaw cordclaw simulate --tool exec --command "echo hello"
openclaw cordclaw simulate --tool exec --command "rm -rf /"

curl -sS "http://127.0.0.1:19090/audit?limit=20" | jq .

Policy profile matrix

CordClaw ships three baseline profiles in `setup/templates/`. They are not cosmetic labels. They encode different risk postures across `exec`, file operations, outbound communication, and scheduling.

cp ~/.cordclaw/templates/policy-strict.yaml ~/.cordclaw/config/safety.yaml
cd ~/.cordclaw
docker compose --env-file .env restart safety-kernel

openclaw cordclaw simulate --tool exec --command "echo profile check"
openclaw cordclaw simulate --tool exec --command "npm install lodash"
openclaw cordclaw simulate --tool exec --command "rm -rf /"

Most teams should launch with `moderate`. It blocks destructive and cloud-risk commands while keeping daily iteration usable.

Risk-tag mapping and tests

Policy quality depends on input quality. CordClaw does not pass raw prompt text to policy. The daemon maps structured tool metadata and command/path/url signals into risk tags. That mapping is where most false positives and false negatives start, so test it directly.

In current mapper code, command regexes identify destructive operations, package installs, remote access tools, cloud utilities, and secrets exposure behavior. Path patterns add tags for sensitive files such as `.env` and key material. URL parsing adds `insecure-transport` for non-HTTPS destinations.

Run explicit simulation vectors for each tag family before rollout. This prevents profile drift where rules look correct in YAML but do not trigger on real command shapes.

# Destructive shell should deny in moderate/strict
openclaw cordclaw simulate --tool exec --command "rm -rf /tmp/demo"

# Cloud control path should deny or require approval based on profile
openclaw cordclaw simulate --tool exec --command "aws iam list-users"

# Package install should require approval in moderate
openclaw cordclaw simulate --tool exec --command "npm install lodash"

# Secrets path read should deny in permissive/strict depending on rule set
openclaw cordclaw simulate --tool read --path "~/.ssh/id_rsa"

# Insecure URL fetch should include insecure-transport risk tag
openclaw cordclaw simulate --tool web_fetch --url "http://example.com/data.json"

Human approvals that hold up

Approval flows fail when they are loosely attached to execution. In this path, approval is a policy decision outcome (`REQUIRE_HUMAN`) emitted before execution. The plugin blocks the tool call and returns an approval reference in the operator message.

Keep approvals narrow. Route high-risk actions only: package installs, deploy-like commands, outbound messaging, or cloud control-plane operations. Leave low-risk reads automated.

Small humor, large truth: if everything needs approval, nothing is actually reviewed.

Fail-mode matrix

Production outages are where policy systems earn trust or lose it. You need explicit behavior for two failure boundaries, not one.

plugins:
  entries:
    cordclaw:
      enabled: true
      config:
        daemonUrl: "http://127.0.0.1:19090"
        timeoutMs: 500
        failMode: "deny"
        logDecisions: true
        bypassTools: []

# Required daemon env
export CORDCLAW_KERNEL_ADDR=127.0.0.1:50051
export CORDCLAW_API_KEY=<cordum-api-key>
export CORDCLAW_TENANT_ID=default

# Cache + resilience defaults
export CORDCLAW_CACHE_TTL=5m
export CORDCLAW_CACHE_MAX_SIZE=10000
export CORDCLAW_LISTEN_ADDR=127.0.0.1:19090

# Kernel outage behavior: graduated | closed | open
export CORDCLAW_FAIL_MODE=graduated

# TLS (production)
export CORDCLAW_KERNEL_INSECURE=false
export CORDCLAW_KERNEL_TLS_CA=/etc/ssl/certs/cordum-ca.pem

Audit evidence and retention

The daemon exposes fast local decision history via `/audit`. That is useful for immediate debugging and triage. It is not durable storage.

Current daemon behavior keeps an in-memory ring up to 1000 entries. When the process restarts, history resets. For compliance-grade trails, export decisions and correlate with Cordum run metadata.

openclaw cordclaw audit --limit 20
curl -sS "http://127.0.0.1:19090/audit?limit=20" | jq .

Integrate with Cordum

Pre-dispatch controls prevent unsafe actions. You still need post-dispatch output controls for secrets, PII, and injection strings that can appear in results. Cordum output policy is the second layer.

# Scheduler feature flag
OUTPUT_POLICY_ENABLED=true

# Example output policy rule
output_rules:
  - id: output-secret-leak
    enabled: true
    severity: critical
    match:
      topics: ["job.*"]
      detectors: ["secret_leak"]
    decision: quarantine
    reason: "Potential credential in output."

Keep OSS and enterprise claims clean. In current docs, multi-tenant API keys and advanced RBAC belong to enterprise components, while core pre-dispatch policy and output scanning are platform capabilities.

Limitations and tradeoffs

Production gate checklist

# 1) Isolation and identity
# - OpenClaw runs in isolated environment
# - non-privileged dedicated credentials only

# 2) Governance path is alive
curl -sS http://127.0.0.1:19090/health | jq .
openclaw cordclaw status

# 3) Decision behavior tests
openclaw cordclaw simulate --tool exec --command "echo ok"
openclaw cordclaw simulate --tool exec --command "rm -rf /"
openclaw cordclaw simulate --tool exec --command "npm install lodash"

# 4) Fail-mode drill
# stop safety kernel, verify expected plugin+daemon behavior

# 5) Output safety enabled
# verify OUTPUT_POLICY_ENABLED=true and output_rules loaded

# 6) Audit export path tested
curl -sS "http://127.0.0.1:19090/audit?limit=50" | jq .

A release is ready when all six checks pass in staging and the fail-mode drill behaves exactly as designed.

FAQ

Next step

Pick one real OpenClaw workflow, run it through `moderate` profile with simulation tests, execute one planned kernel outage drill, and document the exact pass/fail criteria in your runbook before production traffic.

• Continue with AI Agent Governance Platform Setup: Zero to Governed with CordClaw.
• Use How to Add Governance to OpenClaw for a shorter migration path.
• Review Configuration and Operations before broad rollout.