Skip to main content

AxonFlow v9.8.0 Release Notes

v9.8.0 is a minor release with one new capability and two fixes. Enterprise deployments gain agentgateway / Envoy PEP adapters — a gRPC adapter service that lets an agentgateway (or any Envoy-based) data plane call AxonFlow as its Policy Decision Point across all three of the gateway's native external-policy seams. On the fix side, every remaining timezone-naive TIMESTAMP database column is retyped to TIMESTAMPTZ, closing a class of wrong-instant bugs on deployments whose database session timezone is not UTC, and the published OpenAPI specifications are reconciled with the shipped platform surface.

Unlike v9.7.0, this release runs database migrations on startup (one core, one enterprise-only) — see Upgrading below. No SDK or plugin releases ride this train; the compatibility matrix advertised on /health is unchanged from v9.7.0.

Added​

agentgateway / Envoy PEP adapters (Enterprise)​

A new gRPC adapter service, axonflow-gateway-adapters, lets an agentgateway data plane consult AxonFlow as its Policy Decision Point on every governance touchpoint, across all three of the gateway's external-PDP seams:

  • ExtMcp — MCP tools/call governance: the verdict comes from the decision endpoint, and both tool parameters (request plane) and tool results (response plane) can be engine-redacted before they continue.
  • Envoy ext_authz — headers-only allow/deny for HTTP traffic. Because this seam cannot rewrite a body, a verdict that carries a redaction obligation is denied with a pointer to the ext_proc adapter — never forwarded unredacted, never locally masked.
  • Envoy ext_proc — streaming body inspection: engine redaction of the buffered request body, and response-body governance through the engine's check-output contract.

The adapters contain zero local policy or redaction logic — every verdict and every mutated byte comes from the AxonFlow engine — and they enforce the platform's failure postures: the request plane defaults to fail-closed (the fail-open opt-in applies only to an unreachable PDP; an engine rejection or an unfulfillable redaction obligation always blocks), and the response plane is unconditionally fail-closed, including when the engine reports that redaction was not evaluated. Deny responses carry the decision_id and trace_id for audit correlation, inbound bearer tokens are validated by the PDP rather than trusted locally, and a bounded circuit breaker fails fast per plane posture when the engine is repeatedly unreachable.

Alongside the adapters, the shared Go PEP client package gains a CheckOutput response-governance round-trip (wire shape pinned by contract tests) — the same blessed path any custom policy enforcement point can use for response-plane governance.

The adapters require a PDP at platform v9.7.0 or later (they depend on the redaction_evaluated response-plane contract introduced there). Setup, a reference agentgateway configuration covering all three seams, the identity/attribution model, and the full failure-posture matrix are on the agentgateway integration page.

Fixed​

Timezone-naive timestamp columns retyped to TIMESTAMPTZ (Community)​

41 TIMESTAMP (without time zone) columns across 19 tables — sessions, API keys, gateway contexts, audit and violation logs, organizations, connectors, evidence exports, and others — stored wall-clock digits with no offset. Any component reading or writing them under a non-UTC database session silently shifted instants; the original symptom was gateway pre-check approvals expiring at the wrong moment on non-UTC hosts.

Two migrations (core migration 142 and enterprise migration 133) retype every such column, each in a single transaction:

  • The conversion timezone is pinned to UTC (SET LOCAL TIME ZONE 'UTC' + USING ... AT TIME ZONE 'UTC'), so a replay under a non-UTC session — a psql session with PGTZ set, or an RDS parameter-group timezone — cannot shift stored instants.
  • Dependent views are dropped and recreated around each retype, including existence-guarded handling of the banking-vertical retention views: on upgrades of existing banking/SaaS databases those views would otherwise abort the migration mid-boot. Fresh installs and deployments without the banking vertical are untouched by the guards.
  • Both migrations have exact down migrations, and an upgrade-path test applies the real per-mode migration chains to an existing-release database pinned to a +05:30 session zone, asserting stored instants convert exactly and round-trip through the down migrations.

Defensive UTC normalization is also added at the confirmed local-time write sites (the gateway pre-check expiry and the audit-queue writers), and the bootstrap/demo schema copies plus the connector registry's fallback DDL are updated to match.

API reference reconciled with the shipped platform (Community)​

The four OpenAPI specifications (agent-api.yaml, orchestrator-api.yaml, policy-api.yaml, masfeat-api.yaml) and the Enterprise API reference pages had drifted from the shipped code in all three directions:

  • Phantom paths removed — operations that never existed on the platform, including unprefixed MCP check routes, top-level accuracy/conformity families, and circuit-breaker activate/deactivate (the real operations are trip/reset/check).
  • Missing shipped endpoints documented — audit session-summary, audit export and report, the OJK compliance module, the dynamic-policies family, OTLP metrics/logs ingest, and the full HITL surface.
  • Wrong shapes corrected — the audit-search response envelope, check-output response fields, and the circuit-breaker schema now match what the platform actually serves.

Every documented operation is now verified against the handler source. The MAS FEAT spec is re-wired into the OpenAPI CI gates it had silently dropped out of, the agent spec is kept in lockstep with the platform's path-template registry by a regression test, and the EU AI Act endpoint family — briefly removed during the reconciliation — is restored as documented proxied endpoints: those routes are real and are served through the agent's proxy.

Changed​

The agent spec now states the single-entry-point contract explicitly (Community)​

agent-api.yaml now carries a cross-reference note making the deployment contract explicit: the agent is the single entry point — clients never call the orchestrator directly — and every /api/v1/* endpoint is reachable through the agent, including the endpoint families the agent transparently proxies (audit, decisions, overrides, plans/workflows, cost/budgets/usage, connectors, LLM-provider management, evidence, and the regulatory-compliance families). Those proxied families remain documented once, in their canonical specs, rather than being duplicated into the agent spec and maintained in lockstep.

Upgrading​

v9.8.0 runs two database migrations on startup (core 142 and, on Enterprise, 133). They execute automatically and transactionally; each has a down migration.

# 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

Migration duration: retyping a column rewrites its table, so the boot migration takes time proportional to the size of the affected tables — deployments with large audit or violation tables should expect a longer-than-usual first boot and schedule the upgrade accordingly.

Behavioral note: after the migration, the affected columns store timezone-aware instants. On UTC-session deployments (the default) API responses are unchanged; deployments whose database session ran non-UTC will see previously shifted instants come back correct — which is the fix. Direct-SQL reporting against the affected columns now sees timestamptz values instead of naive local digits.

In-VPC Enterprise (AWS CFN)​

Redeploy with the v9.8.0 images. The migrations run automatically on agent startup; the same duration note applies to large audit tables.

Last updated on