Skip to main content

AxonFlow for Insurance

Insurance carriers and insurtechs are deploying AI agents that adjudicate claims, price risk, detect fraud, and communicate with policyholders. Every one of those workflows touches personally identifiable data, makes decisions with direct financial impact on consumers, and operates under regulatory scrutiny that is tightening quarter by quarter. AxonFlow provides the runtime governance layer that sits between your AI agents and the actions they take -- enforcing policies, detecting sensitive data, gating high-risk decisions for human review, and producing the audit trail your compliance team and regulators require.

This page maps AxonFlow capabilities to concrete insurance workflows, regulatory requirements, and deployment patterns. Everything described here is shipped and available today.

The insurance AI governance challenge​

Insurance regulators are moving quickly to address AI risk. The NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers is model guidance that individual states may adopt or adapt; teams must check the rules and bulletins in each operating state. In the EU, insurers assess AI-related operational and model risk within applicable Solvency II and DORA obligations, including ICT third-party risk.

These frameworks converge on four demands:

  1. Auditability. In-scope AI-assisted decisions need records aligned to the insurer's state, product, model-risk, and examination obligations. AxonFlow records policy outcomes on integrated paths.
  2. Human oversight on consequential decisions. Oversight expectations depend on the jurisdiction and use case. Insurers can translate their review policy into deterministic approval gates before a client executes a configured consequential action.
  3. Data protection at every boundary. Social Security numbers, dates of birth, driver's license numbers, medical identifiers, and financial account details must not leak into LLM prompts, MCP connector payloads, or downstream tool calls. Detection must be accurate (checksums, not just regex), and the enforcement action must be configurable per environment and per data type.
  4. Fairness governance evidence. State requirements can call for governance and documentation addressing unfair discrimination. AxonFlow records policy checks and human approvals, but it does not perform statistical fairness or disparate-impact testing.

Generic LLM proxies do not solve this. A proxy that rewrites prompts cannot enforce approval gates on multi-step agent workflows like claims adjudication. A logging layer that captures raw requests cannot produce the structured audit records a state insurance examiner or Solvency II supervisor requires. A gateway that detects PII but cannot distinguish between a Luhn-valid credit card number and a random digit string will either miss real violations or flood your compliance team with false positives.

AxonFlow is purpose-built for this problem. It governs the entire agent execution lifecycle -- LLM calls, MCP connector invocations, multi-step workflows, and external tool use -- with policy enforcement, structured audit logging, PII detection with checksum validation, and human-in-the-loop approval gates.

Use cases​

1. Claims processing agent​

What the agent does: An AI agent triages incoming claims, extracts information from submitted documents (medical records, police reports, repair estimates), cross-references policy terms, and drafts an initial adjudication recommendation.

What could go wrong: The agent includes the claimant's SSN or date of birth in a prompt to an external LLM for summarisation. Or it renders a final claim decision without human review, violating the NAIC expectation that consequential consumer decisions involve human oversight. Or the agent approves a claim above the delegated authority threshold without escalation.

How AxonFlow can help:

  • HITL approval gates pause any claim adjudication above a configurable threshold or for specific claim categories. The require_approval policy action routes the step to a human approval queue where an adjuster approves or rejects via the API. Unanswered requests auto-expire after 24 hours (Evaluation) or a configurable TTL (Enterprise).
  • PII detection catches SSNs (format-validated), dates of birth, and credit card numbers (Luhn-validated) before they reach an LLM. The action is configurable per data type: block, redact, warn, or log. See PII Detection.
  • Audit logging records governed policy checks with decision_id, verdict, evaluated policies, timestamp, and available identity. Claim evidence, model rationale, and the final adjudication remain in their authoritative systems. See Audit Logging.

2. Underwriting copilot​

What the agent does: An underwriting copilot assists underwriters by pulling applicant data from internal systems, querying external data sources (MVR reports, credit scores, property databases) via MCP connectors, running risk calculations, and drafting a coverage recommendation with premium.

What could go wrong: The copilot leaks the applicant's driver's license number, SSN, or medical information into an LLM prompt used for risk narrative generation. Or an external data source returns sensitive information that the copilot forwards to an unauthorised downstream tool. Or the copilot recommends coverage terms without the mandatory underwriter sign-off, creating E&O exposure.

How AxonFlow can help:

  • PII detection identifies supported identifier types on configured governed paths. See PII Detection.
  • MCP connector governance applies three-phase policy evaluation to calls routed through the governed MCP path.
  • HITL gates can pause the configured coverage-recommendation step. The underwriting workbench must enforce the approval result before issuing a quote.
  • Evidence export (Evaluation and Enterprise) produces audit packages documenting every policy evaluation, PII detection event, and human approval in the underwriting workflow. See Evidence Export.
# Policy: require human approval on coverage recommendations
name: underwriting-coverage-approval
category: sensitive-data
action: require_approval
conditions:
  - field: step_metadata.step_type
    operator: eq
    value: coverage_recommendation
  - field: step_metadata.premium_amount
    operator: gt
    value: 50000

3. Fraud detection agent​

What the agent does: A fraud detection agent monitors incoming claims in real time, cross-references claimant history across multiple systems, identifies patterns consistent with fraud rings or staged accidents, and escalates suspicious claims to the Special Investigations Unit (SIU).

What could go wrong: The agent includes claimant SSNs, phone numbers, or addresses in prompts to an external LLM. Or an analyst interacts with the agent using a prompt that contains SQL injection. Or the agent flags claims aggressively without a review gate, causing legitimate claims to be delayed. Or the LLM provider goes down and claims flow through unmonitored.

How AxonFlow can help:

  • PII detection with checksum validation catches SSNs (format-validated), credit card numbers (Luhn-validated), phone numbers, and email addresses before they reach external LLMs. Configured via PII_ACTION (LLM path), GATEWAY_PII_ACTION (gateway path), and MCP_PII_ACTION (connector path).
  • SQL injection scanning evaluates configured input or MCP response paths and can block, warn, or log detected patterns. It does not inspect every database query automatically. See SQL Injection Scanning.
  • HITL approval can pause a configured SIU escalation step for human review; it does not determine whether the underlying model is fair or accurate.
  • Circuit breaker and kill switch (Enterprise) can reject subsequent governed decision requests after a configured threshold. They do not cancel provider or tool work already dispatched. See Choosing an Integration Mode.
# Decision Mode: check a fraud-detection query before it reaches the LLM
curl -s -X POST http://localhost:8080/api/v1/decide \
  -H "Content-Type: application/json" \
  -d '{
    "stage": "llm",
    "caller_identity": {
      "gateway_id": "fraud-detection-gw",
      "tenant_id": "claims-siu"
    },
    "target": {
      "type": "llm",
      "model": "gpt-4o",
      "provider": "openai"
    },
    "query": "Analyse claims history for policyholder SSN 078-05-1120"
  }' | jq .
{
  "verdict": "deny",
  "decision_id": "b4e2c8d1-7f3a-4b2e-a6d4-3e8f9a1b2c3d",
  "trace_id": "2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e",
  "stage": "llm",
  "reasons": ["PII detected: SSN pattern"],
  "obligations": [],
  "evaluated_policies": ["sys_pii_ssn"],
  "expires_at": "2026-05-25T12:30:00Z"
}

4. Policyholder communication agent​

What the agent does: An AI agent drafts and sends communications to policyholders: renewal notices, coverage change confirmations, claim status updates, and responses to policyholder inquiries. It pulls policy details from internal systems via MCP connectors and uses an LLM to generate personalised messages.

What could go wrong: The agent includes the policyholder's SSN, date of birth, or payment card details in a generated message. Or it sends a coverage confirmation that contains inaccurate terms because there was no review gate on outbound communications. Or the agent's LLM prompt contains data from one policyholder that leaks into a message to another.

How AxonFlow can help:

  • PII detection scans every outbound message for SSNs (format-validated), credit card numbers (Luhn-validated), dates of birth, phone numbers, email addresses, and passport numbers. Action is configurable per data type and per path.
  • MCP connector governance applies three-phase policy evaluation to policyholder-data calls routed through the governed MCP path. Configured exfiltration policies can block disallowed transfers before the client proceeds. See MCP Policy Enforcement.
  • HITL approval gates can pause configured coverage-related communications for review. The messaging integration must enforce the approval result before sending.
  • Cost controls can limit spend on governed generation paths with configurable warn, block, and downgrade actions. See Cost Management.

Regulatory mapping​

The table below maps specific regulatory requirements to shipped AxonFlow capabilities. Each capability link points to the relevant documentation page.

RequirementRegulationAxonFlow CapabilityDocs
Model risk management and governance supportNAIC AI Model Bulletin (2023), where adoptedPolicy enforcement on integrated paths, governance profiles, and structured decision recordsCompliance Overview
Consumer protection in AI-assisted decisionsNAIC AI Model Bulletin (2023)require_approval action, HITL approval queue, 24h auto-expiry (Evaluation), configurable TTL (Enterprise)HITL Approval Gates
Documentation of automated decision-makingState insurance regulations (US)Multi-layer audit logging with decision_id, verdict, evaluated_policies, timestamp, identity; evidence export (Evaluation/Enterprise)Audit Logging, Evidence Export
Governance evidence for fairness reviewNAIC AI Model Bulletin (2023), where adoptedPolicy and approval records to complement separate statistical fairness and model-validation evidenceEvidence Export
Operational risk management for AI systemsSolvency IICircuit breaker with configurable failure thresholds, kill switch (Enterprise), cost controls with budget limitsChoosing a Mode, Cost Management
ICT risk management for AI third-party providersDORA (EU)Self-hosted and In-VPC deployment options for governed traffic and audit records, governance profiles, circuit breaker, audit loggingDeployment Mode Matrix
Human oversight for high-risk AIEU AI Act Art. 14HITL approval gates with API-driven approve/reject, structured approval recordsHITL Approval Gates
AI system transparency and explainabilityEU AI Act Art. 13-14Structured decision records with evaluated policies, verdict rationale, and W3C traceparent correlation across gateway layersDecision Mode
PII and sensitive data protectionNAIC, state regulations, GDPRPII detection (SSN format-validated, DOB, credit card Luhn-validated, email, phone, passport) with configurable actions: block / redact / warn / logPII Detection
SQL injection pattern controlsDORA-aligned ICT risk controlSQL injection scanning on configured input or MCP response paths with configurable actionSQL Injection Scanning

Reference architecture​

The diagram below shows AxonFlow in a typical insurance stack. The pattern applies whether your AI agents are internal tools, customer-facing copilots, or back-office automation.

In this reference pattern, model calls route through the Orchestrator and insurance data-source calls route through the MCP Gateway. Configured high-risk steps route to HITL. AxonFlow records policy decisions made on those integrated paths.

Decision Mode for insurance infrastructure teams​

Large carriers typically run multiple gateway layers: an agent gateway that routes agent traffic, an MCP or tool gateway that governs connector access, and an LLM gateway that manages provider calls. Asking these teams to rearchitect their traffic flow through a new proxy is not realistic.

Decision Mode solves this. AxonFlow runs as a standalone policy decision service. Each gateway makes one inline POST /api/v1/decide call per request, receives a verdict (allow, deny, or require_approval), and enforces it locally. AxonFlow is never on the traffic path -- it is consulted, not traversed. This is the PDP/PEP pattern (Policy Decision Point / Policy Enforcement Point) used across the industry by policy engines like OPA, XACML, and Cedar.

Each gateway passes a stage identifier (llm, tool, or agent) and a caller_identity with its gateway_id and tenant_id. AxonFlow evaluates the same policy hierarchy for all three and returns a verdict with a trace_id that correlates decisions across layers using W3C traceparent headers. One audit trail, one policy engine, enforcement at every layer, and zero changes to your existing gateway code beyond the HTTP call.

For the full API reference, request/response schemas, and curl examples, see Decision Mode. For guidance on when to use Decision Mode versus Gateway Mode, Proxy Mode, or Workflow Control Plane, see Choosing an Integration Mode.

Deployment options for insurance​

Insurance carriers have strict requirements around data residency, network isolation, and control over infrastructure -- particularly for systems that handle PHI or PII at scale. AxonFlow supports three deployment modes:

ModeDescriptionBest for
Self-HostedYou run AxonFlow on your own infrastructure. Source-available under BSL 1.1. Full control over data, network, and upgrades.Carriers with strict data-residency, air-gapped, or on-premises requirements
In-VPCAxonFlow runs inside your AWS VPC and uses your infrastructure controls. Governed traffic can stay within your VPC boundary when paired with in-boundary model and connector paths.Carriers that want managed operations without using shared SaaS
SaaSManaged by AxonFlow in us-east-1. Fastest path to production.Insurtechs and teams without data-residency constraints

All three modes support the same feature set. See Deployment Mode Matrix for the full comparison and Licensing for tier details.

Getting started​

Step 1: Run locally. Follow the Getting Started guide to run AxonFlow on your machine in under 5 minutes.

Step 2: Configure for insurance workflows. Enable PII detection for the data types relevant to your workflows (SSN, DOB, credit card, phone, email, passport). Set AXONFLOW_PROFILE=strict for enforcement. See PII Detection for configuration.

Step 3: Add HITL gates on consequential decisions. Configure require_approval policies on claims adjudication, underwriting recommendations, and fraud escalations. See HITL Approval Gates.

Step 4: Map your regulatory requirements. Use the compliance pages for your jurisdiction:

Step 5: Evaluate with real workloads. Request a free Evaluation License for self-hosted validation with HITL approval gates, evidence export, and higher limits. If a sponsored insurance workflow must reach scoped production against a dated control requirement, use the paid Production Program.

Assessment Path​

Use this page as a domain map, then validate the runtime with the same rollout path:

Last updated on