CordClaw

CordClaw for OpenClaw

CordClaw is the OpenClaw plugin that asks Cordum for a deterministic allow/deny/approval decision before any action runs. Policy enforcement at the execution boundary, not in-prompt.

View GitHub 5-Minute Quickstart Open Docs Talk to Enterprise

Request Path

OpenClaw

Gateway Plugin Hook

CordClaw

Local Go Daemon

Cordum

Safety Kernel

Decision returned before execution: ALLOW, DENY, THROTTLE, REQUIRE_HUMAN, CONSTRAIN.

The problem CordClaw solves

OpenClaw's security model assumes a single trusted operator boundary. Its own documentation states that for mixed-trust or adversarial users, separate gateways and hosts are recommended. But most production deployments have multiple agents, multiple teams, and actions with varying risk levels. There is no built-in way to enforce "this agent can read files but cannot execute shell commands" or "this action requires human approval before it runs."

CordClaw fills that gap. It sits at the OpenClaw gateway layer and evaluates every action against policy rules before the tool executes. If the policy says deny, the action never starts. If the policy says require approval, the action waits for a human. Every decision is logged with the policy version that produced it.

What Is CordClaw

The OpenClaw governance plugin for pre-dispatch policy enforcement.

CordClaw is an open-source plugin that intercepts every OpenClaw action request, evaluates it against policy rules, and returns a deterministic decision before anything executes.

How it works

1Your OpenClaw agent decides to call a tool (exec, file write, API call).
2CordClaw intercepts the request at the gateway layer, before the tool runs.
3The local daemon evaluates the action against your policy rules (YAML config).
4A decision is returned: ALLOW, DENY, REQUIRE_HUMAN, THROTTLE, or CONSTRAIN.
5Only allowed actions execute. Denied actions never start. Every decision is logged.

CordClaw and Cordum

CordClaw works standalone with a local policy daemon. No external dependencies required. When you are ready for centralized governance across multiple agents, connect CordClaw to a Cordum instance for fleet-wide policy management, approval workflows, and consolidated audit trails.

Standalone mode: Local daemon, local policies, local audit log. No network calls.

Connected mode: Daemon forwards decisions to Cordum. Centralized policies, approval queues, fleet dashboard.

Start standalone. Upgrade to connected when you need it. No code changes required.

Who is this for

Teams shipping OpenClaw agents to production

You need to prove that dangerous actions are blocked before they run, not after.

Security and compliance teams

You need audit evidence that every agent action was evaluated against policy before execution.

Platform engineers managing agent fleets

You need centralized governance across multiple agents, teams, and environments.

Why CordClaw

Three common approaches miss the execution boundary.

CordClaw is built for deterministic pre-dispatch control, not post-hoc visibility.

Sandboxing only

Contains runtime damage, but still allows risky actions to start. CordClaw decides before execution.

Monitoring only

Tells you what happened after the fact. CordClaw blocks or gates actions up front.

In-context prompts

Policy text can be bypassed by prompt injection. CordClaw evaluates structured metadata outside context.

Decision Model

AI agent policy enforcement with five deterministic outcomes.

Every action request maps to a typed decision and reason before execution.

ALLOW

Low-risk action executes immediately.

exec: npm test

DENY

Dangerous action is blocked before execution.

exec: rm -rf /

THROTTLE

Action is rate-limited to reduce blast radius.

exec: npm install (burst)

REQUIRE_HUMAN

Execution pauses until a reviewer approves.

message-send: external notice

CONSTRAIN

Action runs with enforced limits (sandbox, timeout, paths).

exec: go test ./... with 30s timeout

Comparison

OpenClaw security: CordClaw vs alternatives.

A practical view of where pre-dispatch policy enforcement fits.

Capability	CordClaw	NemoClaw	SecureClaw	Native OpenClaw
Enforcement point	Pre-dispatch	Runtime sandbox	In-context	Config allow/deny
Decision types	5	2	2	2
Prompt-injection resistance	Yes (structured)	Yes	No	No
Human approval flow	Native	No	No	Limited
Audit trail depth	Full decision trail	Partial	Minimal	Minimal

How It Looks

Real policy config, real terminal output.

What CordClaw actually does when an OpenClaw agent tries to run a dangerous command.

Policy config

cordclaw.yaml

yaml

profile: strict
daemon:
  timeoutMs: 500
  failMode: "deny"    # if daemon unreachable, block the action

rules:
  - id: deny-destructive-commands
    match:
      tool: exec
      command_pattern: "rm -rf|drop table|shutdown"
    decision: deny
    reason: "Destructive commands are blocked"

  - id: approve-prod-writes
    match:
      tool: file_write
      environment: production
    decision: require_human
    reason: "Production file writes need approval"

  - id: allow-reads
    match:
      tool: exec
      command_pattern: "ls|cat|echo|grep"
    decision: allow

Terminal output

terminal

bash

$ openclaw cordclaw simulate --tool exec \
    --command "echo hello"
Decision: ALLOW
Reason:   Matched rule allow-reads
Latency:  2ms (cached)

$ openclaw cordclaw simulate --tool exec \
    --command "rm -rf /tmp/data"
Decision: DENY
Reason:   Destructive commands are blocked
Rule:     deny-destructive-commands
Latency:  3ms (cached)

$ openclaw cordclaw simulate --tool file_write \
    --env production --path "/etc/config"
Decision: REQUIRE_HUMAN
Reason:   Production file writes need approval
Rule:     approve-prod-writes
Latency:  41ms (daemon)

$ openclaw cordclaw audit --limit 3
ID        TOOL        DECISION       RULE
a1b2c3    exec        ALLOW          allow-reads
d4e5f6    exec        DENY           deny-destructive-commands
g7h8i9    file_write  REQUIRE_HUMAN  approve-prod-writes

Standalone mode: audit entries stored locally. Connected mode: forwarded to Cordum for centralized audit trails and fleet-wide dashboards.

Quickstart

Install the OpenClaw governance plugin and validate in minutes.

Start with local setup, run your first simulation, then connect CordClaw to the full Cordum stack.

getting-started

bash

cd setup
OPENCLAW_SKIP=true ./install.sh

# first decision
openclaw cordclaw simulate --tool exec --command "echo hello"

# destructive command (expected DENY)
openclaw cordclaw simulate --tool exec --command "rm -rf /"

# inspect audit trail
openclaw cordclaw audit --limit 20

Performance

Built for production latency budgets.

CordClaw adds governance without blocking your agent pipeline.

Cached policy decision

<5ms

Hot path with local policy cache

Warm decision (daemon)

<50ms

Daemon-resolved policy evaluation

Decision types supported

ALLOW, DENY, THROTTLE, REQUIRE_HUMAN, CONSTRAIN

Frequently Asked Questions

What is CordClaw?

CordClaw is an OpenClaw governance plugin that enforces deterministic pre-dispatch policy decisions before tool execution.

How does CordClaw improve OpenClaw security?

CordClaw applies policy checks before execution, supports human approvals, and records decision-level audit trails for each action.

Which policy decisions can CordClaw return?

CordClaw returns ALLOW, DENY, THROTTLE, REQUIRE_HUMAN, and CONSTRAIN so teams can enforce clear runtime behavior for each action.

Can I run CordClaw before deploying the full Cordum stack?

Yes. You can run local simulations with CordClaw first, validate policy behavior, and connect to the full Cordum stack later.

How do I test pre-dispatch governance safely?

Use simulation commands for both allow and deny paths, then review the resulting audit output before enabling production write actions.

Enterprise

Put governance in front of every agent action.

Bring pre-dispatch controls, approval gates, and auditable decision trails to production AI agent workflows.

Book an Enterprise Demo Explore GitHub Repo Read Docs