Skip to main content

OpenClaw + AxonFlow

AxonFlow adds policy enforcement, approval gates, and audit trails to OpenClaw.

OpenClaw is strong at agent runtime, tool execution, MCP connectivity, and channel integrations. AxonFlow complements it with production governance controls: inspect tool inputs before execution, scan outbound messages before delivery, and record tool + LLM activity for review, security, and compliance.

Prerequisites: OpenClaw 2026.4.15 or later (CVE floor), @axonflow/openclaw 2.0.4 or later, and an AxonFlow agent gateway. Self-host via Docker Compose (Getting Started) for any real workload — see Privacy notice below for why.

Plugin: @axonflow/openclaw — also available on ClawHub. Source at getaxonflow/axonflow-openclaw-plugin.

Privacy notice​

Read before installing. AxonFlow Community SaaS at try.getaxonflow.com is the zero-config endpoint the plugin uses if pluginConfig.endpoint is not set. In that mode, governed tool inputs (tool name + arguments) and outbound message bodies are checked by AxonFlow's policy enforcement endpoint and recorded for audit. Community SaaS is offered in two tiers — Free (3-day audit retention, 200 events/day) and Plugin Pro ($9.99 / 90 days, 30-day retention, 2,000 events/day). Both tiers are suitable for individual use within their documented limits. Neither tier is designed for regulated industries, real user data of third parties, or workloads requiring contractual SLOs — see the Privacy Policy for the full scope of what we commit to and what we don't.

For any serious use, choose one of the following instead:

  1. Self-host AxonFlow Community Edition — runs entirely on your infrastructure and keeps data within your boundary. Recommended for any real workload.
  2. Community Edition with an Evaluation License — for production use with real users or clients on the open core; adds production-fit limits and license-gated features. Free 90-day evaluation license.
  3. AxonFlow Enterprise — production-grade governance, regulatory-grade controls, SLOs, and contractual commitments suitable for regulated industries. Contact [email protected].

Setting pluginConfig.endpoint to a self-hosted AxonFlow URL alone flips the plugin into self-hosted mode — no env var is required. For air-gapped operation, set AXONFLOW_COMMUNITY_SAAS=0 to suppress the bootstrap attempt and AXONFLOW_TELEMETRY=off to disable the anonymous 7-day heartbeat.

Plugin Pro — paid upgrade for individual developers​

$9.99 USD for 90 days. One-time payment, no auto-renewal.

If you're using this plugin against try.getaxonflow.com and outgrowing the Free tier's caps — daily quota, audit retention, the custom-policy and HITL-approval limits, or the lack of LLM cost pre-flight — Plugin Pro removes them:

  • 30-day audit retention (10× Free)
  • 2,000 governed events per day (10× Free)
  • Unlimited custom tenant policies (Free: 2 active max)
  • Unlimited HITL approvals (Free: 1 per rolling 7d)
  • LLM cost pre-flight — see what a multi-step plan costs before it runs (Pro only)
  • Email support, 2 business-day response
  • 14-day refund window — no questions asked

Buy at getaxonflow.com/pricing → paste your cs_<uuid> tenant ID at Stripe Checkout → receive your AXON-… token by email → install with export AXONFLOW_LICENSE_TOKEN='AXON-...' in your shell profile, or set licenseToken in ~/.openclaw/openclaw.json under plugins.entries.axonflow-governance.config. Verify with axonflow-openclaw-status — it should print tier: Pro. Full guide: Plugin Pro install.

Pro is for individual-developer use only. For team/production workloads, self-host Community Edition or contact us about Enterprise.

What This Integration Enables​

OpenClaw users now have a much better governed-unblock workflow than a simple allow or deny. That matters because OpenClaw is often the first place a real user feels governance. If a tool call is blocked inside a customer support agent, a travel workflow, or a database-backed enterprise assistant, a vague rejection is not enough. The agent needs enough context to explain what happened and enough platform surface to recover safely.

  • blocked tool calls can carry decision_id, risk_level, matched policy context, and override status, so the agent can explain what happened instead of only showing a generic rejection
  • client.explainDecision() lets the same OpenClaw session pull the full Decision Explainability record for a block, review event, or audited decision
  • createOverride(), listOverrides(), and revokeOverride() let an operator move through a short-lived Session Overrides workflow without leaving the OpenClaw runtime
  • config.userEmail lets the plugin forward per-user identity, which keeps explainability, override creation, and override cleanup scoped to the right human even when agents are shared

In practice, that means an OpenClaw agent can do something materially more useful after a policy block. Instead of returning "not allowed", it can surface the decision ID, tell the user which policy family triggered, explain whether the risk is low enough for a governed exception, and then help the operator create or inspect that temporary override. That is a much more realistic production workflow for support teams, operations teams, and internal platform users who need fast answers without bypassing the control plane.

The OpenClaw-specific value is that risk_level is not just metadata. It can drive the native approval severity and user-facing approval UX that OpenClaw already understands in chat and approval flows. That means AxonFlow is not simply attaching audit decoration after the fact. It is shaping how the agent presents risk and approval urgency to the human operator.

The userEmail support matters just as much operationally. Shared chat agents often serve many human users through the same runtime. Without per-user identity on override and explainability calls, a temporary unblock created for one operator can be hard to reason about or clean up later. With scoped identity, the same OpenClaw deployment can support self-service investigation and temporary unblocks while keeping the audit trail attributable to the actual person who requested them.

What This Integration Covers Today​

  • Tool input governance before execution (dangerous commands, SQL injection, PII in arguments)
  • Human approval for selected high-risk tools
  • Outbound message scanning for PII and secrets
  • Audit logging for tool calls and LLM activity
  • Individual audit event search for debugging and compliance evidence (v1.0.0+)

Current Limitation​

Tool-result transcript scanning is not yet available. OpenClaw's current tool_result_persist hook is sync-only, so the plugin cannot call AxonFlow asynchronously at that point in the lifecycle. If OpenClaw adds async support there, AxonFlow can add transcript/result scanning immediately.

Quick Start

Install the plugin and add governance to your OpenClaw agent in five lines. Requires OpenClaw 2026.4.15 or later (CVE floor); strongly recommended: 2026.5.7 or later (see hash-mismatch note below). Upgrade with npm install -g openclaw@latest.

openclaw plugins install @axonflow/openclaw@latest

We recommend the npm-spec form as the primary install path. npm is our source-of-truth registry — every release is published there first, with the maturity and stability you'd expect from a long-established package registry. The CLI resolves the spec and downloads the latest tarball directly. The clawhub:@axonflow/openclaw form is also supported and pulls from the ClawHub mirror, which we publish to alongside npm on each release.

Hit ClawHub archive integrity mismatch?

OpenClaw CLI versions before 2026.5.7 can hit a regression in the integrity check on the ClawHub install path (confirmed on 2026.4.27). The published @axonflow/openclaw artifact is byte-correct on both registries (npm and ClawHub serve identical bytes that match the manifest's pinned hash); the CLI computes a different hash internally and fails the comparison. Fixed upstream in OpenClaw 2026.5.7 — npm install -g openclaw@latest to upgrade.

If you cannot upgrade the CLI, fall back to a local-tgz install (this also covers the older ENOENT bug below):

TGZ=$(npm pack @axonflow/openclaw 2>/dev/null | tail -1)
openclaw plugins install "./$TGZ"
On a pre-2026.4.14 CLI?

Versions before 2026.4.14 had a separate bug (openclaw/openclaw#66618) that made scoped packages fail with ENOENT .../openclaw-clawhub-package-XXXXXX/@axonflow/openclaw.zip — both forms of the install command hit it. Fixed upstream in 2026.4.14. The local-tgz fallback above resolves it.

# openclaw.config.yaml
plugins:
  @axonflow/openclaw:
    endpoint: http://localhost:8080

That's it. In community mode, clientId defaults to "community" and clientSecret can be left unset. Add both only when you want Evaluation License or Enterprise credentials. Every governed tool call now flows through AxonFlow policy enforcement.

:::

What OpenClaw Does Well​

OpenClaw is an AI agent gateway for messaging platforms and enterprise chat systems. It provides the runtime layer between users and AI agents, handling tool execution, message routing, and channel connectivity:

AI Agent Gateway: Central control plane for deploying AI agents across messaging platforms. Agents register tools, and OpenClaw handles routing user requests to the right tool.

2800+ Community Skills via ClawHub: A marketplace of pre-built skills covering web search, code execution, file management, database queries, and more. Install a skill and your agent can use it immediately.

MCP Runtime: Native Model Context Protocol support for connecting agents to external data sources and APIs. OpenClaw manages MCP server lifecycle, connection pooling, and request multiplexing.

Built-in Safety Controls: Tool allow/deny lists, execution approval prompts, and SecretRef for credential management. These controls handle the "should this tool run at all" question at the agent level.

Multi-Channel Deployment: Single agent definition, deployed across Telegram, Discord, WhatsApp, Slack, and custom webhooks. Channel-specific formatting handled automatically.

Extensible Plugin Architecture: Lifecycle hooks for every stage of tool execution. Plugins can intercept, modify, or block tool calls at before_tool_call, tool_result_persist, and after_tool_call.

What OpenClaw Doesn't Try to Solve​

OpenClaw focuses on agent deployment and tool execution. These concerns are explicitly out of scope:

Production RequirementOpenClaw's Position
Centralized policy enforcement across toolsNot provided. Tool allow/deny is per-agent, not org-wide
PII detection in tool arguments and resultsNot addressed. Tool inputs and outputs pass through unchanged
Audit trails with decision contextProvides execution logs. Not structured for compliance queries
Cross-tool rate limiting and budgetsNot tracked. Each tool executes independently with no cost awareness
Enterprise compliance evidenceBasic logging. Not designed for regulatory evidence packs
Content filtering on LLM responsesNot provided. Agents return LLM output directly to users

This isn't a criticism. OpenClaw handles agent deployment and tool orchestration. Governance is a separate concern.

Where Teams Hit Production Friction​

Based on real enterprise deployments, here are the blockers that appear after the prototype works:

1. The Tool That Phones Home​

A web_fetch skill is installed from ClawHub. An agent uses it to look up product documentation. Then a user asks: "Summarize my customer list." The agent calls web_fetch with a URL containing customer names and email addresses in query parameters. The data leaves your infrastructure.

OpenClaw executed the tool correctly. The allow/deny list approved web_fetch as a permitted tool. Nobody checked what the tool was sending.

2. The MCP Response Full of PII​

An MCP connector queries your CRM database. The agent asked for "recent support tickets." The MCP server returns 50 tickets, each with customer name, email, phone number, and account details. All of it flows into the LLM context window.

OpenClaw managed the MCP connection. SecretRef handled the database credentials securely. The data itself was never inspected.

3. The Compliance Question Nobody Can Answer​

Six months after deployment, a regulator asks: "For this customer interaction on March 14, which tools were called, what data did they access, what policies were in effect, and why was the agent's response allowed?"

OpenClaw has execution logs. They show the tool was called and it succeeded. The decision context (why it was allowed, what policies applied, whether PII was present) does not exist.

How AxonFlow Plugs In​

AxonFlow integrates with OpenClaw through its plugin architecture. The @axonflow/openclaw registers five lifecycle hooks covering tool inputs, outbound messages, and LLM audit:

┌──────────────────────────────────────────────────────────────┐
│                        OpenClaw Agent                        │
│                                                              │
│  User Message → LLM Call → Tool Execution → Response → User  │
│        │           │             │                       │    │
│        ▼           ▼             ▼                       ▼    │
│  ┌───────────────────────────────────────────────────────┐   │
│  │            @axonflow/openclaw                   │   │
│  │                                                       │   │
│  │  GOVERNANCE (can block/modify):                       │   │
│  │  before_tool_call   (priority 10) → mcp_check_input   │   │
│  │  message_sending    (priority 10) → mcp_check_output  │   │
│  │                                                       │   │
│  │  AUDIT (observe-only):                                │   │
│  │  after_tool_call    (priority 90) → audit_tool_call   │   │
│  │  llm_input          (priority 90) → record prompt     │   │
│  │  llm_output         (priority 90) → audit/tool-call   │   │
│  └─────────────────────────┬─────────────────────────────┘   │
│                             │                                │
└─────────────────────────────┼────────────────────────────────┘
                              │
                              ▼
                    ┌───────────────────┐
                    │     AxonFlow      │
                    │  ┌─────┐ ┌─────┐  │
                    │  │Policy│ │Audit│  │
                    │  │Engine│ │Trail│  │
                    │  └─────┘ └─────┘  │
                    │  ┌─────┐          │
                    │  │ PII │          │
                    │  │Scan │          │
                    │  └─────┘          │
                    └───────────────────┘

What this gives you:

  • Every tool call policy-checked before execution, with arguments inspected for PII and injection
  • Every outbound message scanned for PII/secrets before delivery to Telegram/Discord/Slack
  • Every execution audited with tool name, arguments, result summary, and applied policies
  • Approval workflows triggered for high-risk tools, with the agent pausing until a human approves

What stays the same:

  • Your OpenClaw agent configuration is unchanged
  • ClawHub skills work without modification
  • MCP connectors run as before
  • Channel integrations are unaffected

Plugin Installation and Configuration​

This is a three-step install: stand up the AxonFlow platform, add the plugin to OpenClaw, then point the plugin at the platform. Skipping the third step is the most common mistake — the platform is running locally but the plugin still falls back to Community SaaS because no pluginConfig.endpoint is configured.

Step 1: install the AxonFlow platform​

For any real workload, run AxonFlow on your own infrastructure via Docker Compose. See Getting Started and Self-Hosted Deployment.

Step 2: install the plugin​

Requires OpenClaw 2026.4.15 or later (CVE floor); strongly recommended: 2026.5.7 or later — see the "Stuck on an older CLI?" note below for the workaround. Requires @axonflow/openclaw 2.0.4 or later:

openclaw plugins install @axonflow/openclaw@latest

We recommend the npm-spec form as the primary install path — npm is our source-of-truth registry, with the maturity and stability you'd expect from a long-established package registry. To pin a specific version (recommended in production / CI), use openclaw plugins install @axonflow/[email protected]. The clawhub:@axonflow/openclaw form is also supported and pulls from the ClawHub mirror.

Stuck on an older CLI?

Two known CLI bugs both have the same workaround — install from a locally packed tgz, which bypasses the broken paths:

TGZ=$(npm pack @axonflow/openclaw 2>/dev/null | tail -1)
openclaw plugins install "./$TGZ"

This covers both the 2026.4.27 → 2026.5.6 hash-mismatch regression and the pre-2026.4.14 scoped-package ENOENT bug. Both are fixed in current OpenClaw — npm install -g openclaw@latest is the simpler fix.

Step 3: configure the plugin​

Add it to your OpenClaw configuration. Set endpoint to your self-hosted AxonFlow URL — that alone flips the plugin into self-hosted mode and skips the Community SaaS auto-bootstrap. Resolve the credential value from a secret store (Vault, AWS Secrets Manager, GCP Secret Manager, or your CI provider's secret store) rather than embedding it in a config file checked into source control:

# openclaw.config.yaml
plugins:
  "@axonflow/openclaw":
    # AxonFlow agent gateway URL — leave unset to fall back to Community SaaS
    endpoint: http://localhost:8080

    # Tenant credentials — issued to your deployment for Evaluation License or Enterprise
    clientId: openclaw-agent-01
    # clientSecret: resolve from secret manager at runtime, do not commit

    # Optional: tools that require human approval even when policy allows
    highRiskTools:
      - web_fetch
      - message
      - execute_sql

    # Optional: only govern these tools (empty = all tools governed)
    governedTools: []

    # Optional: exclude these from governance (takes precedence over governedTools)
    excludedTools:
      - get_current_time
      - list_models

    # Optional: operation type for mcp_check_input ("execute" or "query")
    defaultOperation: execute

Configuration Reference​

FieldTypeDefaultDescription
endpointstringCommunity SaaS auto-bootstrap if unsetAxonFlow agent gateway URL. Set to your self-hosted instance for any real workload.
clientIdstringauto-populated for Community SaaSTenant ID for Basic auth. Required for self-hosted Community Edition with an Evaluation License or AxonFlow Enterprise.
clientSecretstringauto-populated for Community SaaSBasic-auth secret paired with clientId. Required for licensed tenants; resolve from secret manager, do not commit.
userEmailstringunsetPer-user identity, forwarded as X-User-Email. Required for createOverride / revokeOverride / listOverrides.
highRiskToolsstring[][]Tools requiring human approval even when policy allows
governedToolsstring[][]Only govern these tools (empty = all)
excludedToolsstring[][]Exclude from governance (takes precedence over governedTools)
defaultOperationstring"execute"Operation type sent to mcp_check_input ("execute" or "query")
onErrorstring"block"Behavior when AxonFlow is unreachable: "block" (fail-closed) or "allow" (fail-open)
requestTimeoutMsnumber8000Timeout for policy checks, output scans, audit writes, and health checks

Telemetry​

The plugin sends an anonymous heartbeat at most once every 7 days during activity to help AxonFlow understand adoption and environment shape, including local and self-hosted trials. Under the v1 telemetry schema, the ping carries telemetry_type=plugin, sdk=openclaw-plugin, and stream=heartbeat. The payload also includes plugin version, OS/architecture, Node.js version, AxonFlow platform version, and a hook configuration summary. It does not include message contents, tool arguments, or policy data.

The gate is evaluated once per plugin registration (typically on each IDE launch). The cadence is gated by a stamp file named openclaw-plugin-telemetry-sent under the OS-native cache directory:

  • macOS: ~/Library/Caches/axonflow/
  • Linux: $XDG_CACHE_HOME/axonflow/ when set, otherwise ~/.cache/axonflow/
  • Windows: %LOCALAPPDATA%\axonflow\

Delete the stamp to force one fresh ping on the next plugin load.

Opt out with AXONFLOW_TELEMETRY=off. DO_NOT_TRACK is not honored as an opt-out for AxonFlow telemetry — it is commonly inherited from host tools and developer environments, which makes it an unreliable expression of user intent. See Telemetry for the full wire-level field reference and the scope of AXONFLOW_TELEMETRY=off on Community SaaS vs self-hosted.

The heartbeat is enabled by default for local, self-hosted, and remote deployments. Opt-out controls always win.

Request Timeout Tuning​

Use requestTimeoutMs when OpenClaw needs to reach AxonFlow over a slower network path, VPN, or remote deployment.

plugins:
  @axonflow/openclaw:
    endpoint: http://localhost:8080
    requestTimeoutMs: 12000

The default is 8000 milliseconds and applies to policy checks, output scans, audit writes, and health checks.

Tool Filtering Logic​

The plugin uses a three-level filter to decide whether to govern a tool:

  1. If the tool is in excludedTools, skip governance (always takes precedence)
  2. If governedTools is non-empty and the tool is not in it, skip governance
  3. Otherwise, govern the tool

This means you can either allowlist specific tools (governedTools) or blocklist specific tools (excludedTools), but excludedTools always wins if both are set.

Integration Pattern​

The plugin hooks into OpenClaw's lifecycle at five points. Here is how each hook works, matching the actual implementation.

Hook 1: before_tool_call (Priority 10)​

When OpenClaw selects a tool to execute, the plugin intercepts the call before it runs. The hook receives the tool name and parameters, calls AxonFlow's mcp_check_input endpoint, and returns a decision.

// Receives from OpenClaw:
interface BeforeToolCallEvent {
  toolName: string;
  params: Record<string, unknown>;
  runId?: string;
  toolCallId?: string;
}

// The plugin:
// 1. Checks shouldGovernTool(toolName, config)
// 2. Derives connectorType = "openclaw.{toolName}"
// 3. Calls POST /api/v1/mcp/check-input with:
//    { connector_type, statement: JSON.stringify(params), operation }
// 4. Returns one of three outcomes:

// BLOCKED by policy:
{ block: true, blockReason: "Blocked by AxonFlow policy" }

// REQUIRES APPROVAL (tool is in highRiskTools AND policy allowed):
{
  requireApproval: {
    title: "AxonFlow: web_fetch requires approval",
    description: "Tool call governed by AxonFlow. 3 policies evaluated.",
    severity: "warning",
    timeoutMs: 60000,
    timeoutBehavior: "deny",
  }
}

// ALLOWED:
undefined

When a tool is blocked, OpenClaw skips execution and returns the block reason to the LLM as a tool error. When approval is required, OpenClaw pauses and posts an approval request to the configured channel.

Note that highRiskTools is evaluated after the policy check. If AxonFlow blocks the tool, it stays blocked regardless of the highRiskTools list. The approval gate only fires when AxonFlow allows the tool but the tool is in highRiskTools.

Tool Result Scanning — Pending Upstream Support

OpenClaw's tool_result_persist hook is synchronous, which means it cannot make async HTTP calls to AxonFlow for output policy enforcement. Tool results written to the session transcript are not currently scanned by this plugin.

What IS protected: Tool inputs are governed before execution, and outbound messages are scanned before delivery to users. What is NOT protected: Tool results entering the LLM context window. PII in tool results will be caught by message_sending before reaching the end user, but it will be visible to the LLM.

We have requested async support upstream. When available, this plugin will add output scanning.

Hook 2: after_tool_call (Priority 90)​

After tool execution completes (whether it succeeded, failed, was blocked, or had output redacted), the plugin logs the execution to AxonFlow's audit trail. This is fire-and-forget: audit failures never block tool execution.

// Receives from OpenClaw:
interface AfterToolCallEvent {
  toolName: string;
  params: Record<string, unknown>;
  runId?: string;
  toolCallId?: string;
  result?: unknown;
  error?: string;
  durationMs?: number;
}

// The plugin calls POST /api/v1/audit/tool-call with:
{
  tool_name: "web_fetch",
  tool_type: "openclaw",
  input: { url: "https://example.com/api" },
  output: { result: "<truncated to 500 chars>" },
  success: true,
  error_message: undefined,
  duration_ms: 342,
}

The output field truncates result data to 500 characters to keep audit payloads reasonable. The tool_type is always "openclaw" for connector attribution. If the audit call fails (network error, AxonFlow down), the error is silently caught. Governance was already enforced in the before_tool_call hook.

Connector Type Naming​

AxonFlow uses connector types to identify the source of tool calls in audit logs and policy rules. The OpenClaw plugin uses the format openclaw.{toolName}:

OpenClaw ToolAxonFlow Connector TypeExample Policy Target
web_fetchopenclaw.web_fetchBlock external URLs containing PII
execute_sqlopenclaw.execute_sqlRequire approval for all SQL execution
read_fileopenclaw.read_fileRestrict to allowed directories
send_emailopenclaw.send_emailBlock when recipient count > 100
slack_postopenclaw.slack_postScan message content for sensitive data
search_crmopenclaw.search_crmScan CRM query arguments for sensitive data

All tools (built-in, plugin-provided, and MCP-backed) use the same openclaw.{toolName} convention. The connector type is derived directly from the tool name as registered in OpenClaw.

Policy Examples Using Connector Types​

# Block web_fetch from sending data to non-approved domains
- name: "restrict-web-fetch-domains"
  connector_type: "openclaw.web_fetch"
  condition: "url NOT MATCHES '^https://(docs\\.internal\\.com|api\\.approved\\.com)'"
  action: "block"

# Require approval for any SQL execution
- name: "approve-sql-execution"
  connector_type: "openclaw.execute_sql"
  action: "require_approval"

# Redact PII in outbound messages (message_sending hook)
- name: "outbound-pii-redact"
  connector_type: "openclaw.message_sending"
  check_output: true
  pii_action: "redact"

Starter Policies​

OpenClaw is widely deployed with 135,000+ publicly exposed instances, 13+ CVEs disclosed in 2026 (multiple CVSS 9.8+), and the ClawHavoc supply chain attack poisoned 1,184 skills in ClawHub. The plugin repository includes research-backed starter policies addressing the top 10 OpenClaw security risks:

  • Reverse shell blocking: Detect and block nc -e, bash -i, /dev/tcp/, curl | sh, and other remote code execution patterns in exec tool arguments (Risk 1, CVE-2026-25253 vector)
  • Data exfiltration prevention: Block requests to cloud metadata endpoints (169.254.169.254) and internal networks for SSRF protection (Risk 2)
  • PII/secrets redaction in outbound messages: Automatically detect and redact SSNs, credit cards, API keys, and connection strings before delivery to users via AxonFlow's 76+ system policies (Risk 3)
  • Prompt injection detection: Scan ingested content for injection patterns before it enters the LLM context (Risk 4)
  • Outbound message scanning: Detect PII and secrets in messages before delivery to Telegram, Discord, or Slack channels (Risk 5)
  • Agent config file protection: Block writes to SOUL.md, MEMORY.md, and other OpenClaw identity files to prevent memory poisoning attacks (Risk 7)
  • Path traversal blocking: Detect ../, /etc/passwd, and other escape patterns that exploit workspace boundary bypass (Risk 10, CVE-2026-33573 vector)
  • Credential access blocking: Block cat ~/.ssh/, cat ~/.aws/, printenv SECRET, and similar credential exfiltration attempts (Risk 8)

See the policies directory in the plugin repository for ready-to-use SQL INSERT statements and configuration instructions.

Approval Workflow Integration​

When a tool is in the highRiskTools list and AxonFlow allows the call, the plugin returns a requireApproval response to OpenClaw. OpenClaw's native approval mechanism takes over from there, pausing tool execution and notifying the configured approval channel:

User: "Delete all inactive customer records from the database"
  │
  ▼
Agent selects: execute_sql
  │
  ▼
Plugin: before_tool_call → POST /api/v1/mcp/check-input
  │
  ├─ AxonFlow blocks → { block: true } → Agent receives block reason
  │
  └─ AxonFlow allows + tool in highRiskTools →
      │
      ▼
    Plugin returns: { requireApproval: { title, description, severity } }
      │
      ▼
    OpenClaw: Pauses execution, posts approval request to channel
      │
      ├─ Approve → Tool executes → Audit logged
      └─ Reject  → Agent receives rejection → Audit logged
      └─ Timeout (60s) → Denied (timeoutBehavior: "deny")

The approval request includes the tool name and a description noting how many AxonFlow policies were evaluated. The timeout defaults to 60 seconds with a "deny" behavior, meaning unanswered approval requests are rejected.

AxonFlow API Endpoints Used​

The plugin calls these AxonFlow endpoints. All requests use Basic auth (base64(clientId:clientSecret)):

EndpointPlugin MethodPurpose
POST /api/v1/mcp/check-inputbefore_tool_call hookEvaluate tool arguments against policies
POST /api/v1/mcp/check-outputmessage_sending hookScan outbound messages for PII and policy violations
POST /api/v1/audit/tool-callafter_tool_call, llm_output hooksRecord tool/LLM execution in audit trail
POST /api/v1/audit/searchclient.searchAuditEvents()Search individual audit records (v1.0.0+)
GET /api/v1/decisions/{id}/explainclient.explainDecision()Fetch full DecisionExplanation for an audited decision
POST /api/v1/overridesclient.createOverride()Create a governed session override with mandatory justification
DELETE /api/v1/overrides/{id}client.revokeOverride()Revoke an active override
GET /api/v1/overridesclient.listOverrides()List active overrides for the caller's tenant

HTTP 403 from check-input and check-output is treated as a policy block (not an auth error). The response body is deserialized normally to extract the block reason and the richer context fields (decision_id, risk_level, policy_matches, override_available, override_existing_id) used by the approval UX.

create_override requires an authenticated user identity, which the plugin threads through from OpenClaw's session; create_override, delete_override, explain_decision, and list_overrides are also available as MCP tools on the agent's MCP server for any agent that connects via /api/v1/mcp-server.

Error Handling​

The plugin supports configurable fail-open/fail-closed behavior via the onError option:

plugins:
  @axonflow/openclaw:
    onError: block  # "block" (fail-closed) or "allow" (fail-open)
  • onError: block (recommended for production): If AxonFlow is unreachable, tool calls are blocked. This is the safer default for security-sensitive deployments.
  • onError: allow: If AxonFlow is unreachable, tool calls are allowed through ungoverned. Use this for development where AxonFlow availability is less critical.

How each hook behaves when AxonFlow is unreachable:

  • before_tool_call: Blocks tool execution (if onError: block) or allows through (if onError: allow).
  • message_sending: Cancels the outbound message (if onError: block) or allows through ungoverned (if onError: allow).
  • after_tool_call: Audit failures are silently caught regardless of onError. Governance was already enforced in the before_tool_call hook.

This means governance enforcement respects your fail-open/fail-closed preference, but audit logging is always best-effort.

Use-Case Configuration Examples​

Different OpenClaw deployments need different governance profiles. Here are recommended configurations for common use cases.

DevOps / Coding Agent​

Heavy exec and process usage. Focus on dangerous command blocking and deploy approvals.

plugins:
  @axonflow/openclaw:
    endpoint: http://localhost:8080
    clientId: devops-agent
    # clientSecret: resolve from secret manager at runtime
    highRiskTools:
      - exec
      - process
    excludedTools:
      - get_current_time
      - list_models
    onError: block

Content / Social Media Agent​

Outbound message heavy. Focus on PII redaction and secret scanning before delivery.

plugins:
  @axonflow/openclaw:
    endpoint: http://localhost:8080
    clientId: content-agent
    # clientSecret: resolve from secret manager at runtime
    highRiskTools:
      - message
    governedTools:
      - message
      - web_fetch
    onError: block

Customer Support Agent​

Customer-facing on Slack/Discord/Telegram. Focus on PII redaction, approval for actions, and cost controls.

plugins:
  @axonflow/openclaw:
    endpoint: http://localhost:8080
    clientId: support-agent
    # clientSecret: resolve from secret manager at runtime
    highRiskTools:
      - message
      - execute_sql
      - send_email
    onError: block

Self-Healing Infrastructure Agent​

Highest risk — exec on production systems. Every action must be governed and approved.

plugins:
  @axonflow/openclaw:
    endpoint: http://localhost:8080
    clientId: infra-agent
    # clientSecret: resolve from secret manager at runtime
    highRiskTools:
      - exec
      - process
      - web_fetch
    onError: block  # never fail-open on production infrastructure

For cost management and compliance configuration, see Cost Management and Compliance Frameworks.

OpenClaw Security References​

SDKs: Python v8.0.0, TypeScript v8.0.0, Go v8.0.0, Java v8.0.0, Rust v0.2.0 (preview) | Platform: v7.9.0 | Plugin: v2.4.0

Last updated on