Skip to main content

AxonFlow v9.1.0 Release Notes

v9.0.0 converged every enforcement plane — agent, orchestrator, MCP, gateway, and the decision API — onto one canonical audit vocabulary and closed the then-known unaudited denial paths by hand. v9.1.0 makes that coverage durable rather than something a person has to re-check before every release: continuous integration now fails the build if any enforcement point's denial path stops writing a canonical audit record, the last remaining denial paths are closed, the built-in policy inventory is pinned to a single source of truth, and a customer-portal bug that hid most of your seeded system policies is fixed.

This is a minor release. The audit and inventory changes are additive and backward-compatible — every audit write lands on the existing canonical decision record, and every new response field is additive. One behavior change to note: the strict and compliance profiles now block credential/secret (sensitive-data) detections that previously only logged — see The sensitive-data lever now enforces below if you need to keep the prior behavior. A single data migration realigns a legacy policy column and changes no behavior. Otherwise it is a drop-in upgrade.

Audit coverage, made permanent​

A governance record is only trustworthy if it is complete: a block that returns to the caller without writing an audit row is a silent gap in the trail. Through v9.0.0 those gaps were found by a manual coverage review before each release — which meant a newly introduced enforcement path could ship a gap and only be caught the next time someone re-ran the review.

v9.1.0 replaces that manual sweep with a deterministic check that runs on every change. Continuous integration now inspects every place in the platform that consults the policy decision engine and fails the build if that code's denial path doesn't record its decision on the canonical audit record. Every deliberate exception is held in a reviewed, checked-in allowlist with a one-line reason, so an exception is a documented decision rather than an accident.

The result: every policy enforcement point now writes a canonical audit record, enforced by a CI gate. The check has documented structural limits — it resolves one hop of helper indirection and inspects one denial per function — so it is a strong, continuously-enforced guardrail rather than an exhaustive proof; those limits are tracked for a future hardening pass. In practice it means a denial path can no longer quietly fall out of the audit trail between releases.

Every denial now lands in the decisions feed​

Closing the last paths the new gate flagged means a few more block-and-deny outcomes that previously went to a side channel — or nowhere a reader could see — now appear on the canonical decision record, so they show up in the portal decisions feed, the explain endpoint, and the regulator-facing exports:

  • Agent request denials. When the agent proxy rejects a request — a tripped circuit breaker, a policy block, a held-for-approval step, or an exhausted budget — the denial now writes a canonical decision row keyed on the authenticated user and tenant, so an agent-side block is visible in the decisions feed and the compliance exports rather than only in a legacy table no surface read.
  • MCP authorization failures. An MCP permission denial (the 403) now writes a canonical blocked decision row keyed on the authenticated request identity.
  • Privileged administrative actions. (Enterprise) SCIM access-token mint and revoke, and the deployment-upgrade trigger, now write an administrative audit event on every outcome. These rows carry only the action, the actor, the organization, and request metadata — never a token value or its hash.
  • Held and errored governance steps. A block or held-for-approval verdict from the optional in-memory step gate now records a canonical step-gate decision row, and a step whose policy check itself errors records that error instead of being silently treated as an allow. (The gate continues to fail open for availability, but the errored verdict is no longer lost from the trail.)

Together with the v9.0.0 consolidation, every enforcement surface — request and response, agent and MCP, the decision API and the admin plane — now lands its denials on one queryable record. See Audit Logging.

A straight answer on your built-in policy inventory​

AxonFlow ships a governance baseline so your teams don't start from a blank policy set. v9.1.0 pins that inventory to a single source of truth — the database migrations that actually seed it — and removes a stale, never-applied in-code definition that had advertised an inflated count. The numbers you read in the docs and see in the portal now agree.

Out of the box, AxonFlow ships 75+ immutable system policies (SQL-injection, PII for multiple jurisdictions, secrets and sensitive data, prompt-injection and dangerous-operation guards) — including 37 SQL-injection patterns — plus a set of editable starter policies, for 100+ pre-populated policies enabled on a fresh deployment. System policies are viewable in every edition and overridable in Enterprise.

A note on what those policies do by default: on the default profile, AxonFlow takes an observe-first posture — SQL-injection, PII, and sensitive-data (credentials/secrets) detections warn (the request flows, the detection is recorded) while dangerous commands and queries block. The strict and compliance profiles escalate PII, SQL-injection, and sensitive-data to block. Choose the posture that fits your environment on the Governance Profiles page, and see the full System Policies reference and the Managing Policies guide.

The sensitive-data lever now enforces​

The built-in sensitive-data policies — credentials, API keys, tokens, secrets, and connection strings — are part of that baseline, and the SENSITIVE_DATA_ACTION setting and the governance profile have always documented a default=warn / strict=block posture for them. In prior releases that lever was inert: sensitive-data detections always fell through to log, no matter the profile or setting. v9.1.0 wires it through so it actually drives enforcement — on both the request plane and the response plane (a credential-shaped model response is withheld, not only a request).

This is a behavior change for strict / compliance deployments. On those profiles, content carrying credentials or secrets that previously generated only a log entry will now be blocked — a request is rejected, a response is withheld. The default profile now warns on the same content (it previously only logged). To keep the prior pass-through behavior, set SENSITIVE_DATA_ACTION=log (or =warn). This brings the runtime in line with the long-documented Governance Profiles matrix.

The portal Policies page shows your full system baseline​

On a self-hosted enterprise stack, the customer-portal Policies page could show only a fraction of the governance baseline — your tenant's editable policies, with the seeded system policies missing — because an internal-service credential the portal uses to fetch the system policies from the agent defaulted to empty, and the portal then silently dropped the policies it couldn't load. v9.1.0 fixes both halves:

  • The shipped Docker Compose files now default that internal-service credential to a shared local-development value across the agent, orchestrator, and portal, so a local or evaluation enterprise stack shows the full inventory out of the box. (Production deployments via CloudFormation or the installer still inject their own secret — nothing changes there.)
  • The unified-policies responses no longer present an incomplete view as if it were complete. When a policy source can't be reached, the response now carries an additive partial flag and a source_errors list, so a degraded governance view is surfaced honestly instead of looking like a short, clean list.

If you run a self-hosted enterprise evaluation stack, the Policies page now lists your complete seeded baseline.

Upgrading​

v9.1.0 is a drop-in upgrade from v9.0.0. A single data migration applies automatically on startup and changes no behavior. One thing to check first: if you run AXONFLOW_PROFILE=strict or compliance, sensitive-data (credential/secret) detections will now block instead of log — set SENSITIVE_DATA_ACTION=log before upgrading if you need to retain the prior pass-through behavior. No other configuration changes are required.

# 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

In-VPC Enterprise (AWS CFN)​

No action required. The v9.1.0 images are drop-in — there are no schema changes in this release.

Community-SaaS users​

No action required.

Last updated on