Skip to main content

AxonFlow v8.6.0 Release Notes

Released 2026-06-09. v8.6.0 hardens PII governance across Decision Mode and the policy engine: a validator-assignment fix that restored basic PII detection for every tenant, Indonesian NIK/NPWP redaction closed on both the request and the response path, and self-describing, engine-fulfillable Decision Mode obligations so a Policy Enforcement Point never hand-rolls redaction. Every change ships in the platform binaries, so this release goes to both editions. No breaking changes — every API and policy-engine change is additive and backward-compatible.

Headline: PII validators were misassigned — email, phone, and IP detection are restored​

The policy engine selected the value validator for each PII policy with an exact policy-ID lookup that never matched the built-in sys_pii_* policy IDs. Every PII policy therefore fell through to its category default — the credit-card validator for the global PII category, which rejects every non-card string. The practical effect: email, phone, and ip detection never fired on the request or response path, for any tenant, and pan was checked against the wrong (Aadhaar) validator.

v8.6.0 routes every PII policy to its correct validator through a shared, deterministic resolver used by both the loader and the evaluator:

  • email / phone / ip now resolve to their correct validators (previously inert).
  • pan → the PAN validator (previously Aadhaar).
  • sys_pii_indonesia_phone / sys_pii_singapore_phone → the phone validator (previously accept-all).

This is the broadest-impact change in the release — it restored basic PII detection for every deployment. If you rely on email / phone / ip policies, they now actually fire.

Indonesian NIK/NPWP redaction is closed on every plane​

Indonesian national ID (NIK) and tax ID (NPWP) were governed on some paths but leaked on others. v8.6.0 closes the gaps so a checksum-valid NIK/NPWP is governed consistently on both legs of a call:

  • Agent response path (POST /api/v1/mcp/check-output, used by the PEP/gateway response flow and the MCP tools/call path) now derives its PII category whitelist from the enabled policies — instead of a hardcoded list that omitted pii-indonesia — and runs the Indonesian detector on responses.
  • Orchestrator / LLM-gateway response path (ResponseProcessor, covering proxy / gateway / MAP LLM responses) now runs the same Indonesian detector via a side-effect-free deep walk that masks string leaves in any decoded-JSON shape.
  • Request path — Gateway pre-check, POST /api/v1/decide, and POST /api/v1/mcp/check-input — now redacts a checksum-valid NIK under PII_ACTION=redact (previously it was only hard-denied under PII_ACTION=block).

Across all of these, warn/log detect without mutating content, redact masks, and block hard-denies — consistent PII_ACTION semantics on every plane, with redaction surfaced uniformly to the response body and the audit trail so an Indonesia-only redaction can neither leak the unmasked original nor be logged as un-redacted.

The Enterprise build supplies checksum/province-validated Indonesian PII detection (the precision behind the masking above); the Community build uses pattern-based Indonesian detection. As of this release both editions govern that PII on the request and the response path.

sys_pii_passport and sys_pii_dob now match​

The passport (block) and date-of-birth policies were inert for the same reason as the email/phone fix — no matching validator, so they were stamped the credit-card default and never matched. v8.6.0 adds dedicated passport and date-of-birth validators that are proximity-gated: the passport or birth-date indicator must immediately precede the value. Because the underlying patterns are broad and the engine has no confidence threshold, this gating prevents a generic order number from being blocked as a passport, or an invoice/due date from being redacted as a date of birth.

Singapore detectors no longer over-redact​

Fixed an over-redaction case where the broad Singapore detectors (postal code, UEN) fired on any matching number and — under engine-backed response redaction — could hard-block a benign tool response. These detectors are now label-gated: they redact only when a nearby label confirms the value. There is no loss of real PII coverage — labelled values still redact.

Decision Mode obligations are self-describing and engine-fulfillable​

Decision Mode (POST /api/v1/decide) is the Policy Decision Point / Policy Enforcement Point pattern for AI governance: an infrastructure gateway (the PEP) asks AxonFlow (the PDP) for a verdict before forwarding traffic. v8.6.0 settles how a PEP discharges an obligation so it never has to reimplement redaction.

/decide stays a pure PDP and never mutates content. Each redact_pii obligation it returns now carries a fulfillment block that names the engine call which discharges it:

{
  "verdict": "allow",
  "obligations": [
    {
      "type": "redact_pii",
      "detail": "PII detected under a redact policy",
      "fulfillment": {
        "endpoint": "/api/v1/mcp/check-input",
        "method": "POST",
        "phase": "request",
        "content_types": ["text/plain"]
      }
    }
  ]
}

A conforming PEP POSTs the content to the named endpoint and forwards the engine-redacted result — client-side redaction is impossible by construction. To support this, POST /api/v1/mcp/check-input now returns the engine-redacted request content:

  • redacted_statement — the request statement with PII masked. A PEP forwards this value instead of the original.
  • redacted — whether anything was masked.
  • redaction_evaluated — whether the detector actually ran. A PEP must fail closed when this is false (no detection config was enabled), so an un-evaluated request is never forwarded as if it were clean.

These fields are symmetric with how check-output already exposes redacted_data on the response leg — together they give two-touch redaction: request-phase via check-input, response-phase via check-output, both engine-masked.

A blessed PEP client ships at platform/shared/pep (decide → fulfill via the named endpoint → forward), with HTTP Basic auth and fail-closed behavior when an obligation is not engine-fulfillable. The reference LLM and MCP adapters were corrected to fulfill (not silently drop) the redact_pii obligation.

The obligation fulfillment block and the check-input redaction fields are documented in the Agent API endpoints reference and the docs/api/agent-api.yaml OpenAPI spec.

Capability discovery​

The agent /health capability list now advertises two entries, so SDKs, plugins, and PEPs can feature-detect the new surface without version sniffing:

CapabilitySinceWhat it signals
decision_obligations8.6.0/decide emits self-describing, engine-fulfillable redact_pii obligations (the fulfillment block).
two_touch_redaction8.6.0Request-phase (check-input) and response-phase (check-output) PII redaction both return engine-masked content.

What's NOT changed​

  • No breaking changes. All existing SDKs, plugins, and API consumers continue to work unchanged. The new API fields are additive and omitempty, so existing responses are byte-for-byte identical when no redaction occurs.
  • No schema migration required. This release touches no migrations.
  • Existing endpoints: Proxy Mode (POST /api/request), Gateway Mode (POST /api/policy/pre-check), the OpenAI-compatible endpoint (POST /v1/chat/completions), and Decision Mode (POST /api/v1/decide) all keep their existing contracts.
  • SDK and plugin versions are unchanged by this platform release and follow their own trajectories.

Upgrade notes​

Self-hosted (Docker / docker compose up)​

Pull the v8.6.0 images. No configuration changes are required — the validator fix, the Indonesian request/response redaction, and the Decision Mode obligation contract are all active on upgrade.

# 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

If you operate a Policy Enforcement Point against POST /api/v1/decide, adopt the obligation fulfillment contract: for each redact_pii obligation, POST the content to the named endpoint and forward the returned redacted_statement, and fail closed when redaction_evaluated is false. The platform/shared/pep client implements this flow.

In-VPC Enterprise (AWS CFN)​

No action required. The v8.6.0 images are drop-in.

Community-SaaS users​

No action required. The validator fix and the Decision Mode additions are available at all tiers.

Migration resources​

Last updated on