How AxonFlow Governs — Architecture & Coverage
AxonFlow is a policy plane for AI execution. It sits at the point where an agent, model, or workflow is about to do something consequential — call a tool, hit an LLM, run a workflow step — and it decides, enforces, redacts, and records that action against your policies. This page explains the one model that underlies every integration, the five ways you can wire it in, and exactly what each integration covers.
First-cut page — the governed-call lifecycle, the five modes with sequence diagrams, and the coverage matrix. The per-integration matrix rows are being individually verified against each integration's code; treat any single row as indicative until the integration's own page confirms it.
The governed-call lifecycle (one model, everywhere)
Whatever the integration, the same lifecycle runs on every consequential action:
Three properties hold across all modes:
- Decision before action — policy is evaluated before the call lands on a real system.
- Fail-closed — if the policy service is unreachable, the action is blocked by default (opt-in fail-open).
- One audit trail — every decision is recorded with a
decision_idand a W3Ctrace_id, so multi-step or multi-layer flows correlate end to end (SIEM-ready).
The split that makes this work is PEP / PDP: AxonFlow is the Policy Decision Point (it returns a verdict), and the integration is the Policy Enforcement Point (it acts on the verdict). How the PEP is wired is what distinguishes the five modes below.
The five modes
| Mode | Who calls AxonFlow | Traffic path | Best for |
|---|---|---|---|
| Decision Mode | Your infra gateway | Client → gateway → target (verdict checked inline) | Gateway-level enforcement with no app-code changes |
| Gateway | Your app code (SDK) | App → LLM (direct) | Adding governance to an existing app/framework, least invasive |
| Proxy | Your app code (one call) | App → AxonFlow → LLM | New apps wanting AxonFlow to own routing + the LLM call |
| MAP (Multi-Agent Planning) | Your app code | App → AxonFlow plans + executes | Decomposing a request into a governed multi-step plan |
| WCP (Workflow Control Plane) | Your external orchestrator | Orchestrator → AxonFlow gates each step | Step-level gates beside LangGraph / n8n / Temporal |
Decision Mode — gateway-level governance, no app changes
Your infrastructure gateway (LLM gateway, MCP gateway, agent router) asks AxonFlow for a verdict on each request and enforces it locally. AxonFlow is never on the traffic path — it's consulted for decisions only. This is the lowest-touch way to govern many apps at once: engineers don't change application code; the gateway does the enforcing.
Endpoint: POST /api/v1/decide (stage = llm / tool / agent). Reference PEP adapters ship for LLM, MCP (tools/call), and agent gateways. See Decision Mode.
Gateway Mode — govern an existing app, keep your LLM call
Your app calls AxonFlow to get a policy-approved context before the LLM call, makes the LLM call itself (with its own credentials), then sends an audit record after. Least invasive — the app keeps ownership of the model call.
Endpoints: POST /api/policy/pre-check, POST /api/audit/llm-call. See Gateway Mode.
Proxy Mode — AxonFlow owns the full lifecycle
Your app sends the request to AxonFlow, which evaluates policy, routes to the provider, makes the LLM call, filters the response, and records the audit — automatically. Best for new apps without existing LLM plumbing.
Endpoint: POST /api/request. See Proxy Mode.
MAP — Multi-Agent Planning
AxonFlow decomposes a natural-language request into a multi-step plan, then executes the steps with a policy decision at each step, with replay/resume and optional approval gates.
WCP — Workflow Control Plane
Your external orchestrator (LangGraph, n8n, Temporal, Airflow) keeps running the workflow; AxonFlow adds a gate before each step and a completion record after, plus checkpoints and approvals — without replacing the orchestration engine.
Coverage by integration
The interception point — where AxonFlow plugs in — differs by integration, and that determines what each one can govern. (Rows being verified per-integration; see each integration's page.)
| Integration | Interception point | Governs |
|---|---|---|
| Claude Code | Hooks (PreToolUse / PostToolUse) | Tool calls (incl. Bash/Write/Edit + mcp__*) + response scan; reaches more than MCP-only because hooks see every tool |
| Claude Desktop | Local MCP proxy (.mcpb) | MCP tool calls + responses. Not raw prompt text (Desktop has no prompt hook) — see Claude Desktop |
| Cursor / Codex | Hooks | Tool calls + responses |
| openclaw | Plugin | Tool/command layer |
| Google ADK | BasePlugin on the Runner | Every model + tool call across the agent fleet |
| n8n | WCP gate per step | Workflow step layer |
| LangGraph | WCP adapter | Node/step layer |
| LangChain / CrewAI | SDK wrapper (Gateway Mode) | Model + tool calls you wrap |
| SDKs (Go/Python/TS/Java) | Native SDK | Whatever you wire — Gateway / Proxy / WCP |
| Any infra gateway | Decision Mode (/api/v1/decide) | Whatever traffic the gateway fronts (LLM / MCP / agent) |
A useful rule of thumb: hook-based integrations (Claude Code, Cursor, Codex) govern the tool surface (tool calls + responses) — reaching more than MCP-only because they also see native Bash/Write/Edit tools, but they do not currently intercept prompt content; MCP-proxy and gateway integrations govern the tool/data path; app-SDK integrations govern exactly what you wrap. Pick the interception point that covers the surface you care about.
Choosing a mode
- Want to govern many apps at once without changing their code? → Decision Mode at your gateway.
- Have an existing app/framework and want the lightest touch? → Gateway Mode.
- Building a new app and happy for AxonFlow to own the LLM call? → Proxy Mode.
- Decomposing natural-language requests into governed steps? → MAP.
- Already run an orchestrator and want step-level gates beside it? → WCP.
See Choosing a mode and the Runtime surface map for the full decision tree.
