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.
Coverage matrix verified against each integration's page on 2026-08-24. Each row below restates the "Governance coverage" box on the linked integration page; where a row and a page disagree, the page is authoritative.
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). From platform v9.7.0 the request plane goes further: when the policy engine cannot load its policies at all (for example a transient policy-store outage), the request is blocked regardless of the fail-open opt-in - on the request plane there is no safe middle ground between proceeding ungoverned and blocking. The response plane has failed closed on a policy-load error since v9.4.0.
- 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.
Decisions are keyed on request content, not on a managed connector: stage is recorded for audit and trace correlation and the target descriptor is accepted by the API, but neither scopes which policies run, and the per-connector controls of MCP governance (the static-policy connector allowlist and per-connector rate limits or budgets) are not applied here. For connector-scoped enforcement, govern that traffic through MCP governance; the two compose. See Decision Mode → Connector-agnostic evaluation.
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. Each row links to the integration page whose "Governance coverage" box it summarizes.
| Integration | Interception point | Governs |
|---|---|---|
| Claude Code | Hooks (PreToolUse / PostToolUse) on Bash, Write, Edit, NotebookEdit and every mcp__* tool | Tool calls before execution + check_output scan of tool results. Not prompt or completion text (no prompt hook is registered) |
| Claude Desktop | Local MCP governance proxy (.mcpb); Desktop has no hooks | MCP tools/call requests (deny, HITL hold, fail-closed) + PII redaction of tool responses. Not raw prompt text or chat that involves no MCP tool call |
| Cursor | Hooks (preToolUse / postToolUse, plus beforeShellExecution and afterFileEdit) on Shell, Write, Edit, Read, Task, NotebookEdit and mcp__* | Tool calls before execution + check_output scan of tool results. Not prompt or completion text |
| OpenAI Codex | Hooks on the shell path only (Bash / exec_command / shell) + advisory skills for other tools | Enforced: shell commands before execution, with audit + PII scan after. File edits, MCP tools and prompt content are covered only advisorily (the agent may ignore the guidance) |
| OpenClaw | Plugin hooks: before_tool_call, message_sending (can block); after_tool_call, llm_input, llm_output (observe-only) | Tool calls before execution + outbound messages before delivery. LLM input/output is audited, not blocked; tool results entering the model context are not scanned |
| Google ADK | BasePlugin (AxonFlowPlugin) registered on the ADK Runner | Every model call on that Runner (before_model_callback pre-check can deny, so model-bound content is policy-checked), tool inputs and tool outputs, HITL gates. Model responses are audited only; sub-agents invoked via AgentTool are not covered; fail-open by default |
| n8n | Explicit AxonFlow node (or stock HTTP nodes) you place in the workflow; a WCP-style step gate, not an automatic interceptor | The steps where the node is placed (opt-in per workflow): a checkPolicy gate before the guarded action, audit recording, and HITL waitForApproval. Ungated steps run without any policy check |
| LangGraph | SDK adapter (wrap_langgraph() in Python, a callback handler, or a governed-node factory) on Gateway Mode | Node transitions: a gate before each wrapped node and a completion record after, plus optional per-tool gates. Steps that bypass a wrapped node are not governed |
| LangChain | SDK adapters AxonFlowChatModel (model) and GovernedTool (tools), opt-in | Async LLM calls (ainvoke / astream) through AxonFlowChatModel are policy-checked and raise on deny; tool input and output through GovernedTool. Synchronous invoke / stream on AxonFlowChatModel pass through without a policy check |
| CrewAI | App-to-SDK boundary (Gateway Mode) wrapper around the crew or task + GovernedTool on LangChain tools; no CrewAI-native adapter | Only what you wrap: the crew inputs or task description you pre-check, and governed tool input/output. Nothing is intercepted automatically |
| 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 + results), reaching more than MCP-only because they also see native shell and file tools (Codex: shell commands only), but they do not intercept prompt content; MCP-proxy and gateway integrations govern the tool/data path; app-SDK integrations govern exactly what you wrap. Among the rows above, Google ADK's BasePlugin and LangChain's async AxonFlowChatModel path policy-check model-bound content; beyond this table, LiteLLM in wrapper mode and agentgateway's ext_proc / ExtMcp callouts also send prompt and tool content to the engine and can deny or redact it. 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.
