Skip to main content

Configuring System Policies

AxonFlow ships with a built-in governance baseline so teams do not have to design their entire policy layer before sending the first governed request.

Today that baseline is:

  • 70 pattern-based system policies on the Agent
  • 15 condition-based system policies on the Orchestrator
  • 85 total built-in system policies

This guide covers the public configuration surface for system policies. Tenant-policy management is covered elsewhere in the policy docs.

Configuration Model​

The action stored on the matched policy decides. For the detection categories (pii-*, security-sqli, security-dangerous) the organization's recorded detection-posture override replaces it on the platform's policies; the organization-editable policies are changed in the organization's own typed policy document. No environment variable sets an action.

No environment variable narrows what is evaluated, either. The policy decision engine decides every shipped policy on every plane that can evaluate it, and the detection-scope variables that once switched evaluation off for a surface, a category or a connector refuse boot when set to anything but their default; see Detection-scope variables.

Removed in v11

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 no longer set any action. A deployment that still sets one keeps running with the stored policy actions, logs one boot WARN per variable, and increments axonflow_ignored_posture_env_total{name="<NAME>"}. See Environment Variables Reference.

Changing an Action​

There are two supported ways, and neither is an environment variable.

  1. Record an organization override. The Enterprise customer portal writes it from Settings → Governance → Detection Posture, or through the API below. It uses session auth and requires the sso:configure permission; every write is audited to admin_audit_log and records updated_by. The enforcement planes honor overrides in both editions, and a Community deployment can seed rows directly.

    # List the organization's overrides
    curl -b "axonflow_session=$SESSION" http://localhost:8082/api/v1/detection-posture

    # Block SQL injection for this organization
    curl -b "axonflow_session=$SESSION" -X PUT -H 'Content-Type: application/json' \
      -d '{"action":"block"}' http://localhost:8082/api/v1/detection-posture/sqli

    # Remove the override; the stored policy action decides again
    curl -b "axonflow_session=$SESSION" -X DELETE http://localhost:8082/api/v1/detection-posture/sqli
    Override categoryReaches
    piithe 18 platform pii-* policies
    sqlithe 38 platform security-sqli policies, including the destructive-statement rows (DROP TABLE, TRUNCATE, DELETE without WHERE, ALTER, GRANT, REVOKE, CREATE USER)
    dangerous_commandthe four platform security-dangerous policies, the indirect prompt-injection guards; not the organization-editable dangerous-command blocks
    dangerous_queryno policy category
    obligation_fallbacknot a detector: the action when a plane cannot fulfil a redact obligation (block or log only)

    Actions are block, redact, warn and log. sensitive-data, compliance-*, fincrime and admin-access have no override category, so their stored action always decides.

  2. Change one policy for your organization. Every shipped policy can be disabled, re-enabled or given a different action for a single organization, and an organization can author policies of its own as a typed policy document; see Policy and Identity Control Plane. The v10.x write routes are closed: POST /api/v1/tenant-policies for tenant policies and POST /api/v1/static-policies for system policies answer 409 LEGACY_POLICY_WRITE_FROZEN, naming the typed route.

Shipped Stored Actions​

RowsStored action (request / response)
every sys_sqli_*warn / warn
sys_pii_ssn, sys_pii_credit_card, sys_pii_singapore_nricwarn / redact
sys_pii_passport, sys_pii_dob, sys_pii_emaillog / redact
sys_pii_indonesia_ktpblock / none (request phase only)
sys_sensitive_*warn / warn
security-dangerous command rowsblock / none
prompt-injection rowsblock / redact

SQL injection warns out of the box on the platform policies. Record sqli=block, or change a policy's action for your organization, to block it. Two organization-editable policies, sql_injection_union and sql_injection_or, block the patterns they match. Every shipped policy's action on each plane is listed in Shipped Policy Posture.

The code-backed detectors with no stored row, indonesia_pii_protection (checksum-validated NIK/NPWP) and rbi_pii_protection (India PII), block only under an organization pii=block override and emit a redact obligation only under pii=redact. With no override they detect and record, and the stored policy rows decide.

Detection-scope variables​

These variables once narrowed where the detectors ran. A narrowed detector would leave the engine unable to decide the policies that read it, on every request, so in v11 each of them refuses boot when set to a narrowing value, and the boot message names it. Their defaults boot.

VariableBoots withRefuses boot with
MCP_STATIC_POLICIES_ENABLED, GATEWAY_STATIC_POLICIES_ENABLEDunset, or truefalse
MCP_STATIC_POLICIES_SKIP_CATEGORIES, GATEWAY_STATIC_POLICIES_SKIP_CATEGORIESunset, or emptya category list
MCP_STATIC_POLICIES_CONNECTORSunset, or emptya connector list

To stop a shipped policy deciding for an organization, disable that policy for the organization; to relax the platform's policies in a detection category, record a detection-posture override.

Precedence​

The order of precedence for a detection category is:

organization detection-posture override -> action stored on the matched policy

An override applies on the planes that apply organization overrides (the Decision API, Gateway Mode's pre-check, MCP, the OpenAI-compatible route, Proxy Mode's request, the orchestrator's response filter and the policy test surface), and there is no per-surface action to configure. What a shipped policy does on each plane when no override is recorded is listed in Shipped Policy Posture.

Common Operating Patterns​

Observe During Local Development​

No action configuration is needed: the shipped PII and SQL injection policies already warn or log on the request phase, while dangerous commands and prompt injection still block. To silence one policy for your organization, disable it; no deployment setting narrows evaluation.

Strict Posture for an Organization​

for category in pii sqli dangerous_command; do
  curl -b "axonflow_session=$SESSION" -X PUT -H 'Content-Type: application/json' \
    -d '{"action":"block"}' "http://localhost:8082/api/v1/detection-posture/$category"
done

sensitive-data has no override category; to block it, change the action on those policies. The dangerous-command blocks are organization-editable and already block; dangerous_command=block reaches only the four prompt-injection guards, which then block on responses too, where they ship redact.

Turning a Shipped Policy Off​

Disable it for your organization. There is no deployment-wide switch: MCP_STATIC_POLICIES_ENABLED=false refuses boot in v11 (see Detection-scope variables).

Enterprise Note​

Licensed tiers expand the operating model around policy management, especially for organization-level workflows and broader portal-based governance. The shipped actions, per-policy control and detection-posture overrides are the right place to start when you want to tune the shipped policies. Setting detection-posture overrides from the portal is Enterprise; a Community deployment can seed override rows directly.

Last updated on