Environment Variables Reference
This page consolidates the environment variables a self-hosted operator uses to tune AxonFlow's built-in governance baseline. It complements the two conceptual guides:
- Detection Posture — the per-organization override, the only thing that replaces a stored detection action.
- Configuring System Policies — how a detection action is chosen and changed.
Read those first for the "why"; use this page as the "what" — one table per group, with values, defaults, and editions.
How a detection action is resolved
No environment variable sets a detection action. For each matched policy the effective action is resolved as:
organization detection-posture override (pii, sqli, dangerous_command)
-> action stored on the matched policy
The override applies to the platform's policies in its category for that organization: pii reaches the 18 platform pii-* policies, sqli the 38 platform security-sqli policies, and dangerous_command the four platform policies in security-dangerous, which are the indirect prompt-injection guards. It does not reach the 22 organization-editable policies, among them the dangerous-command blocks; those change in the organization's typed policy document. sensitive-data, compliance-*, fincrime and admin-access have no override category, so their stored action always decides. See Detection Posture.
Action values
A policy action or an organization override takes one of:
| Value | Effect |
|---|---|
block | request rejected with 403; decision recorded in the audit trail |
warn | request flows through unchanged; detection surfaced to the caller and recorded |
redact | detected content masked in the response with a category tag (e.g. [REDACTED:ssn]); PII only |
log | detection recorded in the audit trail only; no change to the response |
Removed in v11: detection action variables
These environment variables no longer set any action: PII_ACTION, SQLI_ACTION, DANGEROUS_COMMAND_ACTION, SENSITIVE_DATA_ACTION, MCP_PII_ACTION, MCP_SQLI_ACTION, MCP_DANGEROUS_QUERY_ACTION, MCP_DANGEROUS_COMMAND_ACTION, GATEWAY_PII_ACTION, GATEWAY_SQLI_ACTION, GATEWAY_DANGEROUS_QUERY_ACTION, GATEWAY_DANGEROUS_COMMAND_ACTION, SQLI_BLOCK_MODE, PII_BLOCK_CRITICAL, DANGEROUS_QUERY_ACTION, HIGH_RISK_ACTION, AXONFLOW_PROFILE and AXONFLOW_ENFORCE. The dev / default / strict / compliance profile matrix no longer exists; Governance Profiles (removed in v11) maps each old profile to its replacement.
A deployment that still sets one keeps running with the stored policy actions. At boot the agent (and orchestrator) logs one line per variable that is set:
WARN [agent] detection posture env var ignored: <NAME>=<value> no longer sets an action (v11); the stored policy action decides - see release notes. To choose a different action for an organization, set its detection-posture override (audited), or change the action on the policy.
and increments axonflow_ignored_posture_env_total{name="<NAME>"} on /prometheus. Remove the variables, and replace any posture you relied on with an organization override or a policy action change.
SQLI_SCANNER_MODE is unchanged. The detection-scope variables below are different: in v11 they refuse boot when set to a narrowing value.
MCP surface
Connector and SQL-style data-access flows.
| Variable | Values | Default | Edition | Purpose |
|---|---|---|---|---|
MCP_STATIC_POLICIES_ENABLED | true | true | Community | v11: false refuses boot; see Detection-scope variables |
MCP_STATIC_POLICIES_SKIP_CATEGORIES | unset | unset | Community | v11: a category list refuses boot |
MCP_STATIC_POLICIES_CONNECTORS | unset | unset | Enterprise | v11: a connector list refuses boot |
Gateway / proxy surface
Governed LLM requests through the Agent.
| Variable | Values | Default | Edition | Purpose |
|---|---|---|---|---|
GATEWAY_STATIC_POLICIES_ENABLED | true | true | Community | v11: false refuses boot |
GATEWAY_STATIC_POLICIES_SKIP_CATEGORIES | unset | unset | Community | v11: a category list refuses boot |
Detection-scope variables
The *_STATIC_POLICIES_ENABLED, *_STATIC_POLICIES_SKIP_CATEGORIES and MCP_STATIC_POLICIES_CONNECTORS variables once narrowed where the detectors ran. In v11 a narrowed detector would leave the policy decision engine unable to decide the policies that read it, on every request, so a narrowing value refuses boot and the boot message names the variable. The defaults boot. To change what a shipped policy does, change it for your organization; see Configuring System Policies.
Capability-scoped evaluation
Execution-class detectors (SQL injection, dangerous commands) do not evaluate tools that AxonFlow classifies as text-document tools — for example a documentation editing tool whose input is prose, not executable statements. Content-borne detectors (all PII, prompt-injection guards) still evaluate everywhere. Classification happens server-side against a built-in registry; the tool name is never trusted from an unauthenticated caller.
| Variable | Values | Default | Edition | Purpose |
|---|---|---|---|---|
AXONFLOW_CAPABILITY_SCOPING_DISABLED | true, false | false | Community | set true to restore full evaluation on every tool (only ever widens evaluation) |
AXONFLOW_TEXT_DOCUMENT_TOOLS | comma list of tool names | unset | Enterprise | extend the built-in text-document registry with additional tool names |
Temporary false-positive posture
If detection is blocking legitimate documentation traffic while you validate a fix, change the outcome for the affected organization rather than the deployment. The dangerous-command blocks are organization-editable policies: change them in your organization's typed policy document, because dangerous_command reaches only the four prompt-injection guards, not these blocks. For SQL injection, delete a sqli=block override so the shipped warn action stored on every sys_sqli_* row decides again. PII is unaffected: its stored actions and any pii override stay as they are.
# Return SQL injection to the stored warn action for this organization during validation
curl -b "axonflow_session=$SESSION" -X DELETE \
http://localhost:8082/api/v1/detection-posture/sqli
# Record block again when validation is done
curl -b "axonflow_session=$SESSION" -X PUT -H 'Content-Type: application/json' -d '{"action":"block"}' http://localhost:8082/api/v1/detection-posture/sqli
An override reaches every platform policy in its category, so keep the window short. There is no per-surface action and no per-surface switch in v11. Treat the override as a stopgap — the durable fix is capability-scoped evaluation, which removes documentation tools from the execution-class detectors without lowering the posture for real data-access flows.
