Governance Profiles (Removed in v11)

Removed in v11

AXONFLOW_PROFILE (dev / default / strict / compliance) and AXONFLOW_ENFORCE no longer exist, and neither do the *_ACTION environment variables they sat on top of. The profile matrix is gone. This page is kept so existing links resolve: it explains what replaces each profile and how to migrate.

What decides the action now

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 or profile sets a detection action.

There are two supported ways to change an outcome:

1. Record an organization override. One row per category in detection_action_overrides: 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; the 22 organization-editable policies are not reached. Actions are block, redact, warn and log. The Enterprise customer portal writes it (Settings → Governance → Detection Posture, or PUT /api/v1/detection-posture/{category} with {"action":"block"}; session auth, sso:configure, audited to admin_audit_log). The enforcement planes honor overrides in both editions, and a Community deployment can seed rows directly.
2. Change one policy for your organization. Disable, re-enable or re-action a single shipped policy for your organization, or author a policy of your own as a typed policy document; see Policy and Identity Control Plane. This is the only way to change sensitive-data, compliance-*, fincrime and admin-access outcomes, which have no override category.

Out of the box

Rows	Stored action (request / response)
every sys_sqli_*	warn / warn
sys_pii_ssn, sys_pii_credit_card, sys_pii_singapore_nric	warn / redact
sys_pii_passport, sys_pii_dob, sys_pii_email	log / redact
sys_pii_indonesia_ktp	block / none (request phase only)
sys_sensitive_*	warn / warn
security-dangerous command rows	block / none
prompt-injection rows	block / redact

This is closest to the old default profile: PII and SQL injection warn or log, while dangerous commands and prompt injection block.

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.

Replacing each profile

Removed setting	v11 replacement
AXONFLOW_PROFILE=dev	Usually nothing: the stored PII and SQL injection actions already warn or log. To match dev more closely, record pii=log and sqli=log. dangerous_command=warn would weaken only the four prompt-injection guards; the dangerous-command blocks are organization-editable policies, changed in the organization's typed policy document.
AXONFLOW_PROFILE=default (or unset)	Nothing. Remove the variable; the stored actions above apply.
AXONFLOW_PROFILE=strict	Record pii=block and sqli=block, or set block on the policies. The dangerous-command blocks already block; dangerous_command=block adds block only for the four prompt-injection guards on responses. Sensitive data (was block) has no override category, so change the action on those policies.
AXONFLOW_PROFILE=compliance	The same overrides as strict. The compliance categories (compliance-*, fincrime) have no override category; their stored actions decide.
AXONFLOW_ENFORCE=<categories>	A block override for each listed category that has one (pii, sqli, and dangerous_commands as dangerous_command, which reaches only the four prompt-injection guards: the dangerous-command blocks already block); a policy action change for sensitive_data. high_risk and dangerous_queries carry over to nothing (see their rows below).
PII_ACTION, SQLI_ACTION, DANGEROUS_COMMAND_ACTION and their MCP_* / GATEWAY_* variants	An organization override for pii or sqli. The dangerous-command action is the organization-editable policies' own, changed in the organization's typed policy document; dangerous_command reaches only the four prompt-injection guards. There is no per-surface action any more.
SENSITIVE_DATA_ACTION	A policy action change on the sys_sensitive_* policies.
SQLI_BLOCK_MODE	The same as SQLI_ACTION: an organization sqli override.
PII_BLOCK_CRITICAL	An organization pii=block override.
HIGH_RISK_ACTION	Nothing: it was never enforced. The dynamic risk policy reads its action from the database.
DANGEROUS_QUERY_ACTION and its MCP_* / GATEWAY_* variants	Nothing to carry over: the dangerous_query override category maps onto no policy category. Destructive SQL statements (DROP TABLE, TRUNCATE, DELETE without WHERE, ALTER, GRANT, REVOKE, CREATE USER) are security-sqli rows and follow sqli.

Migrating

1. Find what you still set. A deployment that still sets a removed variable keeps running with the stored actions. At boot the agent (and orchestrator) logs one line per variable that is set, and increments axonflow_ignored_posture_env_total{name="<NAME>"} on /prometheus:

   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.

2. Decide the intent of each variable with the table above.

3. Record the overrides or change the policy actions. For example, the old strict posture for one 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

4. Remove the variables from your .env, Compose, Helm or Kubernetes configuration, then restart.

5. Confirm. The boot log carries no detection posture env var ignored lines, GET /api/v1/detection-posture lists the overrides you expect, and axonflow_agent_policy_stored_action_displaced_total shows whether an override is weakening a stored action.

The full list of removed variables is in Environment Variables Reference.

See also

• Detection Posture - the per-organization override
• System Policies: what the Action column means at runtime - the per-plane matrix
• Configuring System Policies - changing an action, and the static-policy settings that remain
• Environment Variables Reference