Skip to main content

Governance Profiles

New in v7.0.0

The AXONFLOW_PROFILE and AXONFLOW_ENFORCE env vars, plus relaxed default detection actions, are shipping in AxonFlow platform v7.0.0.

AxonFlow ships four pre-built enforcement profiles so you can pick a posture without tuning eight individual *_ACTION env vars.

TL;DR​

# Local trial / dev workflows — nothing blocks, everything logged
AXONFLOW_PROFILE=dev

# Default for a new deployment — dangerous commands block, PII warns
AXONFLOW_PROFILE=default   # (or leave unset)

# Production with real user data — PII / SQLi / sensitive data block
AXONFLOW_PROFILE=strict

# Regulated environments — HIPAA / GDPR / PCI / RBI / MAS FEAT block
AXONFLOW_PROFILE=compliance

The profile is resolved at agent and orchestrator startup and logged on boot. You can always confirm the active posture by scanning the startup log for [Profile] agent active:.

Profile matrix​

Categorydevdefaultstrictcompliance
piilogwarnblockblock
sqlilogwarnblockblock
sensitive_datalogwarnblockblock
high_risklogwarnwarnblock
dangerous_querieswarnblockblockblock
dangerous_commandswarnblockblockblock

This matrix is authoritative — it matches the runtime ProfileDefaults implementation and the database migration that rewrites system-default policies to match.

What each action means​

  • block — the request is rejected with a 403 and the policy decision is recorded in the audit trail.
  • warn — the request flows through unchanged, but the detection is surfaced in policy_info.policies_evaluated so the caller sees it and the audit trail records it.
  • redact — the detected content is masked in the response with a category tag (e.g. [REDACTED:ssn]). This is still available as an explicit PII_ACTION=redact opt-in but is no longer the default.
  • log — the detection is recorded in the audit trail only. No change to the response.

Fine-grained control with AXONFLOW_ENFORCE​

When a profile is close but not quite right, AXONFLOW_ENFORCE lets you flip individual categories to block without touching the rest:

# Everything defaults to warn, but PII and dangerous commands block
AXONFLOW_ENFORCE=pii,dangerous_commands

# Equivalent to AXONFLOW_PROFILE=strict
AXONFLOW_ENFORCE=all

# Equivalent to AXONFLOW_PROFILE=dev
AXONFLOW_ENFORCE=none

Valid categories: pii, sqli, sensitive_data, high_risk, dangerous_queries, dangerous_commands. Plus the sentinels all and none.

Unknown tokens are a fatal startup error. A typo like AXONFLOW_ENFORCE=piii will crash the agent at boot with a clear error message. This is intentional — a typo must never silently disable enforcement.

Precedence​

From highest priority to lowest:

  1. Explicit category env vars — PII_ACTION=block, SQLI_ACTION=warn, DANGEROUS_COMMAND_ACTION=block, etc. These always win.
  2. AXONFLOW_ENFORCE per-category opt-in.
  3. AXONFLOW_PROFILE built-in posture.
  4. Built-in defaults (equivalent to AXONFLOW_PROFILE=default).

This means existing deployments that already set PII_ACTION=block explicitly continue to work unchanged after upgrading to v7.0.0.

Upgrading from v6.1.0​

Breaking change

The default behavior of PII detection changed in v7.0.0. Deployments that previously relied on the implicit PII_ACTION=redact default will see unredacted PII flowing through to LLM providers after upgrading, unless they explicitly opt back in to the stricter posture. Read the restore instructions below before upgrading a compliance-sensitive deployment.

The default behavior changed in v7.0.0. If your v6.1.0 deployment was relying on the implicit default of PII_ACTION=redact (or the corresponding block-by-default SQLi behavior), you will see different behavior after upgrading.

To restore v6.1.0 behavior:

AXONFLOW_PROFILE=strict

Or explicitly set the categories you care about:

PII_ACTION=redact
SQLI_ACTION=block

The platform startup log banner will show the effective posture so you can confirm before any traffic hits the agent:

[Profile] agent active: strict — PII=block, SQLI=block, SensitiveData=block, HighRisk=warn, DangerousQuery=block, DangerousCommand=block

Why the defaults were relaxed​

Real-world feedback from the v7.0.0 release showed that the old defaults were too strict for every realistic use case except a fully locked-down production deployment:

  1. Silent redaction breaks debugging. A developer querying a real CRM through MCP would see SSN 123-45-6789 become 1*********9 mid-session without understanding why. The warn default preserves the data flow and surfaces the detection honestly.

  2. Reviewers on localhost were seeing redactions for fake test data, assuming AxonFlow was broken, and disabling governance entirely. The very audience we want to convert was being driven away by default behavior appropriate only for production.

  3. False positives are worse than under-policing because they teach people to bypass the system. Dangerous commands (reverse shells, rm -rf /, SSRF to cloud metadata endpoints, credential files) continue to block by default — these are unambiguous threats.

AxonFlow should feel like a seatbelt you're glad is there, not a straitjacket you want to cut off.

See also​

  • Configuring Policies — creating and editing custom policies on top of the system defaults.
  • Telemetry — what we collect at the SDK level and how to opt out.
Last updated on