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 (2023) established expectations for model risk management, consumer protection, and fairness documentation that multiple state departments of insurance have already adopted or are actively incorporating. In the EU, Solvency II now explicitly includes operational risk from AI systems in its risk management framework, and DORA (Digital Operational Resilience Act) imposes ICT risk management obligations on insurers as financial entities -- including third-party AI providers.

These frameworks converge on four demands:

  1. Auditability. Every AI-assisted decision that affects a policyholder -- a claim adjudication, a premium calculation, a coverage recommendation -- must produce a traceable record. Not a log line, but a structured audit record with decision identity, the policies that were evaluated, the verdict, and a timestamp that survives regulatory examination.
  2. Human oversight on consequential decisions. No regulator accepts an unsupervised AI agent denying a claim, declining coverage, or setting a premium. The expectation is a deterministic gate: consequential decisions pause for human review before they execute.
  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 documentation. The NAIC bulletin and state-level regulations require insurers to document how AI models are tested for unfair discrimination. Governance controls that produce structured evidence of policy enforcement, decision rationale, and human review are the foundation of that documentation.

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 prevents it:

  • 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 produces a complete decision chain across every step: document extraction, policy lookup, LLM calls, and the final adjudication recommendation. Each record includes decision_id, verdict, evaluated_policies, timestamp, and identity. 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 prevents it:

  • PII detection identifies SSNs (format-validated), dates of birth, phone numbers, email addresses, and credit card numbers (Luhn-validated) in every governed interaction. See PII Detection.
  • MCP connector governance applies three-phase policy evaluation on every connector call: request-phase (before the call), response-phase (on the returned data), and exfiltration-phase (if data flows to another tool).
  • HITL gates on the coverage recommendation step ensure an underwriter signs off before the quote is issued. The approval queue API integrates with existing underwriting workbenches.
  • 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 prevents it:

  • 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 on all queries prevents prompt-injection attacks that attempt to extract or modify claims data. See SQL Injection Scanning.
  • HITL approval on the SIU escalation step ensures no claim is flagged as fraudulent without human review. This protects policyholders from false positives and provides the documentation trail regulators expect.
  • Circuit breaker and kill switch (Enterprise) provide deterministic fallback when LLM providers are unavailable, ensuring the fraud monitoring pipeline fails loud rather than fails silent. 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 prevents it:

  • 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 on every connector call that retrieves policyholder data, preventing cross-policyholder data leakage at the exfiltration phase. See MCP Policy Enforcement.
  • HITL approval gates on coverage-related communications ensure no outbound message with coverage terms, claim decisions, or financial amounts leaves the system without human sign-off.
  • Cost controls prevent runaway generation loops (e.g., an agent stuck in a retry loop generating thousands of messages) from consuming LLM budget. Budget limits are configurable per tenant with 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 governanceNAIC AI Model Bulletin (2023)Policy enforcement at every governed boundary, governance profiles (AXONFLOW_PROFILE=strict), 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 documentation for fairness reviewNAIC AI Model Bulletin (2023), state regulationsStructured audit trail proving governance was active at time of decision, evidence export packages for regulatory examinationEvidence 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 (no data leaves your network), 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
Prompt injection preventionDORA ICT risk, operational resilienceSQL injection scanning on all queries 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.

Every interaction between an agent and an LLM provider passes through the Orchestrator, where policies are evaluated and PII detection runs. Every interaction between an agent and an insurance data source passes through the MCP Gateway, where three-phase policy evaluation (request, response, exfiltration) applies. High-risk steps route to the HITL queue. All decisions produce structured audit records.

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. No data leaves your network boundary. Managed by AxonFlow with your infrastructure controls.Carriers that want managed operations without data leaving their VPC
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 you need enterprise features, direct rollout support, or managed SaaS, apply for the Design Partner Program.

Last updated on