AxonFlow v11.0.0 Release Notes

Read the v10 → v11 Migration Guide before you upgrade. It has the checklist, the realm steps and the list of variables that now refuse boot.

v11.0.0 is a major. Its centre of gravity is one sentence: the policy decision and identity plane is the system. In v10.x two policy engines, one for system policies and one for tenant policies, decided each request, and a newer decision engine ran beside them behind switches that defaulted to off. In v11 the anchored engine decides on nine enforcement scopes of the twelve the plane model carries after proxy_tier's removal; the three it does not yet decide are cowork_ingest, policy_simulation and policy_test, all deferred to v11.1.0. It decides for every organization, on every deployment and edition, from the first boot. There is no mode, no opt-out and no comparison between the old model and the new one.

Breaking changes

1. A user token from an undeclared issuer is refused. On a deployment that verifies user identity, every request's subject is now admitted through the identity plane; on Community a presented user token is ignored, as in v10.x. A user token whose issuer no trust realm declares, or that carries no issuer, is refused UNKNOWN_REALM; in v10.x at the default setting it was accepted. Tokens AxonFlow mints itself are covered by a built-in realm. On Enterprise, declare your identity provider as your organization's enabled OIDC SSO configuration. Check before you upgrade: on v10.2.0 or later, run AXONFLOW_IDENTITY_COMPAT_MODE=shadow against representative traffic and search the logs for divergence=identity_refused. At the default off that search finds nothing, whatever your traffic. The realm steps.
2. One engine decides; the legacy system-policy and tenant-policy engines decide nothing. Where v11 decides a request differently from v10.x, that is intended: the two are different models and v11 makes no backward-compatibility promise between them.
3. The shipped policies are enabled from the first boot, and observe by default: 85 platform policies and 22 organization-editable policies, with most actions warn or log, redaction where content is unambiguously sensitive, and blocking for a shorter list: dangerous commands and access (among them destructive file-system and shell commands, and credential-file, cloud-metadata and internal-network access), DROP TABLE and TRUNCATE, two SQL-injection patterns, prompt-injection attempts in a request, administrative-table access on the proxy request path, and a few condition-based, country-specific and media policies. Shipped Policy Posture lists every one.
4. Policies you authored in the legacy tables are not carried forward. On Enterprise, import them with the operator import and activate the result; on Community, re-author them.
5. The legacy policy write APIs answer 409 LEGACY_POLICY_WRITE_FROZEN, naming the typed route, on every surface including template apply. Legacy reads remain as a deprecated export surface until v11.1, every response carrying the successor Link, X-AxonFlow-Removed-In: v11.1 and a Deprecation header; POST …/test on the legacy families is removed; and the portal's legacy Policies page and its unified policy reads are removed.
6. Variables and a licence shape that now refuse boot: the decision shadow and identity compatibility variables (and their CloudFormation parameters), any narrowing value of the detection-scope variables (*_STATIC_POLICIES_ENABLED=false, *_STATIC_POLICIES_SKIP_CATEGORIES, MCP_STATIC_POLICIES_CONNECTORS), the MCP_DYNAMIC_POLICIES_* family, AXONFLOW_FINCRIME_SCORER_URL and AXONFLOW_FINCRIME_SCORER_TIMEOUT_MS, AXONFLOW_HITL_GRANT_TTL_SECONDS, and a licence that names no organization. The v10.x docker-compose.enterprise.yml sets the FinCrime scorer timeout by default, so clear it before you upgrade; the migration guide lists every one.
7. evaluated_policies carries v11 policy identifiers (corpus:static_policies:sys__pii__ssn:warn where v10.x returned sys_pii_ssn). Update SIEM queries, dashboards and alerts.
8. A policy that requires approval on POST /api/v1/decide is refused, with a reason beginning approval_required, rather than answered needs_approval.
9. The identity settings admin API no longer carries compat_mode, decision_shadow_mode or decision_shadow_planes; a request that sends one is refused 400.
10. Session allow-bypass overrides no longer bypass. The engine has no opt-out.
11. The FinCrime pack's seeded legacy rows decide nothing; the pack itself decides. It ships as a typed document that AXONFLOW_POLICY_PACKS=fincrime installs, and its controls bind on the Agent's planes only, and on a request plane only where that plane's call site admits their detector's category; see its page.
12. Detection action variables no longer set an action (PII_ACTION, SQLI_ACTION, AXONFLOW_PROFILE and the rest). They are ignored with a boot warning and counted, rather than refused. Their four CloudFormation parameters are gone from the AWS Marketplace template, so a stack update that still passes one fails.
13. Community and Evaluation enforce their licence's scale limits on distinct users, service credentials, agent nodes and authored policies. A request over a limit is refused 402 with an ERR_TIER_LIMIT_ code; the limits are in the migration guide.
14. Per-policy overrides move to a typed lever. The v11 engine does not read the v10.x per-policy override routes (/api/v1/system-policies/{id}/override, /api/v1/policy-overrides), which are deprecated; existing overrides are imported once at upgrade into the typed per-policy lever. A detection-posture override reaches the engine for the platform's policies in its category.

Am I affected?

Everyone who upgrades. The engine that decides your requests changes, and the shipped policies start deciding from the first boot. Read Shipped Policy Posture before you upgrade, so no shipped action surprises you.

Anyone who sends per-user tokens to an Enterprise deployment. Declare a realm for every issuer before you upgrade, or those requests are refused. This is the change most likely to turn a working integration into refusals.

Anyone who authored their own policies. They stop deciding at upgrade until you import or re-author them.

Anyone with automation that writes policies. Legacy writes answer 409; move it to /api/v1/typed-policies.

Anyone reading decision records. evaluated_policies identifiers change, and records gain engine, policy_bundle and subject_type.

Anyone who set a v10.x shadow, compatibility or detection-scope variable. The process refuses to start until it is removed.

Community and Evaluation deployments. The licence's scale limits are enforced; compare your users, service credentials and agent nodes with them before you upgrade.

Community deployments. Governed from the first boot with nothing to configure; every request is decided for its client credential, as before no per-user identity is verified, and the boot refusals apply.

The decision plane is the product

• One engine on the enforcement planes. The same engine decides Decision Mode, Gateway Mode's pre-check, Proxy Mode, MCP governance on the request and the response, the OpenAI-compatible route, the Orchestrator's response governance, the Workflow Control Plane and Multi-Agent Planning.
• The shipped set runs from the first boot. An organization that has published nothing runs the shipped policies and the deployment's baseline permissions, composed and signed in the process; nothing is written to your database. No request is refused because no policy has been written.
• Every caller has a principal. A verified user token is decided for that user. Where there is no user identity (Community, Community SaaS, the OpenAI-compatible route), the client credential is the principal, recorded as subject_type: Client. On a deployment that verifies user identity, a user token that fails verification is still refused.
• Every decision says what decided it. engine, policy_bundle and subject_type on the wire and the audit row, and /health reports the engine on each plane.

The v11 policy and identity model explains the model from end to end, and Policy and Identity Control Plane describes it in depth.

What your organization controls

• Each shipped policy: disable, re-enable, or change its action to log, warn, redact or block, for your organization only.
• The platform policies of a detection category: record a detection-posture override, which now reaches the engine. dangerous_command reaches the four indirect prompt-injection guards; the organization-editable policies, among them the dangerous-command blocks, change in your own document.
• Policies of your own: a typed policy document written through /api/v1/typed-policies or the portal's Policy Authoring page. The deployment's baseline permissions compose beside it, so it narrows what is permitted with constraints. A new document starts from the organization-editable policies, activating it replaces them, and the publish response lists any your document drops. No variable is needed to author.

Removed

• The decision shadow mode and the identity compatibility mode, their variables, their per-organization settings and their comparison observers.
• The legacy verdict engines as authors of any verdict. Their code is removed where that is easy or important, and the rest in a later release, with no behaviour change.
• The legacy policy write paths, the legacy /test evaluation routes, and the portal's legacy Policies page.

Client versions

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.0
LiteLLM integration	1.1.0

Migrations

Twenty-two migrations run, by deployment shape: 13 core on every deployment, 6 Enterprise, 2 Community SaaS and 1 for the banking vertical. None deletes a policy you authored: the legacy tables become read-only and stay readable for export. Three need your attention: core/178 fails the upgrade on a deployment holding a typed row under another root, and names the table; core/181 has an ordered rollback, so roll the binaries back before applying its down file; and core/183 imports each legacy per-policy override into an unpublished draft, which decides nothing until you publish it. The migration guide lists each one.

What this release deliberately does not claim

• No parity with v10.x. Nothing compares the two engines, and no test measures agreement between them. Where they differ, v11's decision is the product's.
• No opt-out. There is no setting that returns a plane, an organization or a deployment to the v10.x engines.
• The shipped actions are a default, not a ceiling. Every one is switchable per organization.