Skip to main content

AxonFlow v8.7.0 Release Notes

v8.7.0 is a governance-integrity release. It consolidates policy decisions onto a single canonical audit record, lets each organization set its own detection enforcement posture on every plane, closes a class of compliance-export defects that let regulator-facing exports report success with no data, and corrects audit-feed pagination and PII detection false positives. Every change ships in the platform binaries, so this release goes to both editions. No breaking changes and no schema-incompatible changes — every API addition is additive and backward-compatible, and the new database columns are nullable and additive.

Audit-trail consolidation: one canonical decision record​

Before v8.7.0, reconstructing why a request was governed meant parsing a JSON policy_details blob and correlating timestamps by hand. v8.7.0 makes the decision a first-class, queryable record on audit_logs.

  • decision_id and plane are now first-class columns. Every governed decision writes a canonical row carrying a stable decision_id (which joins to the decision record and the explain endpoint) and a plane that names the enforcement surface (llm, mcp, agent, …). A regulator export can now be filtered to a single plane.
  • MCP check-output blocks emit a canonical decision row. A PII block on the MCP response path previously did not produce a decision row in the consolidated shape; it now writes the same canonical audit_logs decision record as every other plane, so the response leg is no longer a blind spot in the trail.
  • correlation_id groups decisions into chains. A single user action fans out into several governed decisions — the LLM call is checked, the tool it wants to call is checked, the agent step that wires them is checked. AxonFlow now stamps the W3C trace_id a Policy Enforcement Point propagates across those hops onto every decision row. Rows sharing a correlation_id are the ordered steps of one decision chain.

The regulator-facing exports use this to reconstruct chains instead of emitting a flat dump — see the compliance section below. Full detail is on the Audit Logging page.

Per-organization detection posture on every plane​

A single deployment often serves teams that want different enforcement behavior — a chat assistant wants PII redacted so the conversation flows, a nightly batch export wants the same PII to block the job. Until now the detection action (PII_ACTION and the SQLi / dangerous-operation levers) was one deployment-wide value resolved at boot, so those teams could not coexist.

v8.7.0 makes the enforcement action per-organization and per-category, with effective = per-org override ELSE deployment-global default:

  • Agent plane. The agent honors per-(org, category) overrides across its request and response paths — MCP check-input / check-output, the Gateway pre-check, POST /api/v1/decide, the proxy, the policy-test surface, and the OpenAI-compatible endpoint.
  • Orchestrator response plane. The orchestrator runs in a separate binary and previously always used the deployment-global action on the LLM-response redaction path (proxy / gateway / MAP). It now resolves the same per-org override there, so a per-org redact under a global warn is no longer reverted.
  • Customer-portal write path (Enterprise). A new Settings → Governance → Detection Posture page (/settings/detection-posture) lets an operator set each category to block / redact / warn / log, or leave it on the deployment default. The write path is gated by the sso:configure permission and scopes the write to the session's organization, so a spoofed X-Tenant-ID header cannot steer it.

On the hot path neither binary makes a per-request database call — each holds a short-TTL per-org cache and fails safe to the deployment-global action if a posture lookup errors. Full detail on the new Per-Org Detection Posture page.

Compliance-export integrity​

This release fixes a class of defects where a regulator-facing export could report success while carrying no data, and derives the regulator exports from the canonical decision record.

  • EU AI Act exports no longer fake success. Every EU AI Act export processor except decision-chain was a stub that returned no rows while the job was still marked Completed with a 100% progress bar — a regulator-facing export that lied. Unimplemented export types now fail honestly instead of reporting a zero-record success.
  • EU AI Act exports query real data. The full_audit, conformity_evidence, hitl_summary, policy_violations, and accuracy_metrics processors now read real, org-scoped data from audit_logs, policy_violations, the HITL records, and the euaiact_* tables.
  • SEBI and EU AI Act exports reconstruct decision chains. Both exports derive their lineage from the canonical audit_logs rows and group by correlation_id — SEBI returns chains under data.decision_chains; the EU AI Act export returns decision_chains with a chain_count. A single-step request (or a legacy row with no trace) is a one-element chain, so grouping never drops a decision. See SEBI and EU AI Act.
  • Audit retention is actually executed. A retention executor now prunes the six config-governed audit tables on schedule. It runs dry-run by default (it reports what it would delete) and only deletes when retention enforcement is explicitly enabled, with an admin surface to inspect a run.
  • admin_audit_log and scim_audit_log writers are wired. Administrative actions and SCIM operations are now recorded to their dedicated audit tables — the SCIM writer is row-level-security scoped to the acting org.

Decisions / audit feed​

The audit feed that backs the portal's audit view and the POST /api/v1/audit/search API got four correctness fixes:

  • total is the true match count. It previously returned the size of the returned page, so a UI could not render an accurate "1–100 of 4,213".
  • offset is applied. Pagination previously repeated the first page; page 2 is now actually page 2.
  • Partial-match filters. The tenant_id and user_email filters now do case-insensitive substring matching, so an operator can search by a fragment.
  • action filter. A filter on policy_decision (allowed / blocked / redacted / error) was added.

The portal audit view also no longer steals input focus on each filter fetch — typing in a filter box while results refresh no longer drops keystrokes. The API-visible changes are documented on the Audit API page.

SCIM group-to-role mapping is mounted​

The SCIM group-to-role mapping endpoints — which let an IdP group membership grant an AxonFlow role — are now mounted and reachable on the customer portal. Because assigning a role is a privilege grant, they are served on the session-authenticated router behind the sso:configure permission (not the bearer-token /scim/v2 provisioning router), the org is resolved from the session, and every change is written to the SCIM audit log. See SCIM 2.0 Provisioning → Group-to-Role Mapping.

PII detection false-positive fixes​

v8.7.0 tightens several broad detectors so benign values stop getting masked, and makes redaction structure-aware. This behavior is documented in detail on the PII Detection and MCP Response Redaction pages; in summary:

  • Context-gated detectors. Broad-shape detectors — bare-12-digit Aadhaar, Singapore NRIC/FIN/UEN/postal, passport, date-of-birth, IP-vs-version, Indonesian phone — now require a label or indicator adjacent to the value before they fire, so order IDs, barcodes, asset tags, build numbers, and tracking IDs are no longer masked. The specific fixes close IP-detected-on-a-version-string and phone-detected-on-a-tracking-ID false positives, and context-gate the bare Aadhaar and Singapore NRIC/FIN detectors.
  • Structure-aware, JSON-safe redaction. A redacted response always stays valid JSON: a string value is masked in place; a numeric-position value (e.g. a NIK stored as an integer) is masked and coerced to a string so the document stays valid; escaped PII (\uXXXX) is decoded and matched; and an unsafe result fails closed rather than emitting broken JSON.

Masking requires redact or block. Under warn / log the detectors fire for audit but never modify content — see the detection-posture and PII-detection pages.

Capability discovery​

The agent capability list (surfaced at GET /health) now recommends claude-code plugin v1.6.0 as the current plugin for self-hosted Enterprise MCP, so a deployment can advertise the plugin version that carries the Enterprise login fix.

What's NOT changed​

  • No breaking changes. All existing SDKs, plugins, and API consumers continue to work unchanged. New API fields and filters are additive; an org with no posture override behaves byte-for-byte as it did in v8.6.0.
  • The new audit_logs columns are additive and nullable. Legacy rows carry NULL for decision_id / plane / correlation_id and are treated as single-step chains; no backfill is required.
  • SDK versions are unchanged by this platform release and follow their own trajectories. The recommended SDK versions are unchanged from v8.6.0.
  • Existing endpoints — Proxy Mode (POST /api/request), Gateway Mode (POST /api/policy/pre-check), the OpenAI-compatible endpoint (POST /v1/chat/completions), and Decision Mode (POST /api/v1/decide) — all keep their existing contracts.

Upgrade notes​

Self-hosted (Docker / docker compose up)​

Pull the v8.7.0 images. No configuration changes are required — the audit consolidation, the per-org posture enforcement planes, the export-integrity fixes, and the detection false-positive fixes are all active on upgrade.

# Community
docker compose pull && docker compose up -d

# Enterprise
docker compose -f docker-compose.yml -f docker-compose.enterprise.yml pull
docker compose -f docker-compose.yml -f docker-compose.enterprise.yml up -d

To use per-org detection posture, set each org's overrides from Settings → Governance → Detection Posture (Enterprise portal). Optionally tune the propagation window with AXONFLOW_DETECTION_OVERRIDE_TTL_SECONDS (default 60s). To enable audit-retention pruning beyond dry-run, enable retention enforcement explicitly.

In-VPC Enterprise (AWS CFN)​

No action required. The v8.7.0 images are drop-in. The new audit_logs columns are added by an additive, idempotent migration.

Community-SaaS users​

No action required. The audit-consolidation and per-org posture enforcement changes are available at all tiers; the portal write path to set posture is an Enterprise surface.

Migration resources​

Last updated on