Skip to main content

AxonFlow v8.2.0 Release Notes

Released 2026-05-25. Decision Mode brings the Policy Decision Point / Policy Enforcement Point pattern (established by OPA, XACML, Cedar) to AI governance. The OpenTelemetry decision tracer wires every policy decision into a standard observability pipeline. Three new ecosystem packages land on PyPI and npm. Fully additive — no breaking changes, no schema changes, no migration impact.

Headline: Decision Mode — PDP/PEP for AI governance​

Decision Mode brings the Policy Decision Point (PDP) / Policy Enforcement Point (PEP) architecture pattern — the same pattern behind OPA, XACML, and Cedar — to AI governance. Instead of routing traffic through AxonFlow (Gateway Mode) or embedding the SDK in your application (Proxy Mode), Decision Mode lets infrastructure gateways (the PEP) query AxonFlow (the PDP) for a policy verdict before forwarding a request to the upstream LLM, tool, or agent.

The gateway calls POST /api/v1/decide with a structured request describing the stage (llm, tool, or agent), caller identity, target, and query. AxonFlow evaluates its policy engine and returns a verdict (allow, deny, or needs_approval) along with the evaluated policies, reasons, and a W3C trace_id for end-to-end trace correlation.

Key properties:

  • Same shared-policy engine as Gateway Mode's POST /api/policy/pre-check — policies are defined once and enforced everywhere.
  • Available at all tiers (Community and Enterprise).
  • M1 scope covers static policies (PII detection, SQL injection, RBI India compliance, compliance categories). Dynamic/custom policy support is planned for M2.
  • Architecture documented in ADR-056 (Decision Mode).

Reference PEP adapters​

Two reference Policy Enforcement Point adapters ship as working examples:

AdapterPathLanguageProtocol
LLM + Agent Gatewayexamples/integrations/decision-mode-adapter/GoHTTP middleware
MCP Gatewayexamples/integrations/decision-mode-mcp-adapter/GoJSON-RPC 2.0

Both include docker-compose PoC harnesses with mock upstreams and test scripts. The adapters are reference implementations — fork and adapt them for your gateway stack.

OTel decision tracing​

Every policy decision (from both POST /api/policy/pre-check and POST /api/v1/decide) now emits an OpenTelemetry span named axonflow.decision carrying eight attributes:

AttributeDescription
decision.idUnique decision identifier
decision.stagellm, tool, or agent
decision.verdictallow, deny, or needs_approval
decision.policy_idsEvaluated policy identifiers
decision.latency_msPolicy evaluation latency
decision.reasonsHuman-readable denial/approval reasons
org.idOrganization identifier
tenant.idTenant identifier

The W3C trace_id is returned in the response body so PEP adapters can propagate it downstream for end-to-end trace correlation.

Configuration​

Env varDefaultDescription
AXONFLOW_OTEL_ENDPOINT(empty — noop)OTLP/gRPC endpoint. When empty, tracing is disabled with zero overhead.
AXONFLOW_OTEL_SERVICE_NAMEaxonflow-agentService name in OTel spans.
AXONFLOW_OTEL_SAMPLE_RATE1.0Parent-based sampling rate (0.0–1.0).

For local development, docker-compose.otel.yml boots an OTel collector and Jaeger UI on port 16686:

docker compose -f docker-compose.yml -f docker-compose.otel.yml up -d

New integration packages​

Three standalone ecosystem packages ship alongside v8.2.0. Each is MIT-licensed, maintained in its own repository, and published to its language-specific registry.

axonflow-litellm v1.0.0​

LiteLLM SDK callback integration via CustomLogger subclass. Intercepts LLM calls for policy checks and audit logging.

pip install axonflow-litellm

axonflow-google-adk-plugin v1.0.0​

Google Agent Development Kit plugin for policy checks and HITL approval within ADK agent flows.

pip install axonflow-google-adk-plugin

@axonflow/n8n-nodes-axonflow v1.0.0​

n8n community node with four operations: Check Policy, Record Decision, Audit Log, and Wait for Approval.

npm install @axonflow/n8n-nodes-axonflow

Fixed​

  • HITL require_approval policies now correctly return the require_approval sentinel in Gateway Mode pre-check. When a custom policy with action=require_approval matched, the pre-check response returned the policy description as block_reason instead of the require_approval sentinel string that SDKs and plugins check to trigger the HITL approval flow. The approval flow silently did not activate. Now require_approval policies return block_reason="require_approval" so SDK-side HITL detection works correctly.

What's NOT changed​

  • No breaking changes. All existing SDKs, plugins, and API consumers continue to work unchanged.
  • No schema changes. No new migrations in this release.
  • SDK versions: Recommended Python / TypeScript / Go / Java at v8.2.0; Rust preview at v0.4.0. Minimum: v8.0.0. Previous SDK versions keep working.
  • Plugin versions: Recommended claude / cursor / codex at v1.5.2; openclaw at v2.6.1. Minimum: v1.4.0 / v2.4.0. Unchanged from v8.0.0.

Upgrade notes​

Self-hosted Community (Docker / docker compose up)​

Pull the v8.2.0 image. No migrations to apply. To enable OTel tracing, set AXONFLOW_OTEL_ENDPOINT to your OTLP/gRPC collector.

In-VPC Enterprise​

No preflight required for v8.1.0 to v8.2.0. Existing licenses, credentials, and DSN secrets keep working.

Community-SaaS users​

No action required.

SDK users​

Existing v8.1.0 / v8.2.0 SDK callers keep working. No SDK changes required for the new platform features.

Plugin users​

No action required. Existing plugins keep working.

Migration resources​

Last updated on