Skip to main content

AxonFlow v9.3.0 Release Notes

v9.3.0 is a minor release focused on visibility: knowing who ran a governed AI action, in which session, and being able to read, filter, report on, and export that activity from the portal. It records a per-developer and per-session identity on the canonical audit record, adds a filterable audit-logs page with an aggregate report view and CSV/JSON export, ingests the native Claude Cowork and Claude Code OpenTelemetry stream as canonical audit records, and labels the decision-mode metrics by the integration that produced them so a new Claude Code dashboard can break governance activity down by client and by developer. It also fixes the Usage page so governed Claude Code traffic is counted rather than reading zero. Schema changes are additive and backward-compatible, and the new capabilities are additive or opt-in, so it is a drop-in upgrade from v9.2.x.

Added​

Per-developer and per-session identity on the audit record​

By default a governed request is attributed to the client that made it — the organization, tenant, and license. v9.3.0 adds two optional identity dimensions to the canonical audit_logs decision record so activity can be attributed to a person and a session:

  • user_email — the individual developer, read from the X-User-Email request header.
  • session_id — the AI-tool session that produced the request, read from the X-Session-Id request header. A new nullable session_id column is added to audit_logs (migration core/129), with a partial index for session lookups.

Both are read from request headers only and are never trusted from a request body, so a payload cannot spoof another developer's identity into the audit trail. Both are recorded on both governance planes — the agent's policy-check path and the orchestrator's tool-call audit path. When no email is supplied, the record falls back to a client-scoped synthetic id rather than a blank value, so attribution degrades gracefully. With an identity supplied, the portal's User column, the audit User filter, and the per-user views on the Claude Code dashboard resolve to an individual. Identity is asserted for visibility, not authenticated; the organization and tenant on every stored row still come from the license.

A filterable audit-logs portal with report and export​

The customer portal's Audit Logs page becomes a first-class read surface. A Log Explorer lets you filter the canonical decision records by date range, user email, tenant, and action (allowed, blocked, redacted, needs-approval, error), and expand any row into a full detail panel — decision and plane, the (redaction-masked) request and response, the matched policy and reasons, the tool and gateway involved, the correlation and session identifiers, latency and cost, and compliance flags. A Report by Action view returns per-verdict counts, average latency, and the top policies that fired for the filtered window. Both views are backed by a new orchestrator audit read API: GET /api/v1/audit/{id} for a single record, POST /api/v1/audit/report for the aggregate, and POST /api/v1/audit/export?format=csv|json for a bounded (50,000-row) export of the filtered set that flags truncation with a response header.

Claude Cowork and Claude Code OTEL ingest (Enterprise)​

Enterprise deployments can now ingest the native OpenTelemetry stream emitted by Claude Cowork (the agentic surface in Claude Desktop) and Claude Code, and land every event as a canonical, redacted, signed audit_logs record — the same store every other governance plane writes to. The endpoint (POST /v1/logs) is authenticated; the organization and tenant on every stored row are derived from the license, never from the (spoofable) telemetry attributes. User content is masked by the policy engine before anything is persisted, regardless of the deployment's PII action, and content is withheld rather than stored in the clear if detection is unavailable. This gives a single, central place to capture Cowork activity — which otherwise has no governed audit trail — alongside unspoofable per-developer attribution for Claude Code.

Decision origin label and a Claude Code dashboard​

The decision-mode metrics now carry a low-cardinality origin label — a closed set of claude-code, claude-desktop, sdk, plugin, gateway, and unknown — classified from the X-Axonflow-Client header and the caller's gateway id, so governance activity can be sliced by client type without exploding label cardinality. Two supporting series land alongside it: an obligations counter (the redact_pii obligation on an allow is the "redacted" signal) and a blocks counter keyed by the top blocking policy, with per-tenant custom policy ids collapsed to a single bounded label. A new Claude Code Governance Grafana dashboard uses these to show allowed / blocked / redacted per integration, plus a per-developer breakdown from the span-metrics pipeline. See the Grafana Dashboard reference.

Fixed​

Usage & Analytics counts governed Claude Code traffic​

The portal Usage page could read zero total API calls when the only traffic was governed MCP tool calls — the Claude Code path. Two things caused it: governed tools/call traffic was not being recorded as a usage event, and the page read a detail endpoint that does not return the summary totals. v9.3.0 records one api_call usage event per served, authenticated tool call, points the page at the summary endpoint, scopes the read to the caller's organization, and includes the current day in the default window. Behavior change: the Usage page now reflects governed Claude Code and MCP activity in Total API calls and the event-type breakdown, where it previously undercounted or read zero.

Upgrading​

v9.3.0 is a drop-in upgrade from v9.2.x. The database migration applies automatically on startup and adds the nullable session_id column to the audit record without changing existing behavior. Per-developer and per-session identity are recorded when the X-User-Email / X-Session-Id headers are present and fall back to the prior client-scoped attribution when they are not, so no configuration is required to upgrade. The Cowork / Claude Code OTEL ingest endpoint is Enterprise-only and opt-in. The one behavior change to expect is on the Usage page, which now counts governed Claude Code and MCP traffic it previously missed.

# 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

In-VPC Enterprise (AWS CFN)​

Redeploy with the v9.3.0 images. The migration applies automatically on startup. Per-developer attribution is populated whenever a client sends the X-User-Email / X-Session-Id headers; the Claude Code plugin v1.8.0+ (via an AXONFLOW_USER_EMAIL environment variable) and the Claude Desktop proxy v0.3.0+ emit them, and requests from clients that do not send them keep their prior client-scoped attribution. To enable Cowork / Claude Code OTEL ingest, point the client OTLP exporter at the agent's logs endpoint.

Community-SaaS users​

No action required.

Last updated on