AxonFlow v9.18.0 Release Notes

v9.18.0 introduces the Fraud & Risk Add-on, an Enterprise add-on for agentic payments. It brings deterministic financial-crime policy evaluation, a documented transaction context schema, and an optional self-hosted machine-learning risk scorer to the decision API and MCP policy planes. The release also fixes two real defects in the marketplace CloudFormation template: a monitoring blind spot in which a total agent outage read as healthy, and a missing permission that silently broke SAML identity-provider trust on every portal restart.

It is a MINOR by the semver policy: everything new is backward compatible and stays dormant until you enable it, and nothing an operator relied on is removed. No migrations run this release.

Am I affected?

Enterprise deployments evaluating the Fraud & Risk Add-on get its first release: the FinCrime policy pack, the transaction context schema, and the optional risk scorer. All of it is opt-in; nothing activates until you seed the pack, and the scorer additionally requires deploying its service and configuring the agent to reach it.

Deployments created from the marketplace CloudFormation template should upgrade their stack to pick up the alarm and permission fixes. If you configured SAML single sign-on on such a stack, read the signing-keypair fix below: your identity provider may have been re-registering a changing certificate without anyone noticing.

Community edition: no functional changes. See the compatibility note below.

Everyone else: routine upgrade. No migrations, no configuration changes required, and a deployment that changes nothing behaves identically to v9.17.0.

The Fraud & Risk Add-on

The add-on governs payment-shaped agent traffic with two cooperating layers (Enterprise add-on):

• A deterministic policy layer: a seeded pack of financial-crime policies evaluated by the same static policy engine as every other policy, plus typed validation of a documented transaction context schema.
• An optional ML scoring layer: a self-hosted risk scorer whose score can route a decision on the decision API into human review, with the score and the scoring outcome recorded on the audit trail on every plane.

The machine-learning layer is advisory in a specific, deliberate way: it never denies a request. On the decision API, an above-threshold score escalates an allowed decision to requires human approval. On the tool-call (MCP) planes, the score is recorded on the audit row as an attributed detection: the request proceeds, and nothing pauses. An outright deny, on any plane, can only come from deterministic policy rows. The seeded pack rows are system policies: you can read them, disable or change any one of them individually through per-policy overrides, and tune their thresholds where the pack is seeded.

The FinCrime policy pack and context schema

A caller can attach two documented context objects to a governed request: a transaction object (amount, currency, timing, counterparty locations, merchant category) and a cohort object (caller-supplied aggregates such as recent transaction counts and exposure, so velocity rules work without the platform holding rolling state). The platform validates both against the schema and evaluates the pack's policies over them.

The pack ships policies for structuring-band amounts, sanctioned and high-risk corridor geography (matching two-letter, three-letter, and subdivision-suffixed location forms), amount caps, and velocity and exposure step-ups. Each policy row names the public source it derives from. Pattern evaluation is identical on the decision API and MCP planes because patterns bind to one canonical serialization of the context objects. Outcomes differ by plane by design: a step-up (requires-approval) row pauses the decision on the decision API, while on the tool-call planes it is recorded as a non-blocking attributed match; a blocking row blocks on every plane.

Two behaviors worth knowing before you enable it:

• Step-ups are reviewable, not just returned. On the decision API plane, a verdict of requires-approval always creates an entry in the human-in-the-loop approval queue, so the decision can actually be approved or rejected rather than only reported.
• Opting in subjects the context to the full policy scan. On the decision API plane, attached context JSON is scanned by the complete static policy engine, including PII and injection detection, not only the FinCrime rows.

Audit rows for scored or flagged decisions carry the matched policy identities, the risk score, and an explicit machine-learning inference status on every plane, so a reviewer can always tell whether the scorer ran, what it said, or that it was unavailable.

The self-hosted risk scorer

The scoring service is a separate container you deploy inside your own network; transaction context never leaves your infrastructure to be scored. Its API contract is versioned and frozen: requests authenticate with an HMAC service signature, and authentication is decided before request validation, so an unauthenticated caller receives 401 and never a validation response. The model is mounted at deploy time, never baked into the image, and the bundle format rejects bundles built for earlier format versions outright.

On the platform side, the scorer client enforces a hard per-request time budget. If the scorer is slow, down, or unreachable, the decision proceeds on the deterministic layer alone and the audit row records that the scoring layer was unavailable. Degradation is visible, never silent, and never a block.

The scorer is off by default. It scores only when its service is deployed, the agent is configured with its endpoint, and a valid internal service secret is set; without all three, the platform behaves as if the scoring layer does not exist.

Fixes for marketplace CloudFormation deployments

A total agent outage is now alarmed

The template's agent monitoring had a blind spot: its unhealthy-host alarm counts registered load-balancer targets that fail health checks, and a service at zero running tasks has no targets to count, so a total agent outage read as healthy while a partial one alarmed. The template now adds a dedicated agent task-count alarm on the Container Insights running-task-count metric, mirroring the orchestrator's existing one, so the agent service dropping to zero tasks pages instead of disappearing. Missing data breaches by design: if Container Insights is ever disabled, the alarm pages rather than silently going green (Enterprise).

The same class of defect in the opposite direction, task-count alarms defined on a metric name their namespace never publishes and therefore stuck permanently in the alarm state, existed only on AxonFlow-operated infrastructure and is fixed there in the same change; no customer stack carried those alarms. A regression test now pins the class for every template: no ECS alarm may name a metric its namespace does not publish, and every service deployment must carry task-count coverage.

The task role could not read the SAML signing keypair

The customer portal's SAML service loads its service-provider signing keypair from AWS Secrets Manager at runtime, through the ECS task role. The template's task role shipped with no Secrets Manager permissions at all, so the load always failed, and the service fell back to generating a temporary keypair in memory. SAML appeared to work, but the service-provider signing certificate changed on every portal restart, silently breaking any identity provider that had registered it.

The template now grants the task role read access scoped to that one secret. If your SAML identity provider kept "losing" the AxonFlow certificate between restarts, this was why; after upgrading the stack, re-register the certificate once and it will remain stable (Enterprise).

The fallback behavior itself, generating a temporary keypair instead of failing loudly, is unchanged in this release and will be addressed separately.

Security

The indirect moby/go-archive dependency is bumped to 0.3.0 in both editions' Go modules (CVE-2026-17106: a crafted tar archive can write outside the extraction directory). The dependency enters the module graph through test tooling, not shipped request paths, so no runtime behavior changes in either edition; the bump updates a source build's go.mod and go.sum and keeps its vulnerability-scan posture green.

Smaller operational changes

This release also carries internal operations work on AxonFlow-hosted infrastructure: password-reset email enablement on the AxonFlow-operated SaaS, deployment-workflow parameter plumbing for the reset-email configuration group, cleanup automation for artifacts retained after ephemeral test-stack deletion, and a telemetry alarm cadence fix. None of these change self-hosted deployments.

Community edition

No functional changes. The community edition is released in lockstep at v9.18.0. The add-on's integration seam compiles into the community binaries, but on a community build it is a strict no-op: the engine is never constructed, the FinCrime policy category is only ever evaluated where the Enterprise pack was seeded, and every request proceeds exactly as it did on v9.17.0. The version is cut so the two editions never diverge in version number.

Before you upgrade

• No migrations this release. No schema changes, no boot-requirement changes, no mode-selector changes.
• The Fraud & Risk Add-on is opt-in configuration. Nothing about policy evaluation changes until the pack is seeded, and the scoring layer stays off until its service is deployed and the agent is configured to reach it.
• Marketplace CloudFormation stacks should apply the updated template to receive the alarm and task-role fixes. After the update, a new agent task-count alarm appears alongside the existing ones, and if you use SAML, re-register the service-provider certificate with your identity provider once; it will then remain stable across restarts.
• From older versions: v9.18.0 is cumulative. If you are coming from v9.16.x or earlier, read the intermediate release notes; the v9.17.0 notes carry an additive migration (core/159) that runs when you cross that version.

SDK and plugin compatibility

No SDK or plugin changes are required. Clients compatible with v9.17.x are compatible with v9.18.0.