OpenClaw Security Comparison: CordClaw vs NemoClaw vs Built-In Sandboxing

The real problem

Most OpenClaw security conversations start with tools. The harder question comes later: which control layer is actually stopping which failure?

CordClaw, NemoClaw, and built-in OpenClaw controls are often compared as if they were equivalents. They are not. One layer decides before dispatch, one layer isolates runtime behavior, and one layer configures native allow/deny boundaries inside the gateway.

If your team is choosing a production baseline, a side-by-side control-path comparison is more useful than a list of features. This guide focuses on decision depth, failure behavior, operational overhead, and where each option breaks under pressure.

Top 3 sources: what they cover and miss

I reviewed the top external references operators usually find for this topic (checked on April 1, 2026). Each source is useful. None of them gives the complete deployment decision model by itself.

The common gap is clear: limited guidance on combining layers and testing outage behavior. The rest of this article fills that gap.

Feature matrix

This matrix maps each option to its strongest control point. It helps avoid category mistakes during evaluation.

Practical reading: built-in controls are fastest to adopt, NemoClaw is strongest on runtime isolation, and CordClaw is strongest when you need deterministic policy decisions before execution.

Decision flowchart

If your team wants one quick decision path instead of abstract pros and cons, use this flow.

START
  |
  v
Do agents run risky tools (exec, write, network, deploy)?
  |-- no --> Built-in OpenClaw controls + sandbox defaults
  |
  |-- yes --> Need strong runtime isolation?
               |-- yes --> Add NemoClaw sandbox policies
               |-- no --> Keep built-in sandbox + tighter tool policy

Need deterministic pre-dispatch decisions with approval semantics?
  |-- yes --> Add CordClaw governance path
  |-- no --> Stay with runtime/config controls

Production baseline:
built-in restrictions + sandboxing + pre-dispatch governance + output safety

Most mature production stacks end up layered: built-in restrictions, runtime sandboxing, pre-dispatch governance, then output safety.

# Built-in baseline check
# deny should win and elevated should stay restricted

# NemoClaw baseline check
openshell term
# verify blocked network request behavior in TUI

# CordClaw baseline check
curl -sS http://127.0.0.1:19090/health | jq .
openclaw cordclaw simulate --tool exec --command "echo ok"
openclaw cordclaw simulate --tool exec --command "rm -rf /"

Implementation examples

These are practical command and config patterns for each layer. The goal is fast evaluation with comparable signals, not perfect setup on day one.

{
  "agents": {
    "defaults": {
      "sandbox": {
        "mode": "on",
        "scope": "agent",
        "workspaceAccess": "ro"
      }
    }
  },
  "tools": {
    "sandbox": {
      "tools": {
        "allow": ["group:runtime", "group:fs", "group:memory"],
        "deny": ["gateway", "cron"]
      }
    }
  }
}

# NemoClaw policy persistence workflow
# 1) approve in TUI for current session
openshell term

# 2) persist required route into baseline policy file
#    openclaw-sandbox.yaml

# 3) re-apply static policy
nemoclaw onboard

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

CordClaw path defaults worth remembering from source: plugin timeout `500ms`, daemon check timeout `2s`, decision cache TTL `5m`, and cache max size `10000`.

Use-case recommendations

Choose controls by blast radius and evidence requirements, not by whichever product has the longest feature list.

Run the same simulation vectors across all options, then compare behavior and operator burden.

# Destructive path
openclaw cordclaw simulate --tool exec --command "rm -rf /tmp/demo"

# Cloud control path
openclaw cordclaw simulate --tool exec --command "aws iam list-users"

# Package install path
openclaw cordclaw simulate --tool exec --command "npm install lodash"

# Secrets path read
openclaw cordclaw simulate --tool read --path "~/.ssh/id_rsa"

# Non-HTTPS fetch
openclaw cordclaw simulate --tool web_fetch --url "http://example.com/data.json"

Operations tradeoffs

A secure architecture that no one can operate is not secure in practice. Compare on-call burden and debug loops before deciding.

Built-in controls minimize moving parts. NemoClaw adds sandbox/network operations. CordClaw adds governance-plane operations and policy lifecycle management. None of these costs is optional once you deploy at scale.

Small humor, large truth: if your team cannot explain one denied action in under two minutes, your control stack is not production-ready yet.

Failure behavior matrix

Outages are where security claims are either true or fiction. Test fallback behavior explicitly.

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 and evidence reality

Runtime logs and decision logs are useful, but they are not equal in audit quality.

Current CordClaw daemon behavior keeps an in-memory ring up to 1000 entries. Restarts reset local history. Treat local audit as operational telemetry and export durable evidence for compliance paths.

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

Layered deployment model

Production systems usually combine controls instead of choosing one winner. Layering is not redundancy; each layer catches a different failure class.

# Layered deployment model
# 1) Built-in OpenClaw controls (tool policy, sandbox defaults, elevated restrictions)
# 2) NemoClaw runtime isolation + network policy workflow
# 3) CordClaw pre-dispatch governance (plugin -> daemon -> Safety Kernel)
# 4) Output safety and durable audit retention

The practical stack for high-risk workflows: built-in controls for immediate hardening, sandboxing for runtime containment, CordClaw for pre-dispatch decisions, and output-safety scanning after execution.

Limitations

One-day evaluation script

# 1) Built-in controls only
# - enable sandbox mode
# - enforce strict tool allow/deny

# 2) Add NemoClaw
# - validate isolation and blocked endpoint workflow
# - verify which approvals persist

# 3) Add CordClaw
# - run ALLOW, DENY, REQUIRE_HUMAN, CONSTRAIN vectors
# - drill plugin and daemon outage behavior

# 4) Capture evidence
# - keep decision logs and approval outcomes
# - verify audit export path

This script gives you comparable behavior data in one day instead of a week of ad-hoc testing.

FAQ

Next step

Pick one real OpenClaw workflow and run it through all three layers in sequence: built-in only, then NemoClaw, then CordClaw. Keep the stack that passes both risk and operator burden checks. If your incident review process needs deterministic approval semantics, stop relying on runtime-only controls.

• Continue with How to Secure OpenClaw Agents in Production.
• Continue with AI Agent Governance Platform Setup: Zero to Governed with CordClaw.
• Read What Is Pre-Dispatch Governance for AI Agents? before broad rollout.
• Review Output Safety for the post-dispatch layer.