AxonFlow v9.0.0 Release Notes (DRAFT)

Draft — not yet released

This page is a draft of the v9.0.0 release notes. v9.0.0 will be cut when Phase 8 of the v9 identity epic (FORCE ROW LEVEL SECURITY rollout) completes its soak. The terminology rebrand and identity plumbing have already landed in the v8.x train as additive changes; the major-version cut marks the point at which RLS becomes enforced and X-Tenant-ID enters its single-major-version deprecation window.

Identity model cleanup + Row-Level Security enforcement. v9 is the major version where AxonFlow's identity model becomes self-consistent: org_id is the customer organization (the RLS boundary), client_id is the API credential, and the license payload's deployment identity is separated from both. Row-Level Security is now actually enforced on the application role — pre-v9 it was defined but inert because the agent connected as the table owner.

This is a major version because Row-Level Security enforcement changes the behaviour of direct SQL queries against the AxonFlow application database under the application role. For customers using only the SDKs / plugins / HTTP API, there is no breaking change — JSON field names are unchanged, the X-Tenant-ID header is accepted as a deprecated alias, and Basic Auth credentials keep working.

For the full mapping, see the v8 → v9 Migration Guide.

What's new

Identity model is now three distinct identifiers

Pre-v9 conflated customer organization, API credential, and license deployment identity. v9 separates them:

Identifier	What it is	Where it lives
`org_id`	Customer organization. Row-Level Security boundary.	DB rows, auth context, `X-Org-ID` header (forwarded)
`client_id`	API credential / app identity inside an org.	Basic Auth username, auth context, `X-Client-ID` header
deployment license identity	The AxonFlow installation that booted this agent. Never written to customer rows.	License payload (V3 `deployment_id` field, shipped 2026-05-19 in PR #2257; V2 `org_id` field still accepted as back-compat alias), `ORG_ID` env, stack config

The SDK config field clientId already corresponded to v9's client_id. No SDK code changes are required.

Row-Level Security is enforced on the application role

Pre-v9, RLS policies were defined but bypassed at runtime because the agent connected as the table owner. v9:

Adds a non-owner application role for normal request traffic.
Adds axonflow_platform_admin with BYPASSRLS for legitimate cross-org workers (Community-SaaS sweep, activity-update worker, usage aggregators, support tooling).
Sets app.current_org_id at every request entry.
Enables FORCE ROW LEVEL SECURITY table-by-table across nine batches, identity tables last.

Breaking change for direct SQL only: if you connect to the AxonFlow application database with the application role and bypass the HTTP API, you must set app.current_org_id before SELECTs or your queries return zero rows. Use the axonflow_platform_admin role (or master) for legitimate cross-org access.

`X-Tenant-ID` deprecation window opens

Version	`X-Client-ID`	`X-Tenant-ID`	Agent → orchestrator forwarding
v8 pre-#2233	not recognized	used internally for cross-process forwarding	forwards `X-Tenant-ID` only
v8.x post-#2233	recognized inbound + forwarded outbound	accepted as alias	forwards both `X-Client-ID` and `X-Tenant-ID`
v9 (this release)	canonical	accepted as deprecated alias	forwards both, with `X-Client-ID` as primary
v10 (planned)	required	rejected	forwards `X-Client-ID` only

The JSON tenant_id field on /api/v1/register responses, in Plugin Pro license tokens, and in audit-log payloads stays unchanged through v9. v10 will rename to client_id on the wire.

AxonFlow-operated deployments use the `axonflow-` prefix

Internal AxonFlow deployments (community-saas, production-us, travel, healthcare, banking) migrate to axonflow--prefixed deployment identities (axonflow-community-saas, etc.). Telemetry classification uses the axonflow-internal- prefix as the primary signal for "this row came from AxonFlow's own infrastructure" rather than the previous shape-based heuristics.

Customer org_id values are unaffected — they stay free-form and should not start with axonflow- unless the customer is AxonFlow.

Schema additions

Additive migrations across the v8.x train and finalised in v9:

client_id columns added to credential / audit / policy / execution / service-identity tables.
Backfill: client_id = tenant_id for hot-path credential tables; org_id = client_id for Community-SaaS cs_* rows.
Composite indexes (org_id, client_id, timestamp/created_at) on audit tables.
set_org_id() / set_config('app.current_org_id', ...) set at every request entry.

License payload V3 — `deployment_id` field

Phase 5 of the v9 epic (PR #2257, merged 2026-05-19) introduced a V3 license payload that adds a deployment_id JSON field carrying the deployment/licensee identity. V3 mints both deployment_id and org_id with the same value so V2-only readers continue to validate signed payloads. The agent now exposes a LicenseDeploymentID() accessor; new code should prefer it over reading .OrgID directly. Operators rotating deployment identity across the 15 AxonFlow-operated stacks use the runbook + scripts/deployment/rotate-deployment-identity.sh script shipped in the same PR.

Customers do not need to regenerate licenses for v9. V2 licenses keep working through v9 and beyond — V3 is purely a clarity rename, and the org_id back-compat field stays on V3 payloads.

Breaking changes

Surface	What breaks	Workaround
Direct SQL with application role	SELECTs return zero rows unless `app.current_org_id` is set first	Set the session variable, or connect via `axonflow_platform_admin` for cross-org needs
Background workers spanning orgs (Community-SaaS sweep, etc.)	Must use `axonflow_platform_admin` role	AxonFlow-operated deployments already migrated; self-hosted operators with custom cross-org workers must adjust

Everything else stays compatible — SDK clients, HTTP API consumers, plugins, and Basic Auth credentials all keep working.

What does NOT change

Wire-level JSON field names (tenant_id JSON field stays — v10 renames to client_id).
X-Tenant-ID header (accepted through v9 as deprecated alias).
Basic Auth credential format and the SDK's clientId / clientSecret config.
The license validation mechanism — AXONFLOW_LICENSE_KEY still drives tier enforcement.
Plugin Pro license tokens (tenant_id claim semantics unchanged).
Community-SaaS cs_* credentials (no re-registration required).
Self-hosted defaults (local-dev-org default ORG_ID is preserved across versions).

Upgrade notes

Self-hosted operators: upgrade the platform image to v9.0.0 with no configuration changes. If you maintain custom SQL tooling against the application DB, ensure it sets app.current_org_id or uses the axonflow_platform_admin role.
In-VPC Enterprise: no configuration changes required. Existing licenses, credentials, and ORG_ID values keep working.
Community-SaaS users: no action required. Existing cs_* credentials and Plugin Pro entitlements keep working.
SDK users: upgrade to the v9-companion SDK release on the next dependency refresh. Existing v8.x SDK callers keep working — the v9 platform accepts X-Tenant-ID as a deprecated alias.

Migration resources

v8 → v9 Migration Guide — the full mapping including the cheat sheet, header timeline, and verification commands.
Auth and Header Matrix — Identity Primer — the three-identifier model.
License Management — license deployment identity distinguished from row identity.

What's new​

Identity model is now three distinct identifiers​

Row-Level Security is enforced on the application role​

X-Tenant-ID deprecation window opens​

AxonFlow-operated deployments use the axonflow- prefix​

Schema additions​

License payload V3 — deployment_id field​

Breaking changes​

What does NOT change​

Upgrade notes​

Migration resources​

See also​