← Back to Skills Marketplace
🔌

AxonFlow Governance Policies

cross-platform ✓ Security Clean
229
Downloads
1
Stars
0
Active Installs
9
Versions
Install in OpenClaw
/install governance-policies
Description
Govern OpenClaw with AxonFlow — block dangerous commands, detect PII, prevent data exfiltration, protect agent config files, explain policy decisions, grant...
README (SKILL.md)

AxonFlow Governance Policies for OpenClaw

Use this skill when setting up, hardening, or operating an OpenClaw deployment with AxonFlow governance. It covers self-hosting AxonFlow, plugin installation, policy configuration, understanding why a tool call was blocked, granting a time-bounded override with mandatory justification, and building compliance-grade audit trails.

AxonFlow is self-hosted. It runs on your infrastructure via Docker Compose. All policy evaluation, PII detection, and audit logging happens on your own AxonFlow instance. Credentials are only needed for enterprise mode — community mode requires no auth. An anonymous startup ping (version and basic deployment info) is sent by default for local, self-hosted, and remote deployments. Opt out globally with DO_NOT_TRACK=1 or AXONFLOW_TELEMETRY=off.

When to use this skill

  • Setting up OpenClaw with AxonFlow for the first time.
  • A tool call got blocked and you want to know why.
  • You need to allow a specific blocked action for a short, audited window.
  • You are auditing agent behavior for compliance.
  • You are configuring per-user identity so AxonFlow attributes decisions correctly.
  • You are hardening an OpenClaw deployment against reverse shells, SSRF, PII leakage, or agent-config poisoning.

Self-Host AxonFlow

AxonFlow runs locally via Docker Compose. No LLM provider keys required — OpenClaw handles all LLM calls, AxonFlow only enforces policies and records audit trails.

Prerequisites: Docker Engine or Desktop, Docker Compose v2, 4 GB RAM, 10 GB disk.

Quick start: Clone the AxonFlow community repo, copy .env.example to .env, and run docker compose up -d. The Agent starts on port 8080 — all SDK and plugin traffic goes through this port.

Full setup instructions: Self-Hosted Deployment Guide

Install the Plugin

openclaw plugins install @axonflow/openclaw

The clawhub:@axonflow/openclaw form also works.

Requires OpenClaw 2026.4.14 or later and @axonflow/openclaw 1.3.1 or later (for X-User-Email forwarding on override endpoints). Upgrade the CLI with npm install -g openclaw@latest.

Note on the package name: the npm package is @axonflow/openclaw, not @axonflow/openclaw-plugin. The repo name differs from the package name.

Configure

Configure the plugin with your AxonFlow endpoint, credentials, and per-user identity:

endpoint:          http://localhost:8080           # AxonFlow agent gateway
clientId:          community                        # or your enterprise client id (defaults to "community")
clientSecret:      ""                               # leave empty in community mode; set in enterprise mode
userEmail:         [email protected]                # required for override + explain endpoints (v1.3.1+)
highRiskTools:     [web_fetch, exec]                # tools requiring human approval on allow
onError:           block                            # fail-closed in production, or "allow" for dev
requestTimeoutMs:  8000                             # raise when AxonFlow is remote/VPN

In community mode, clientId defaults to "community" and clientSecret can be left empty — no credentials needed for the local developer flow. In enterprise mode, provide OAuth2 Client Credentials (Basic auth) matching your tenant. Setting clientSecret without clientId is rejected by the config resolver — licensed mode must specify both.

userEmail (new in v1.3.1): per-user identity forwarded via the X-User-Email header. Required for client.createOverride(), client.revokeOverride(), client.listOverrides() (endpoints reject unauthenticated user identity with HTTP 401) and for correct per-user scoping on client.explainDecision(). If unset the client still works for block-path features but override lifecycle methods return 401.

Full configuration reference: OpenClaw Integration Guide

What's Protected Automatically

AxonFlow's 80+ built-in system policies apply with no additional setup:

  • Dangerous command blocking — 10 policies covering destructive operations, remote code execution, credential access, cloud metadata, path traversal
  • SQL injection — 30+ detection patterns covering advanced injection techniques
  • PII detection and redaction — SSN, credit card, email, phone, Aadhaar, PAN, NRIC/FIN (Singapore)
  • Code security — API keys, connection strings, hardcoded secrets, unsafe code patterns
  • Prompt manipulation — instruction override and context manipulation attempts

Examples of blocked patterns (all evaluated server-side by AxonFlow):

rm -rf /          → blocked by sys_dangerous_destructive_fs
curl ... | sh     → blocked by sys_dangerous_shell_download
nc -e /bin/bash   → blocked by sys_dangerous_reverse_shell
169.254.169.254   → blocked by sys_dangerous_cloud_metadata
cat ~/.ssh/id_rsa → blocked by sys_dangerous_credential_access
../../etc/passwd  → blocked by sys_dangerous_path_traversal

Understand a Block: Richer Context (v1.3.0+)

When AxonFlow blocks a tool call against platform v7.1.0 or later, the plugin surfaces structured context instead of a terse "policy violation" string. The block response carries:

  • decision_id — unique ID pinning the block to an audit row. Use it to fetch the full explanation or reference it in a support conversation.
  • risk_levellow / medium / high / critical (highest severity wins across matched policies).
  • policy_matches[] — every policy that matched, with policy_id, policy_name, action, risk_level, allow_override, and policy_description so the agent can render a specific reason instead of a generic block message.
  • override_available — true when at least one matched policy is overridable (non-critical, allow_override=true).
  • override_existing_id — set when the caller already has a live override on the blocking policy (check before creating a new one).

The hook stderr also carries a machine-readable suffix like [decision: \x3Cid>, risk: \x3Clevel>, active override: \x3Cid>] or a pointer to client.explainDecision(id) when no active override exists.

Explain a Decision

Fetch the full explanation for any previously-made decision:

import { AxonFlowClient } from '@axonflow/openclaw';
const client = new AxonFlowClient({ endpoint, clientId, clientSecret, userEmail });

const explanation = await client.explainDecision(decisionId);
// DecisionExplanation: { decision, reason, risk_level, policy_matches, matched_rules,
//                       override_available, override_existing_id,
//                       historical_hit_count_session, tool_signature, policy_source_link }

The shape is frozen per the explainability data contract (ADR-043). Access is scoped to the decision owner or same-tenant callers. Returns null on 404 or network failure so callers can fall back to a terse block message without crashing. See Explainability.

Grant a Session Override

For a policy that allow_override=true and is not critical-risk, grant a time-bounded override with mandatory free-text justification:

const override = await client.createOverride({
  policyId:       'sys_dangerous_shell_download',   // UUID or slug — both accepted
  policyType:     'static',                          // or 'dynamic'
  overrideReason: 'Approved by security — scripted install for pinned deployment',
  toolSignature:  'openclaw.exec:bash-script',       // optional: scope to one tool
  ttlSeconds:     1800,                              // optional: clamped to [60s, 24h], default 60m
});
// CreateOverrideResult: { id, policy_id, policy_type, expires_at, ttl_seconds,
//                         requested_ttl?, clamped?, clamped_reason?, created_at }

Platform-enforced invariants (per the session-override semantics contract):

  • TTL clamped to [1 min, 24 h]; default 60 min.
  • Critical-risk policies are never overridable — a DB trigger rejects the create with HTTP 403.
  • allow_override=false policies rejected with HTTP 403.
  • overrideReason is mandatory and captured on the audit row.
  • Four audit events per override lifecycle: override_created, override_used, override_expired, override_revoked.
await client.revokeOverride(override.id);
const active = await client.listOverrides({ policyId, includeRevoked: false });

See Session Overrides.

OpenClaw-Specific Hardening

For additional protection against OpenClaw-specific attack vectors, the plugin repository includes ready-to-use policy templates:

Command execution  → reverse shells, destructive filesystem ops, credential file access
SSRF prevention    → cloud metadata endpoints, internal network addresses
Agent config       → SOUL.md, MEMORY.md, identity file write protection
Path traversal     → workspace escape patterns

Full policy templates: Starter Policies

Top 10 Risks

Rank Risk Hook
1 Arbitrary command execution before_tool_call
2 Data exfiltration via HTTP before_tool_call
3 PII leakage in messages message_sending
4 Indirect prompt injection before_tool_call
5 Outbound secret exfiltration message_sending
6 Malicious skill supply chain after_tool_call (audit)
7 Memory/context poisoning before_tool_call
8 Credential exposure message_sending
9 Cross-tenant leakage Tenant-scoped policies
10 Workspace boundary bypass before_tool_call

Common Workflows

Debug a block

  1. Agent hits a block; capture decision_id from the block reason string.
  2. Call client.explainDecision(decisionId) to get the full reason, matched policies, risk level, and override availability.
  3. If override_available === true and the block is genuinely a false positive for your context, either fix the policy (permanent) or create a scoped override (temporary).

Grant a one-off allow

  1. Confirm the policy matched is not critical (risk_level !== 'critical' and allow_override === true).
  2. Call client.createOverride({ policyId, policyType, overrideReason, toolSignature, ttlSeconds }) with a specific justification text that will end up on the audit trail.
  3. Retry the tool call; the platform re-evaluates, flips deny → allow, emits an override_used event.
  4. Call client.revokeOverride(id) when the work window ends, or let the TTL expire.

Audit a session

  1. Call client.searchAuditEvents({ startTime, endTime }) to scan tool-call records.
  2. Filter the compliance-grade records by decision_id, policy_name, or override_id (platform v7.1.0+).
  3. Each record includes user, tool, matched policies, LLM prompt/response, latency, and token usage.

Guardrails

  • All policies are evaluated server-side by AxonFlow, not locally.
  • High-risk tools require human approval only after AxonFlow allows the tool call. If AxonFlow blocks, it stays blocked regardless of HITL configuration.
  • The plugin verifies AxonFlow connectivity on startup.
  • Overrides are per-user (via userEmail), tenant-scoped, and logged at every lifecycle event.

Learn More

Get Started

Policies & Security

Governance & Compliance

Platform & Examples

Source Code

Licensing

  • AxonFlow platform (getaxonflow/axonflow): BSL 1.1 (Business Source License). Source-available, not open source.
  • @axonflow/openclaw plugin (getaxonflow/axonflow-openclaw-plugin): MIT. Free to use, modify, and redistribute.
  • This skill: MIT-0 per ClawHub terms.
Usage Guidance
This SKILL.md appears to be what it says: a guide to self-host and integrate AxonFlow with OpenClaw. Before installing or enabling it in production: 1) be aware telemetry (an anonymous startup ping) is sent by default — set DO_NOT_TRACK=1 or AXONFLOW_TELEMETRY=off to opt out; 2) the plugin forwards X-User-Email for per-user overrides — only supply user emails if you accept that identity will be sent to your AxonFlow endpoint (and ensure that endpoint and logs are appropriately protected); 3) if using enterprise mode, keep clientSecret secure and follow your secrets-handling policy; 4) verify you are installing the expected npm package (@axonflow/openclaw) and the repo/package authorship before running installs; and 5) test the setup in an isolated/dev environment to confirm the blocking/explain/override behavior meets your policies and auditing needs.
Capability Analysis
Type: OpenClaw Skill Name: governance-policies Version: 1.5.2 The skill bundle provides documentation and configuration instructions for AxonFlow, a governance and security framework for OpenClaw. It focuses on hardening deployments by blocking dangerous commands, detecting PII, and maintaining audit trails. The content includes transparent disclosure of a telemetry ping with opt-out instructions (DO_NOT_TRACK=1) and provides legitimate workflows for managing policy overrides and decision explanations (SKILL.md).
Capability Assessment
Purpose & Capability
Name/description match the instructions: the SKILL.md explains installing an OpenClaw plugin, running a self-hosted AxonFlow via Docker Compose, configuring endpoint/credentials, and using override/explain endpoints. No unrelated binaries or credentials are requested.
Instruction Scope
Instructions stay within governance/setup scope (clone repo, docker compose up, openclaw plugins install, config fields). Notable behaviors documented in the instructions: an anonymous startup ping (version and basic deployment info) is sent by default, and per-user identity (userEmail) is forwarded in an X-User-Email header for override/explain endpoints. These are relevant privacy/telemetry implications but are described and opt-out options are provided.
Install Mechanism
This is an instruction-only skill (no install spec, no code files). The SKILL.md tells users how to install the OpenClaw plugin and run Docker Compose, which is appropriate for a governance integration. Nothing is downloaded implicitly by the skill itself.
Credentials
The skill declares no required env vars, which aligns with the community self-hosted flow. The doc mentions optional env flags (DO_NOT_TRACK/AXONFLOW_TELEMETRY) to opt out of telemetry and documents clientId/clientSecret for enterprise mode. Forwarding userEmail is required for some endpoints—this is functionally justified but increases privacy exposure and should be considered before enabling in production.
Persistence & Privilege
The skill does not request always:true or other elevated platform privileges. It instructs installing a plugin into OpenClaw (normal for this purpose) but does not itself modify system-wide agent settings or other skills' configs.
How to Use
  1. Make sure OpenClaw is installed (local or Docker)
  2. Run the install command in chat: /install governance-policies
  3. After installation, invoke the skill by name or use /governance-policies
  4. Provide required inputs per the skill's parameter spec and get structured output
Version History
v1.5.2
1.5.2 (2026-04-19) Major content expansion covering Plugin Batch 1 features shipped in @axonflow/openclaw v1.3.0 and v1.3.1. 1. New section - "Understand a Block: Richer Context" - documents the structured block response shape from platform v7.1.0+ (decision_id, risk_level, policy_matches[], override_available, override_existing_id) so agents render specific block reasons instead of generic "policy violation" strings. 2. New section - "Explain a Decision" - covers client.explainDecision(id) with the frozen DecisionExplanation shape (ADR-043). Links to the Explainability docs page. 3. New section - "Grant a Session Override" - covers client.createOverride / revokeOverride / listOverrides with platform-enforced invariants: TTL clamping (60s to 24h, default 60m), critical-risk rejection, allow_override=false rejection, mandatory justification, 4-event audit lifecycle. Links to the Session Overrides docs page. 4. New section - "Common Workflows" - canonical walkthroughs for: debug a block, grant a one-off allow, audit a session. 5. New section - "When to use this skill" - triggers that help the LLM decide to activate this skill (setup, debugging blocks, granting overrides, compliance audits, hardening). 6. New userEmail configuration guidance - required for override and explain endpoints in v1.3.1+. Added to the Configure block. 7. Community-mode config wording corrected - clientSecret can be left empty in community mode (the plugin's resolveConfig only defaults clientId to "community"; clientSecret stays the empty string unless set). Prior phrasing had implied both defaulted to "community", which overstated the actual runtime behavior. 8. Updated description and tags - added explainability, overrides, sqli, prompt-injection, llm-governance, agent-security, and data-loss-prevention for better discoverability. Total tag count now 19 (up from 12), covering capability (explainability, overrides, sqli, prompt-injection, pii, mcp), category (governance, llm-governance, agent-security, compliance, security, safety, data-loss-prevention), process (audit, approvals, human-in-the-loop, policies), and platform (openclaw, latest). 9. Removed the pre-2026.4.14 CLI workaround from the primary install flow - the upstream bug is fixed and the primary install command now works unconditionally. Minimum OpenClaw CLI required stated as 2026.4.14; minimum plugin version stated as 1.3.1 (for X-User-Email forwarding).
v1.5.1
- Updated plugin installation instructions for compatibility with OpenClaw 2026.4.14 or later. - Clarified that the recommended install command (including the `clawhub:` form) now works natively on supported OpenClaw versions. - Added upgrade guidance and made the workaround for older OpenClaw CLIs explicit. - No functional policy or core changes; documentation only.
v1.5.0
- Documentation updated with explicit OpenClaw plugin install instructions. - Added caveat and workaround for known OpenClaw CLI bug affecting scoped npm packages. - No changes to underlying functionality or configuration—core policies and hardening guidance remain the same.
v1.4.0
- Plugin configuration section updated: added the `requestTimeoutMs` override option for OpenClaw deployments with remote or slow AxonFlow instances. The default is 8000ms, and guidance is provided for increasing it when needed. - Telemetry note clarified: anonymous startup ping is now always sent by default for all deployment types (local, self-hosted, remote); opt-out instructions updated to include both DO_NOT_TRACK=1 and AXONFLOW_TELEMETRY=off. - Minor clarifications throughout to reflect the above operational changes and improve configuration guidance. - No code changes included in this release (documentation update only).
v1.3.0
- Documented telemetry behavior: clarified when anonymous startup pings are sent, default suppression for localhost, and how to globally opt out. - Highlighted that AxonFlow is always self-hosted and all policy enforcement/logging happens on your infrastructure. - Added info that credentials/auth are only required for enterprise mode; community mode needs no authentication. - No file or code changes—documentation update only.
v1.2.0
- Moved specific attack patterns and blocked commands into code fences to improve readability - Added policy ID references for each blocked pattern (e.g., `sys_dangerous_destructive_fs`) - No content removed — same coverage, better structure
v1.1.0
**Summary:** Updates to authentication configuration, policy details, and documentation clarity. - Simplified authentication: In community mode, no credentials required; in enterprise, use OAuth2 Client Credentials. The tenantId config field has been removed. - Policy count and coverage updated: 80+ built-in policies now documented, with expanded descriptions for PII detection, SQL injection, dangerous commands, prompt injection, and code security. - Configuration instructions clarified, including how authentication and deployment modes affect setup. - Documentation improved for accuracy and alignment with current AxonFlow and OpenClaw integration standards.
v1.0.1
- Simplified and condensed self-hosting, installation, and configuration instructions for AxonFlow and the OpenClaw plugin. - Moved detailed policy SQL examples and setup steps to documentation links, referencing ready-to-use policy templates. - Clarified features protected by default and focused OpenClaw-specific risks and protections into concise summaries. - Pruned outdated notes (e.g., async hook support, health check commands), emphasizing current plugin capabilities. - Added and reorganized links for deployment, policy templates, and governance features. - No code or functional changes; documentation streamlined for usability.
v1.0.0
Initial release of AxonFlow governance policies for OpenClaw. - Provides a detailed guide for setting up AxonFlow governance with OpenClaw, covering self-hosting, plugin installation, and configuration. - Includes default and custom security policies to block dangerous commands, reverse shells, PII leakage, path traversal, and data exfiltration. - Lists OpenClaw-specific hardening SQL policy templates for use with AxonFlow. - Documents top 10 OpenClaw abuse risks and associated policy hooks. - Offers links to deployment guides, policy syntax, compliance features, and further documentation. Archives: saurabhjain1592/axonflow-governance-policies skill
Metadata
Slug governance-policies
Version 1.5.2
License MIT-0
All-time Installs 0
Active Installs 0
Total Versions 9
Frequently Asked Questions

What is AxonFlow Governance Policies?

Govern OpenClaw with AxonFlow — block dangerous commands, detect PII, prevent data exfiltration, protect agent config files, explain policy decisions, grant... It is an AI Agent Skill for Claude Code / OpenClaw, with 229 downloads so far.

How do I install AxonFlow Governance Policies?

Run "/install governance-policies" in the OpenClaw or Claude Code chat to install it in one step — no extra setup required.

Is AxonFlow Governance Policies free?

Yes, AxonFlow Governance Policies is completely free, licensed under MIT-0. You can download, install and use it at no cost.

Which platforms does AxonFlow Governance Policies support?

AxonFlow Governance Policies is cross-platform and runs anywhere OpenClaw / Claude Code is available (cross-platform).

Who created AxonFlow Governance Policies?

It is built and maintained by AxonFlow: Runtime control layer for production AI (@axonflow); the current version is v1.5.2.

💬 Comments