AxonFlow v11.1.0 Release Notes

v11.1.0 is a minor on the v11 model. Nothing in the v10 → v11 Migration Guide changes. If you are upgrading from v10.x, read that first.

Most of this release completes v11's own model:

• the Fraud & Risk Add-on's risk score returns, as a fact the FinCrime pack reads;
• an approval requirement holds on Decision Mode and the MCP request plane;
• a policy can say which planes it binds on;
• every multi-agent step, and the content of every step, is decided.

Several changes close behaviour that let a request through without a decision. Where that turns an allow into a refusal, the section below says what to do.

Before you upgrade: actions

Two changes need a caller to change to keep working:

1. Send acknowledge_template_omissions when you activate a document that drops or changes template policies, or the activation is refused. Activating a typed organization document that omits organization-template policies, or carries one under its id but changed, now answers 409 TEMPLATE_OMISSIONS_UNACKNOWLEDGED. It succeeds only when the request lists exactly those policy ids in acknowledge_template_omissions. The ids are the union of template_omissions.omitted and template_omissions.modified, which both the publish response and the refusal report. The portal's promote and rollback show the removed and changed policies and confirm them in one step. See Typed Policy Authoring.
2. Remove Industry from your AWS Marketplace stack's parameter overrides, or the stack update is rejected. The CloudFormation template no longer declares it. That includes a script that rebuilds UsePreviousValue entries from describe-stacks. The parameter set a variable nothing read, and what a stack deploys does not change. See AWS Marketplace.

Four more changes refuse something that used to be allowed. Check each one against your deployment:

3. With media governance on and no analyzer that measures content safety, every image request is refused. Examples are a deployment with no analyzer registered, or with local OCR as its only analyzer. The refusal is unknown_constraint from sys_media_nsfw_block. Before, these requests were allowed on safe values that no analyzer had measured. Register a content-safety analyzer, or change that policy in your organization's document. See Media Governance.
4. Cowork ingest answers 501 when an Enterprise image runs a core-only deployment mode (community, evaluation or community-saas), exactly as the community build does. To keep it, run the Enterprise image in an Enterprise mode. See Cowork OTEL Ingest.
5. Every multi-agent step is decided by your policy, on every deployment. Before, steps were decided only when AXONFLOW_HITL_ENABLED was true, which no shipped deployment set to true. That variable is now ignored.
   • A step your policy blocks is refused 403 execution_blocked (it was 500).
   • A step an approval requirement matches is refused 403 approval_requires_durable_record.
   • To have a person approve multi-agent steps, run the plan in confirm or step mode.
6. Audit rows and metrics for /api/v1/process and /api/v1/plan/execute carry plane: orchestrator_request instead of wcp. Update dashboards, saved searches and alerts that filter on wcp for those two routes.

Am I affected?

Anyone with automation that activates typed documents. Read action 1.

AWS Marketplace deployments. Read action 2.

Anyone using image governance, cowork ingest or multi-agent plans. Read actions 3 to 5.

Anyone who authored typed policies for workflow steps or the orchestrator's request routes. Read Orchestrator request routes: a document you already published keeps governing exactly what it governed, until you republish it.

Enterprise deployments running the upgrade with a v10.x customer portal or agent still in service. Read Migrations: upgrade every portal and agent to v11 before v11.1.0's migrations run.

The Fraud & Risk Add-on's risk score is back

Enterprise, with the Fraud & Risk Add-on. v11.0.0 retired the add-on's v10 scoring integration. v11.1.0 brings the score back under the v11 model: it is a fact the FinCrime pack reads, advisory by design, and it never blocks.

• Turning it on. Run the add-on's optional scoring service, whose image and model bundle are not in the standard install image set and come from your AxonFlow contact during early access (see Known limits), and set AXONFLOW_FINCRIME_RISK_FACT_URL; AXONFLOW_FINCRIME_RISK_FACT_TIMEOUT_MS sets the call's budget. A deployment that does not start the service is unchanged. The v10 variables AXONFLOW_FINCRIME_SCORER_URL and AXONFLOW_FINCRIME_SCORER_TIMEOUT_MS still refuse boot, and the refusal now names their replacements. A scorer URL without a usable AXONFLOW_INTERNAL_SERVICE_SECRET also refuses boot.
• What it does. A request on Decision Mode or the MCP request pass that declares a FinCrime transaction is scored before it is decided, once the caller has been admitted. The FinCrime pack, now version 2, holds the request for a person's approval when the score is at or above 0.011591929942369461.
  • The threshold is the operating point that flags at most 1% of transactions on the model's validation partition. It is not tuned to your traffic.
  • To move it, up or down, publish a policy under the control's own id pack:fincrime:fincrime__ml__risk__stepup in your organization's document.
• Guarantees. The score never blocks, and a missing score never refuses or holds. Every decision on which the control read the score records why it has the score it has, at policy_details.fincrime_risk_score:
  • a status: scored, timeout, auth_rejected, unavailable, malformed_response, unconfigured or no_transaction;
  • the score, the model version and its top features;
  • each control that read the score, with its threshold.
• Observability. The same outcomes are counted in axonflow_fincrime_risk_fact_total. /health reports them as risk_score_fact, which reads degraded while the scoring service refuses the agent's secret.

Approvals

• Decision Mode and the MCP request plane hold an approval requirement as a pending approval (Enterprise). On a deployment with the approval queue, a call an approval requirement matches is no longer refused.
  • It answers pending_approval on the MCP routes and verdict: needs_approval on Decision Mode, and the approval appears in the portal's Approvals view.
  • Once approved, retrying the same call with the approval named (X-Axonflow-Approval-Id, or the approval_id field) passes it once.
  • A retry after a rejection, after expiry, with changed input, or naming an unknown approval is refused with a named reason.
  • /health names the contract approval_hold_retry, so a client can discover it. Community is unchanged: there, the requirement is refused approval_required.
• The approval window is configurable. AXONFLOW_APPROVAL_TTL_SECONDS sets the window for an approval no policy gives one: 15 minutes when unset, 60 to 604800 seconds, and an out-of-range value refuses boot. A policy's approval_challenge expiry_seconds now sets the window in either direction, and approval_challenge accepts a severity (low, medium, high, critical).
• Workflow step approvals govern what runs. A step gate that would re-evaluate a step whose approval is pending, rejected or expired is refused 409 APPROVAL_HOLD. An approve and a reject racing on one step cannot both land, and an approval never lands on an ended workflow (409 WORKFLOW_TERMINAL). A step held again gets its own new approval, with its own window.
• A call that several FinCrime approval requirements match at once is held as one pending approval (Enterprise), naming every policy that asked. It could be refused approval_required instead. An approval that cannot be queued is refused with its cause (the pending-approval limit, the licence tier, or an internal error), never a database error's text.
• Multi-agent plan resume runs its steps in order, runs the step whose approval it recorded, and acts only on the plan's own workflow.

See Human-in-the-Loop.

Typed policies

• binds_on. A policy can name the enforcement planes it applies on, for example ["wcp", "map"] to require approval on workflow steps without touching MCP tool calls. A policy without binds_on applies everywhere, as before. Publishing warns where a requirement binds on a plane that cannot hold an approval:

  • BINDS_ON_MCP_RESPONSE: the MCP response pass. An approval requirement that applies there also refuses check_output, so scope it with binds_on.
  • BINDS_ON_ORCHESTRATOR_REQUEST_NO_HOLD: the orchestrator's request routes.
  • BINDS_ON_MAP_NO_HOLD: the multi-agent plane.

  See Where a requirement binds.

• Step names and tool names. A document can constrain a workflow or multi-agent step by args.context.step__name, and a workflow tool step by args.context.tool__name, read with an eq comparison. A caller sets these labels, so a constraint on them applies only to requests that carry them.

• Group and OIDC scope (Enterprise).

  • A policy scoped to a group applies to the group's members on the agent's enforcing planes, with membership read from the SCIM directory. A SCIM membership change takes effect on the user's next request.
  • A user who signs in through your organization's OIDC identity provider is decided by policy. They were refused unknown_realm. Policies can scope to User::oidc:<sub> and Group::oidc:<id>.
  • The orchestrator's planes do not yet state groups.

• Store failures are answered as the store. When the typed-policy store is unreachable, publish, promote, rollback, withdraw and activation answer 503 storage_unavailable (or key_not_loaded), instead of refusing your document. A store that disagrees with its own ledger answers 503 ledger_inconsistent. The artifact list names an artifact it could not read, in unverifiable, instead of failing the page or dropping it.

• The policy summary counts installed policy packs. GET /api/v1/typed-policies/active/summary answers pack and packs_counted.

• A new route, GET /api/v1/typed-policies/template, returns the shipped organization template to seed a document from.

Workflow and multi-agent steps

• Step content is decided. The workflow step gate presents a step's step_input (and tool_input for a tool step), and the multi-agent plane presents a step's prompt, statement, parameters and what it sends.
  • The shipped content policies decide there. A step whose content asks to debug is blocked outside development, and a step comparing tenant_id is blocked.
  • Bodies over 1 MiB are refused 413 request_too_large.
  • An idempotent step-gate retry whose input differs from the first is refused 409 STEP_INPUT_MISMATCH.
  • A policy of yours that reads a static detector on these planes now sees it as unknown, not false, because no static detector runs there.
• Conditional branch steps are decided by their own type on workflow execute and plan execute outside confirm and step mode.
• A multi-agent plan's LLM calls obey your route policies. A route policy set whose allowed providers intersect to nothing refuses the call 403 no_compliant_provider before any provider is contacted. This applies on /api/v1/process, /api/v1/plan/execute and POST /api/v1/plan. It used to lift the restriction.
• A multi-agent plan step has a cost estimate. The platform now prices the step it is about to run, from your deployment's own pricing table. The two shipped advisory "expensive query" policies act on it. Neither ever refuses a step.
• The in-memory multi-agent pause is retired. A multi-agent step is held only in confirm or step mode. GET /api/v1/workflows/executions/{id}/hitl-status answers 404 and is removed in v12.0.0.

Orchestrator request routes

POST /api/v1/process and POST /api/v1/plan/execute are decided under a plane of their own, orchestrator_request. wcp now means the workflow step gate alone, and binds_on can name either plane.

• A document you already published keeps governing what it governed. It records the vocabulary it was written against. When you republish it, wcp means the step gate alone.
• A policy that reads a detector applies only where that detector runs. Detectors such as the SQL-injection ones do not run on these routes, the step gate or the multi-agent plane. So a policy reading one there could not be evaluated, and refused every request whatever it contained. It now does not apply there. Traffic through the agent is unaffected. If you relied on such a policy to refuse requests on those planes, use a policy the plane can evaluate.

MCP and redaction

• check-input hands back masked parameters (Enterprise). MCP check-input and the MCP server's check_policy return each masked request parameter in redacted_parameters. This happens when the enforcement point's capability handshake declares field_redact at versions 1 and 2. Under a pii=redact posture, a tool call whose personal data sits in its arguments is then answered 200 with the masked arguments. Every other caller is refused 403 unsupported_obligation, naming the parameter, as in v11.0.0.
  • /health advertises field_redact_parameters (since 11.1.0): an enforcement point that declares field_redact@2 receives the masked parameters; a client can discover the capability before declaring it.
• The gateway adapters present the capability handshake by default. Under pii=redact, a request carrying personal data through the MCP and LLM routes is now redacted instead of refused. This closes the v11.0.0 known issue for those two routes. The HTTP authorization route stays refused, because a seam that cannot rewrite a body cannot discharge a redaction.
• MCP tier limits answer as tier limits. A tools/call tier gate, and a credential past its organization's principal ceiling, answer 403 (or 429 with Retry-After) with the upgrade envelope. Before, they answered 200 or 401.

Other changes

• Media.
  • Local OCR text is scanned by the platform's PII detectors.
  • Each media_analysis item carries a scanned array listing what ran. has_pii: false is a finding only when pii is listed.
• Cowork ingest (Enterprise). What cowork ingest stores is decided by the anchored engine. PII masking on this plane can no longer be weakened by an organization's settings. Content a pre-v11 custom PII policy masked is stored as sent, unless a typed policy or pack reads that detector. The audit row's policy_details.legacy_detections lists each such match.
• Legacy policy routes. They now carry X-AxonFlow-Removed-In: v12.0, and they keep answering throughout v11. The legacy tenant-policy export no longer drops rows by category: it returns the same rows as the list. The agent stamps the deprecation headers even on a request it refuses.
• Compliance (Enterprise).
  • The OJK, SEBI and US securities readiness reports count the policies in force on your organization.
  • The SEBI audit export's violations section carries a Policy ID column.
• Fresh installs. The orchestrator catches up with migrations within about 2 seconds instead of up to 30, closing the v11.0.0 known issue. The agent's dev-token endpoint, which mints user tokens, is registered only on an explicit development signal: ENVIRONMENT or DEPLOYMENT_KIND of development, dev or local, or DEPLOYMENT_MODE community. A production or prod value always removes it. The shipped compose files set ENVIRONMENT: development, so set ENVIRONMENT=production on the agent of any deployment that should not carry it.
• Privacy. No customer portal log line carries a person's email.

Known limits

Enterprise, with the Fraud & Risk Add-on.

• Validate your fraud-context objects yourself: nothing validates them on this release. The fincrime_transaction and fincrime_cohort objects are matched as sent. A malformed value, such as an amount sent as a string or a merchant category code sent as a number, produces no detection and no error: the request looks accepted, and the control you expect does not match. The deterministic controls keep applying; the score-based control does not. Check every producer against the documented field formats before relying on the add-on.
• The FinCrime approver pool is named, not enforced. A FinCrime hold names the fincrime-approvers group, but on this release any person your approval queue admits, other than the caller who raised the hold, can approve it. Limit who can reach your approval queue, or treat the group as documentation. Eligible-pool and quorum enforcement are v12.0.0.
• The scoring service image is not in the standard install image set. During early access, obtain the scoring image and its model bundle through your AxonFlow contact.

Client versions

No client release is required by this platform release; the client versions current at publication are:

Client	Version	Notes
Python SDK	9.4.0
TypeScript / Go / Java SDK	9.4.0
Rust SDK (preview)	0.11.0
openclaw plugin	2.9.1
Claude Code plugin	1.13.0
Cursor plugin	1.9.0
Codex plugin	1.9.0
Claude Desktop proxy	0.4.0
n8n node	1.2.1
Google ADK plugin	1.3.1	/health and the API reference recommend 1.3.1; v11.0.0 recommended 1.3.0, which was never published.
LiteLLM integration	1.1.0

Migrations

Four migrations run: three on every deployment and one on Enterprise.

• core/186 adds a unique index to policy_metrics. It locks the table while it builds, and per-evaluation metric writes wait for that window, so check the table's size before you upgrade.
• core/188 changes two columns of the approval queue to TEXT. It locks the approval queue while PostgreSQL rebuilds two indexes, and approvals can be neither read nor written during that time, which is about 1 second per 0.5 GB of the table. Check SELECT pg_size_pretty(pg_total_relation_size('hitl_approval_queue')); before you upgrade.
• core/187 records the first step of a step-mode plan in flight at the upgrade. It needs no action; until 187 has run, resuming such a plan answers 409.
• enterprise/161 drops three identity-settings columns v11 already ignores. Upgrade every customer portal and every agent to v11 before v11.1.0's migrations run. A v10.x portal reads and writes those columns by name, so it fails to read an organization's identity settings once they are gone. A v10.x agent's per-organization settings read fails too, and it falls back. The migration's down restores the columns, but not their values.

What this release does not claim

• policy_simulation and policy_test are still answered by the legacy dynamic-policy evaluator. The orchestrator's POST /api/v1/policies/simulate, /api/v1/policies/impact-report and /api/v1/policies/conflicts, and its POST /api/v1/policies/test, evaluate legacy policy rows, so what they report can disagree with what the anchored engine enforces. v11.0.0 deferred these two operator tools to this release; they remain on the legacy evaluator. Both surfaces are deprecated, carry X-AxonFlow-Removed-In: v12.0, and are removed in v12.0.0. To preview a decision with the enforcing engine, use the Agent's POST /api/policies/test.