CiscoCiscoDefenseClaw

OpenClaw integration

How DefenseClaw integrates with OpenClaw end-to-end — fetch interceptor, before_tool_call hook, correlation headers, plugin-mediated HITL approvals, and the audit loop.

OpenClaw is the connector DefenseClaw was designed against. It is also the only connector that ships a first-party plugin in the same repository (extensions/defenseclaw/). That plugin owns the OpenClaw-side wiring; the gateway and CLI own everything else.

Plugin install + first guardrail. The DefenseClaw plugin loads inside OpenClaw, the gateway picks up the correlation header, and policy decisions stream back through the chat UI.

Components

DefenseClaw plugin

TypeScript plugin under extensions/defenseclaw/. Hooks into OpenClaw's fetch interceptor and before_tool_call lifecycle.

defenseclaw-gateway

Go sidecar. Receives plugin requests, evaluates policy, returns verdicts, and writes the audit row.

DefenseClaw CLI

Python operator surface. Runs setup, exposes the TUI, drives HITL approvals.

End-to-end flow

  1. 01User OpenClaw

    prompt

  2. 02OpenClaw DefenseClaw plugin

    fetch (LLM request)

  3. 03DefenseClaw plugin defenseclaw-gateway

    POST /v1/inspect (X-DefenseClaw-Correlation-Id)

  4. 04defenseclaw-gateway DefenseClaw plugin

    allow / block / pause

  5. 05defenseclaw-gateway Operator (TUI)

    enqueue approval (when paused)

  6. 06Operator (TUI) defenseclaw-gateway

    approve / deny

  7. 07defenseclaw-gateway DefenseClaw plugin

    resolved verdict

  8. 08DefenseClaw plugin OpenClaw

    forward (or reject)

  9. 09OpenClaw DefenseClaw plugin

    before_tool_call(name, args)

  10. 10DefenseClaw plugin defenseclaw-gateway

    POST /v1/tool/inspect

  11. 11defenseclaw-gateway DefenseClaw plugin

    verdict

  12. 12DefenseClaw plugin OpenClaw

    allow / block

  13. 13OpenClaw User

    response

Three interception points let DefenseClaw inspect every interesting moment in OpenClaw's lifecycle and surface HITL approvals back through the chat origin.

Correlation headers

Every plugin → gateway request carries X-DefenseClaw-Correlation-Id so the audit log can stitch a tool call back to the prompt that triggered it. The plugin generates one ID per OpenClaw turn; the gateway re-uses it for every downstream verdict.

HITL: the only connector with plugin-mediated approval

OpenClaw is one of two connectors (alongside Claude Code) where HITL approvals reach the operator inside the agent UI. The DefenseClaw plugin queues approvals in OpenClaw's chat origin, so the operator approves or denies without leaving OpenClaw.

The other connectors fall back to a downgraded confirm verdict surfaced through defenseclaw tui. See the HITL page for the per-connector matrix.

Files DefenseClaw owns inside the OpenClaw tree

openclaw.json (allow + load entries for the DefenseClaw plugin)

DefenseClaw never touches anything outside extensions/defenseclaw/ and the allow / load arrays in openclaw.json. Backups are byte-for-byte; teardown either restores the file or surgically removes only DefenseClaw entries when the file has drifted.

When this is the right connector

Pick OpenClaw when:

  • You want the strongest enforcement contract: proxy-mode interception, sandbox subprocess policy, native ask + plugin-mediated approval.
  • You're already running OpenClaw or are open to switching from Codex / Claude Code for security-critical workflows.
  • You need fail-closed behaviour on transport failures.

If you're not running OpenClaw, the Claude Code connector is the closest hook-only equivalent and supports native ask on PreToolUse.

Defaults

What every fresh DefenseClaw install ships with — three OPA policies (permissive / default / strict), three matching guardrail rule packs, the operator-config defaults, and how to pick the combination that fits your team's risk tolerance.

Observability

Every prompt, tool call, scan finding, and HITL decision lands in your SIEM and your dashboards. DefenseClaw ships local Grafana/Loki/Tempo and local Splunk stacks you can stand up with one command.