Runtime governance for Claude Code: block dangerous commands before they run, scan every tool output for PII and secrets, and keep a compliance-grade audit trail — without leaving your terminal.
→ Full integration walkthrough: docs.getaxonflow.com/docs/integration/claude-code — architecture, policy examples, latency numbers, troubleshooting, and the 10 MCP tools the platform exposes.
Upgrade strongly recommended. AxonFlow ships substantial monthly security and quality hardening; staying on the latest major is the security-supported release line. Latest release · Security advisories
Claude Code is Anthropic's official CLI — a fast, agentic coding assistant that edits files, runs shell commands, and calls MCP servers. It's excellent at developer productivity. It was never designed to be the layer where your security and compliance team lives.
The gaps start surfacing the moment Claude Code moves from one developer's laptop to a team or production setting:
| Production requirement | Claude Code alone | With this plugin |
|---|---|---|
| Policy enforcement before tool execution | Hooks available, no governance logic | 80+ built-in policies evaluated on every governed tool call |
Dangerous command blocking (rm -rf /, reverse shells, curl | bash) |
Not addressed | Blocked before execution with decision context |
| PII / secrets detection in tool outputs | Developer responsibility | Auto-scan; Claude is instructed to use redacted version |
| SQL-injection detection on MCP queries | MCP server's problem | 30+ patterns evaluated on every MCP tool call |
| Compliance-grade audit trail | Session logs, not compliance-formatted | Every governed call recorded with policies, decision, duration |
| Decision explainability after a block | Generic hook failure message | decision_id surfaced in deny reason; explain_decision MCP tool returns the full record |
| Self-service, time-bounded exceptions | Not available | create_override with mandatory justification, fully audited |
| Cloud metadata / SSRF / path traversal blocking | Not addressed | Built in |
You get all of that with zero change to how developers use Claude Code. Hooks fire automatically, the deny message tells you why, MCP tools are there when you want to investigate or unblock yourself.
Claude selects a tool (Bash, Write, Edit, NotebookEdit, mcp__*)
│
▼
PreToolUse hook fires automatically
│ → check_policy("claude_code.Bash", "rm -rf /")
│
├─ BLOCKED → Claude receives denial reason with decision_id + risk_level,
│ can call explain_decision / create_override to unblock
│
└─ ALLOWED → Tool executes normally
│
▼
PostToolUse hook fires automatically
│ → audit_tool_call(tool, input, output) [non-blocking]
│ → check_output(tool result for PII/secrets)
│
├─ Sensitive data found → Claude instructed to use
│ redacted version in its reply
└─ Clean → Silent
Governed tools: Bash, Write, Edit, NotebookEdit, and all MCP server tools (mcp__*). Read-only tools (Read, Glob, Grep) are not governed by default — they don't modify state or send data externally.
Fail behavior:
- AxonFlow unreachable (network) → fail-open, tool execution continues
- AxonFlow auth/config error → fail-closed, tool call denied until config is fixed
- PostToolUse failures → never block (audit and PII scan are best-effort)
A developer connects an MCP server to a production database for debugging. Claude Code queries customer records. Results flow through the conversation with PII intact. Session logs exist but they aren't structured for compliance queries.
With the plugin: check_policy fires before the MCP query runs (SQL injection scan, policy scan), check_output scans the result for SSN / credit card / email / phone / API keys, and audit_tool_call records the full interaction with matched policies and decision ID.
A developer types "fix the database issue." Claude Code picks a Bash tool and runs a migration against prod. The command ran because nothing stopped it.
With the plugin: a dynamic policy scoped to production patterns matches, the call is denied with a decision ID, and Claude surfaces the deny reason in the REPL. A developer can call explain_decision to see exactly which policy family triggered, then create_override with justification if they have the authority — all without leaving the session.
A team wants to deploy Claude Code at scale and security says no: "No policy enforcement on MCP queries, PII flows through conversations unchecked, bash commands aren't governed, audit trail isn't compliance-ready, no approval gates."
With the plugin: every one of those gaps is filled at the plugin layer. The productivity surface doesn't change.
We're opening limited Plugin Design Partner slots.
30-minute hook lifecycle review, policy pack scoping, override workflow design, and IDE/CLI rollout pattern walkthrough — for solo developers and small teams putting governance on Claude Code.
Apply here or email design-partners@getaxonflow.com. Personal email is fine — solo developers welcome.
Three short videos covering different angles of the platform:
- Community Quickstart Demo (Code + Terminal, 2.5 min) — governed calls, PII block, Gateway Mode with LangChain/CrewAI, and MAP from YAML
- Runtime Control Demo (Portal + Workflow, 3 min) — approvals, retry safety, execution state, and the audit viewer
- Architecture Deep Dive (12 min) — how the control plane works, policy enforcement flow, and multi-agent planning
Outgrown Community on a real plugin install? Evaluation unlocks the capacity and features that matter for plugin users — without moving to Enterprise yet:
| Capability | Community | Evaluation (Free) | Enterprise |
|---|---|---|---|
| Tenant policies | 20 | 50 | Unlimited |
| Org-wide policies | 0 | 5 | Unlimited |
| Audit retention | 3 days | 14 days | Up to 10 years |
| HITL approval gates | — | 25 pending, 24h expiry | Unlimited, 24h |
| Evidence export (CSV/JSON) | — | 5,000 records · 14d window · 3/day | Unlimited |
| Policy simulation | — | 300/day | Unlimited |
| Session overrides (self-service unblock) | — | — | Enterprise-only |
Org-wide policies and session overrides are Enterprise-only — those are the actual upgrade triggers for plugin users.
Get a free Plugin Evaluation license
Read before installing. AxonFlow Community SaaS at try.getaxonflow.com is the zero-config endpoint the plugin uses if neither AXONFLOW_ENDPOINT nor AXONFLOW_AUTH is configured. In that mode, governed tool inputs (tool name + arguments) and outbound message bodies are checked by AxonFlow's policy enforcement endpoint. Community SaaS is for early exploration only — not for production workloads, regulated environments, real user data, personal data, or any other sensitive information. It is offered "as is" on a best-effort basis with no SLA, no warranties, and no commitment to retention, deletion, or incident-response timelines.
For any serious use, choose one of the following instead:
- Self-host AxonFlow Community Edition — runs entirely on your infrastructure and keeps data within your boundary. Recommended for any real workload. The in-README quick start is in Step 1 below.
- 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.
- AxonFlow Enterprise — production-grade governance, regulatory-grade controls, SLOs, and contractual commitments suitable for regulated industries. Contact hello@getaxonflow.com.
To skip Community SaaS entirely: set AXONFLOW_ENDPOINT to a self-hosted AxonFlow URL. That alone flips the plugin into self-hosted mode — the Community SaaS auto-bootstrap is not attempted, and no env var is required. Get the AxonFlow platform from getaxonflow/axonflow and follow the Getting Started guide for the Docker Compose setup. For air-gapped environments where AxonFlow is not yet reachable but you want to suppress the bootstrap attempt, set AXONFLOW_COMMUNITY_SAAS=0; set AXONFLOW_TELEMETRY=off to also disable the anonymous 7-day heartbeat.
LLM provider keys never leave the user's machine in any mode — Claude Code makes the LLM calls; AxonFlow only enforces policies and records audit trails.
This is a three-step install: stand up the AxonFlow platform, add the plugin to Claude Code, then point the plugin at the platform. The plugin alone does not enforce policy — its hook scripts are thin clients that talk to an AxonFlow agent gateway. If the platform is not installed and reachable, governed tool calls have nothing to evaluate against. Skipping Step 3 is the most common mistake: the platform is running locally but the plugin still falls back to Community SaaS because no AXONFLOW_ENDPOINT is configured.
For any real workload, run AxonFlow on your own infrastructure via Docker Compose:
git clone https://github.com/getaxonflow/axonflow.git
cd axonflow && docker compose up -d
# verify
curl -s http://localhost:8080/health | jq .Follow the Getting Started guide for prerequisites (Docker Engine or Desktop, Docker Compose v2, 4 GB RAM, 10 GB disk) and the Self-Hosted Deployment Guide for production options. For production with real users or clients, run Community Edition with a free 90-day Evaluation License or AxonFlow Enterprise.
Skipping Step 1 makes the plugin fall back to the Community SaaS endpoint at
try.getaxonflow.comfor early exploration only. Do not skip Step 1 for any real workload — see the Privacy notice above.
Add this repo as a custom marketplace (recommended):
/plugin marketplace add getaxonflow/axonflow-claude-plugin
/plugin install axonflow
Or load locally for testing:
git clone https://github.com/getaxonflow/axonflow-claude-plugin.git
claude --plugin-dir /path/to/axonflow-claude-pluginThe plugin has been submitted to the official Anthropic marketplace (
anthropics/claude-plugins-official) and is currently in Anthropic's review queue. Until it appears in/plugin > Discover, use one of the install methods above.
Without this step the plugin auto-registers with Community SaaS regardless of whether you ran Step 1 — it does not auto-detect a locally-running AxonFlow. Set AXONFLOW_ENDPOINT (and AXONFLOW_AUTH if you have credentials):
# Self-hosted local agent — that alone flips mode to self-hosted, no other env var needed
export AXONFLOW_ENDPOINT=http://localhost:8080
# Self-hosted remote agent with credentials
export AXONFLOW_ENDPOINT=https://axonflow.your-company.com
export AXONFLOW_AUTH=$(echo -n "your-client-id:your-client-secret" | base64)Every hook invocation logs a one-line canary on stderr confirming the active mode:
[AxonFlow] Connected to AxonFlow at http://localhost:8080 (mode=self-hosted)
If the canary says mode=community-saas after you ran Step 1, the plugin is still hitting try.getaxonflow.com because Step 3 was skipped or AXONFLOW_ENDPOINT is unset. Fix Step 3 and reload.
Run /axonflow-status from any Claude Code session to see your tenant_id, the resolved AxonFlow endpoint, and current tier (Free vs Pro):
OK endpoint=https://try.getaxonflow.com
OK tenant_id=cs_a1b2c3d4-...
OK tier=Free
OK license_token=unset
OK upgrade_url=https://getaxonflow.com/pro
Paste your tenant_id above into the 'AxonFlow tenant ID' custom field at checkout.
The tenant_id is the value to paste into the AxonFlow tenant ID custom field at Stripe checkout when upgrading to AxonFlow Pro. The license token is always shown redacted (set (AXON-...XXXX)) — the full bearer credential is never printed, so the output is safe to screen-share or paste into a support ticket.
The recommended self-hosted path is covered in Install Step 1. Two more modes worth knowing about:
The plugin's zero-config fallback when neither AXONFLOW_ENDPOINT nor AXONFLOW_AUTH is configured. The plugin registers a tenant with try.getaxonflow.com on first run and persists credentials at ~/.config/axonflow/try-registration.json (mode 0600).
Use only for early exploration of the plugin's behaviour. Not for production workloads, regulated environments, real user data, personal data, or any other sensitive information.
What goes to try.getaxonflow.com |
What does NOT |
|---|---|
| Tool name + arguments before each governed call | LLM provider API keys |
| Outbound message bodies before delivery (PII/secret scan) | Claude Code conversation history outside governed tools |
| Anonymous 7-day heartbeat (plugin version, OS, runtime) | Files outside the Claude Code runtime |
The endpoint runs against shared Ollama models, rate-limits at 20 req/min · 500 req/day per tenant, and is offered "as is" on a best-effort basis with no SLA, no warranties, no commitment to retention or deletion timelines, and may be modified or discontinued without notice. Read the Try AxonFlow — Free Trial Server page for the full disclosure, including data retention and registration mechanics.
For environments where no outbound traffic is permitted at all — air-gapped labs, regulated networks, classified deployments — set both env vars before the Claude Code process starts:
export AXONFLOW_COMMUNITY_SAAS=0 # disable Community SaaS auto-bootstrap
export AXONFLOW_TELEMETRY=off # disable the anonymous 7-day heartbeat
export AXONFLOW_ENDPOINT=http://your-internal-axonflow:8080With both env vars set and AXONFLOW_ENDPOINT pointing at a same-network instance, no traffic leaves your environment.
Step 3 above covers AXONFLOW_ENDPOINT and AXONFLOW_AUTH. Other connection options:
# Self-hosted local agent
export AXONFLOW_ENDPOINT=http://localhost:8080
# Self-hosted remote agent with credentials
export AXONFLOW_ENDPOINT=https://axonflow.your-company.com
export AXONFLOW_AUTH=$(echo -n "your-client-id:your-client-secret" | base64)
# Default (Community SaaS) — leave both unset
unset AXONFLOW_ENDPOINT AXONFLOW_AUTH
# Optional: increase hook timeout for remote / VPN'd deployments
# (PreToolUse default 8s, PostToolUse default 5s)
export AXONFLOW_TIMEOUT_SECONDS=12When AXONFLOW_AUTH is unset and AXONFLOW_ENDPOINT is unset, the plugin defaults to AxonFlow Community SaaS — no further configuration needed.
AxonFlow ships with 80+ built-in system policies that apply to Claude Code automatically. No configuration required — new policies added to the platform are immediately enforced in every session.
| Category | Coverage |
|---|---|
| Dangerous commands | Reverse shells (nc -e, bash -i, /dev/tcp/), rm -rf /, dd if=, curl | bash, credential file access (cat ~/.ssh/, cat ~/.aws/), path traversal |
| SQL injection | 30+ patterns including UNION injection, stacked queries, auth bypass, encoding tricks |
| PII detection | SSN, credit card, Aadhaar, PAN, email, phone, NRIC/FIN (Singapore), and more — with redaction |
| Secrets exposure | API keys, connection strings, hardcoded credentials, code secrets |
| SSRF | Cloud metadata endpoint (169.254.169.254) and internal-network blocking |
| Prompt injection | Instruction override, jailbreak attempts, role hijacking |
| Claude Code-specific | .claude/settings.json write protection, .claude/hooks/*.json modification warnings (enabled via AXONFLOW_INTEGRATIONS=claude-code) |
Custom policies are easy — POST /api/v1/dynamic-policies or the Customer Portal. See Policy Enforcement.
In addition to automatic hooks, the agent's MCP server exposes 10 tools Claude can call directly. All served by the platform at /api/v1/mcp-server — the plugin's .mcp.json just points Claude there. New platform tools are immediately available.
| Tool | Purpose |
|---|---|
check_policy |
Evaluate specific inputs against policies |
check_output |
Scan specific content for PII/secrets |
audit_tool_call |
Record an additional audit entry |
list_policies |
List active governance policies (system + tenant) |
get_policy_stats |
Summary of governance activity |
search_audit_events |
Search individual audit records for debugging and compliance evidence |
| Tool | Purpose |
|---|---|
explain_decision |
Return the full DecisionExplanation for a decision ID |
create_override |
Create a time-bounded, audit-logged session override (mandatory justification) |
delete_override |
Revoke an active session override |
list_overrides |
List active overrides scoped to the caller's tenant |
The inline-unblock workflow: a policy block → the deny reason includes decision_id and risk_level → the developer asks Claude to call explain_decision → if the decision is overridable, create_override unblocks with justification. No separate admin surface, full audit trail.
See Session Overrides.
| Operation | Typical overhead |
|---|---|
| Policy pre-check | 2–5 ms |
| PII detection | 1–3 ms |
| SQL-injection scan | 1–2 ms |
| Audit write (async) | 0 ms (non-blocking) |
| Total per-tool overhead | 3–10 ms |
Imperceptible in interactive Claude Code sessions.
Same governance platform, same 80+ policies, same 10 MCP tools — different agent hosts:
| Integration | Repo | Docs |
|---|---|---|
| Claude Code | this repo | claude-code |
| Anthropic Computer Use | Docs-only integration (uses the Agent SDK pattern) | computer-use |
| Claude Agent SDK | Docs-only integration | claude-agent-sdk |
| Cursor IDE | axonflow-cursor-plugin | cursor |
| OpenAI Codex | axonflow-codex-plugin | codex |
| OpenClaw | axonflow-openclaw-plugin | openclaw |
axonflow-claude-plugin/
├── .claude-plugin/
│ ├── plugin.json # Plugin metadata
│ └── marketplace.json # Marketplace listing
├── .mcp.json # MCP server connection (points at the platform)
├── hooks/
│ └── hooks.json # PreToolUse + PostToolUse hook definitions
├── scripts/
│ ├── pre-tool-check.sh # Policy enforcement before tool execution
│ ├── post-tool-audit.sh # Audit + PII scan after execution
│ ├── mcp-auth-headers.sh # Basic-auth header generation for MCP
│ └── telemetry-ping.sh # Anonymous telemetry (fires once per install)
└── tests/
├── test-hooks.sh # Hook regression (mock server)
├── E2E_TESTING_PLAYBOOK.md
└── e2e/ # Smoke E2E against live AxonFlow
# Hook regression tests (no live stack required)
./tests/test-hooks.sh
# Smoke E2E against a live AxonFlow at localhost:8080
bash tests/e2e/smoke-block-context.shThe smoke scenario installs the plugin's pre-tool-check.sh against a running platform, feeds a SQLi-bearing Bash tool invocation through it, and asserts the hook returns the permissionDecision: deny shape with the richer-context markers (decision:, risk:) in the reason text. Exits 0 with SKIP: if no stack is reachable. Run in CI via workflow_dispatch when a reachable endpoint is configured.
For the broader validation story — explain-decision, override lifecycle, audit-filter parity, cache invalidation — see the Claude Code integration guide and the governance test scenarios documentation.
Anonymous heartbeat at most once every 7 days per machine: plugin version, OS, architecture, bash version, AxonFlow platform version, deployment mode (community-saas / self-hosted production / self-hosted development). Never tool arguments, message contents, or policy data. The stamp file mtime advances only after the HTTP POST returns 2xx, so a transient network failure does not silence telemetry until the next window.
Opt out: set AXONFLOW_TELEMETRY=off in the environment Claude Code runs in.
DO_NOT_TRACK is not honored as an opt-out for AxonFlow telemetry. It is commonly inherited from host tools and developer environments — and in Claude Code specifically, the CLI injects DO_NOT_TRACK=1 into every hook subprocess regardless of user intent. That makes it an unreliable expression of user intent, so AxonFlow telemetry is controlled exclusively by AXONFLOW_TELEMETRY=off.
Guarded by a stamp file at $HOME/.cache/axonflow/claude-code-plugin-telemetry-sent (delete to re-send). Details: docs.getaxonflow.com/docs/telemetry.
- Claude Code Integration Guide — the full walkthrough (recommended starting point)
- AxonFlow Documentation
- Policy Enforcement
- Decision Explainability
- Session Overrides
- Self-Hosted Deployment
- Security Best Practices
- Anthropic Computer Use Integration
- Claude Agent SDK Integration
- AxonFlow source
MIT