Governance Architecture and Coverage
AxonFlow can govern a model request, tool call, or workflow step at several different boundaries. The boundary matters: a policy decision returned to your gateway is not the same as an AxonFlow-managed provider call, and a WCP step gate is not the same as a MAP execution.
This page compares governance coverage across the same seven paths listed in Runtime Request Paths. Use Choosing an Integration Mode when you need a recommendation rather than a control-by-control comparison.
One Policy Plane, Different Enforcement Points
Every path uses AxonFlow policy and audit capabilities, but the component that enforces a decision changes.
Do not assume every box is automatic on every path:
- In Decision Mode, Gateway Mode, MCP governance, and WCP, your gateway, application, MCP host, connector, or orchestrator remains an enforcement point. It must honor the result and perform the real action only when permitted.
- In Proxy Mode and MAP, AxonFlow owns execution, so policy evaluation and execution records can remain in one managed flow.
- With Direct Orchestrator access, coverage depends on the endpoint selected and on the authentication, identity, and audit context supplied by the caller.
- Response or tool-output governance exists only where the path submits that output to AxonFlow or AxonFlow owns the execution that produces it.
Complete Coverage Matrix
| Path | Execution owner | Primary enforcement point | Request or step policy | Output governance | Record created automatically | Caller responsibility |
|---|---|---|---|---|---|---|
| Decision Mode | Your infrastructure gateway | Gateway | Decision returned before forwarding | Only through a returned obligation and a separate AxonFlow check | Policy decision and trace context | Enforce verdict, fulfill supported obligations, and retain downstream action context |
| Gateway Mode | Your application | Application code | Pre-check before the provider call | Not automatic for the direct provider response | Pre-check decision; LLM-call record only after the audit call | Stop on deny or hold, make the provider call, and reliably submit the audit |
| Proxy Mode | AxonFlow | Agent and Orchestrator | Applied in the managed request flow | Applied where the selected request path supports response controls | Managed request, policy, usage, and audit records | Supply correct identity, request type, provider context, and retry behavior |
| MCP governance | Your MCP host or connector | MCP host, managed connector, or MCP server | Input and connector-scoped checks before tool execution | Explicit output check can scan or redact tool results | MCP policy and audit records for submitted checks | Gate execution and submit output before returning it when output controls are required |
| MAP | AxonFlow | Orchestrator | Plan and step policy within AxonFlow-managed execution | Step-specific, based on the executor and connector path used | Plan, version, step, approval, and execution records | Supply the objective and monitor or resume the managed plan lifecycle |
| WCP | Your external orchestrator | External orchestrator | Explicit gate before each governed step | Step result is recorded through the completion call; use MCP checks for tool-output scanning | Workflow, gate, completion, checkpoint, and approval records for submitted lifecycle calls | Model every governed step, honor the gate, execute it, and submit completion or failure |
| Direct Orchestrator | Depends on selected API | Trusted internal caller plus Orchestrator | Depends on /process, MAP, WCP, or another selected endpoint | Depends on selected endpoint and explicit checks | Endpoint-specific | Protect :8081, propagate identity, select the right endpoint, and wire retries and audit context |
AxonFlow policy handlers fail closed where documented, but caller-owned paths still depend on the caller enforcing the returned result and handling an unavailable AxonFlow service safely. Treat each endpoint's error contract as authoritative. Do not infer that an SDK wrapper, framework hook, or external gateway has the same failure behavior as the underlying service.
Caller-Owned Execution
These four paths keep the real action outside AxonFlow.
Decision Mode
An infrastructure gateway calls POST /api/v1/decide and receives allow, deny, or needs_approval plus any obligations. The gateway is the policy enforcement point.
Decision Mode evaluates the submitted content. It does not automatically execute the target, capture the target response, or apply connector-scoped controls. Use MCP governance alongside it when connector_type policies or tool-output checks matter.
See Decision Mode and Building a Policy Enforcement Point.
Gateway Mode
Application code calls POST /api/policy/pre-check, calls the provider directly when permitted, then reports the result through POST /api/audit/llm-call.
The pre-check decision is automatic. Provider-call evidence is only as complete as the application's audit submission, and the direct provider response is not automatically passed through a generic AxonFlow response filter.
See Gateway Mode.
MCP Governance
An MCP host, managed connector, or MCP server submits tool input and output through:
POST /api/v1/mcp/check-inputPOST /api/v1/mcp/check-output/api/v1/mcp-serverfor MCP server transport
This is the path for per-connector policies because the request carries connector_type. It can be combined with Decision, Gateway, Proxy, MAP, or WCP.
See MCP Policy Enforcement and the Connector Capability Matrix.
Workflow Control Plane
An external orchestrator creates a workflow record, calls a step /gate endpoint before execution, and calls /complete after execution. WCP adds governance state around an external runtime; it does not replace that runtime.
Approval decisions can be returned across tiers, but new queue-backed approval entries require Professional or above. Evaluation exposes resolve-only approval endpoints for draining entries created under a qualifying license; Community and Evaluation do not create new queue entries.
See Workflow Control Plane and HITL Approval Gates.
AxonFlow-Managed Execution
These paths keep policy and the real execution inside AxonFlow.
Proxy Mode
Application code calls Agent POST /api/request. The Agent authenticates and validates the request, then sends ordinary model processing to Orchestrator POST /api/v1/process. AxonFlow owns provider routing and the governed request lifecycle.
Proxy Mode is the strongest default when a new application wants automatic provider-call and usage records without maintaining a separate pre-check and audit pair.
See Proxy Mode.
Multi-Agent Planning
MAP uses /api/v1/plan, /api/v1/plan/execute, and plan lifecycle routes. AxonFlow generates, stores, and executes the plan, including step-level state and enabled approval behavior.
Use MAP when AxonFlow should own planning. If your application supplies a predefined workflow for AxonFlow to execute, use POST /api/v1/workflows/execute; if an external engine executes each step, use WCP.
See Multi-Agent Planning Overview and the Workflow and MAP API.
Advanced Service Access
Direct Orchestrator
Direct access to Orchestrator :8081 is an advanced service boundary, not a separate governance lifecycle. A caller can select governed processing, MAP, WCP, workflow execution, or control-plane endpoints directly.
Keep this boundary inside a trusted network. The caller takes responsibility for service authentication, identity propagation, route selection, and any Agent-side behavior it bypasses.
See Orchestrator API Endpoints and the Authentication and Header Matrix.
Framework and Tool Coverage
Framework integrations are adapters into one or more runtime paths. Their coverage depends on the interception point they expose.
| Integration type | Typical path | What it can see | Main limitation |
|---|---|---|---|
| Application SDK or model wrapper | Gateway or Proxy | Submitted model input and the response data wired through the adapter | Code paths that bypass the wrapper are not governed |
| Framework node or callback | Gateway, WCP, or MCP | Wrapped node transitions, model calls, or tool calls | Coverage is limited to registered callbacks and wrapped nodes |
| IDE hook | MCP-style tool governance | Tool input and, where supported, tool output | Prompt and model completion text may not be exposed by the IDE |
| MCP proxy or managed connector | MCP governance | MCP tool input, connector identity, and returned tool data | Non-MCP actions remain outside this boundary |
| Infrastructure gateway adapter | Decision Mode, optionally MCP | Traffic crossing the gateway | The gateway must enforce the verdict and fulfill supported obligations |
Examples:
- LangChain can use model and tool wrappers.
- LangGraph can use governed nodes, WCP, and MCP tool checks.
- Google ADK uses plugin callbacks for model and tool boundaries.
- n8n governs only the workflow positions where an AxonFlow node or HTTP call is placed.
- Claude Code, Cursor, and Codex depend on the hook surfaces each IDE exposes.
Coverage by integration
The following adapter-specific limitations complement the runtime comparison. Each linked integration page documents the interception points and version-specific behavior.
| 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) | 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 | Native SDK or HTTP client | Coverage follows the selected endpoint and the calls you wire; verify method availability in your SDK version |
| 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.
Common Combinations
| Architecture | Governance combination |
|---|---|
| Existing application with direct model calls and database tools | Gateway Mode for model calls plus MCP governance for tools |
| New application with AxonFlow-managed model calls | Proxy Mode, adding MCP governance for connector work |
| Existing LangGraph, n8n, Temporal, or Airflow workflow | WCP for steps plus MCP governance at tool boundaries |
| AxonFlow-generated agent plan | MAP plus MCP governance for connector steps |
| Shared gateway across many applications | Decision Mode, with MCP governance where connector-scoped controls are needed |
| Internal platform automation | Agent for application traffic, with Direct Orchestrator access only inside the trusted boundary |
How To Choose
- Decide who should execute the real model call, tool call, or workflow step.
- Decide which component can reliably block before that action.
- Decide whether output needs an explicit AxonFlow scan or redaction pass.
- Decide which component owns audit submission when execution remains outside AxonFlow.
- Add MCP governance wherever connector identity and tool-output controls matter.
Then use Choosing an Integration Mode for the recommended path and Runtime Request Paths for endpoint-level routing.
