Use Cases/Insurance Agents

Authorize insurance workflows before policyholder impact.

Name: Veto
Availability: InStock
Author: Veto

Claims and underwriting agents can issue payments, send denials, request records, update submissions, bind coverage, and message carriers. Veto checks the exact tool call before it changes the claim, policy, or customer record.

What is runtime authorization for insurance AI agents?

Runtime authorization for insurance AI agents is a pre-execution policy check for claims payouts, denials, underwriting/pricing, coverage changes, SIU/fraud workflows, and medical-record access. Veto evaluates the tool, arguments, claim context, prohibited factors, and review thresholds, then allows, blocks, or requires human approval.

What claims, underwriting, and compliance leaders care about

Payout thresholds

Claims AI guardrails route large or unusual settlements to supervisors before payment, reserving, or coverage action.

No auto-denial

Adverse claims, coverage, or medical-necessity decisions can require licensed human review before the agent responds.

SIU and fraud escalation

Fraud-score thresholds can pause payment, preserve the claim file, and route to SIU instead of letting the model improvise.

Regulator evidence

NAIC, Colorado SB21-169, state regulator, and market-conduct reviews need the attempted action, policy, reviewer, and rationale.

Protect the first policyholder-impacting action.

Insurance buyers do not start by reviewing a philosophy of AI governance. They ask about the action that changes a claim, submission, policy, or policyholder communication. Put that call behind policy, approval, and a decision record first.

Claims and payouts

Amount, coverage limit, fraud score, authority level, and SIU route checked before payment or reserve change.

Denials and coverage

Adverse actions can wait for licensed review, rationale capture, and state-specific policy before the agent responds.

Submissions and records

Medical records, SSNs, loss runs, claim photos, carrier messages, and submissions checked before read or send.

Four scenarios, four policy sets

Each insurance workflow carries different risks and requires different guardrails. Veto policies map to the four most common insurance AI agent patterns.

1. Claims processing

Claims agents review submissions, assess damage estimates, and authorize payments. The primary risks are approving amounts beyond authority limits, missing fraud indicators, and paying on lapsed or excluded coverage. Guardrails enforce dollar thresholds, fraud score gates, and coverage validation before any payment is authorized.

Payment limitsCoverage validationFraud score gateHuman escalation

2. Underwriting and pricing

Underwriting agents assess risk profiles, calculate premiums, and issue quotes. The risks are quoting below minimum rates (creating actuarial losses), binding coverage outside appetite guidelines, and using prohibited rating factors. Guardrails enforce premium floors, coverage caps, and prohibited-factor blocking.

Premium floorsRisk class limitsFactor blockingSenior approval

3. Fraud detection and SIU

Fraud agents flag suspicious patterns, but cannot deny claims unilaterally. California SB 1120 and Florida HB 527 prohibit AI from being the sole decision-maker for adverse claim determinations. Guardrails enforce mandatory human review for any denial, ensuring due process and licensed-professional sign-off.

Mandatory reviewNo auto-denialSIU escalationDecision records

4. Policy issuance and servicing

Issuance agents generate contracts, bind coverage, and handle endorsements. The risks are issuing policies outside binding authority, missing required disclosures, and modifying coverage without proper authorization. Guardrails enforce authority limits, disclosure checklists, and signature requirements.

Authority limitsDisclosure checksEndorsement reviewSignature workflow

Claims authorization policies

These YAML policies cover the most common claims processing controls. They execute deterministically, the LLM's reasoning has no influence on whether a rule fires. Policies live in your repo and deploy through your existing CI/CD pipeline.

policies/claims.yaml

rules:
  # Tier 1: Auto-approve low-value claims
  - name: auto_approve_small_claims
    description: Allow claims under $5,000 with low fraud scores
    tool: approve_claim
    when: args.amount <= 5000 AND args.fraud_score < 0.3
    action: allow

  # Tier 2: Supervisor review for mid-range claims
  - name: mid_range_claims_review
    description: Require supervisor review for claims $5,000-$50,000
    tool: approve_claim
    when: args.amount > 5000 AND args.amount <= 50000
    action: require_approval
    message: "Claims $5K-$50K require supervisor review"
    approvers: ["claims-supervisor"]

  # Tier 3: Senior management for high-value claims
  - name: high_value_claims
    description: Route claims over $50,000 to claims director
    tool: approve_claim
    when: args.amount > 50000
    action: require_approval
    message: "Claims over $50K require claims director approval"
    approvers: ["claims-director"]

  # Hard block: payment exceeds policy coverage
  - name: block_overcoverage_payment
    description: Block payments that exceed policy limits
    tool: process_payment
    when: args.amount > args.policy_coverage_limit
    action: deny
    message: "Payment exceeds policy coverage limit"

  # Fraud gate: high fraud score triggers SIU
  - name: fraud_siu_escalation
    description: Route high-fraud-score claims to SIU
    tool: approve_claim
    when: args.fraud_score > 0.7
    action: require_approval
    message: "Fraud score {{args.fraud_score}} requires SIU review"
    approvers: ["siu-team"]

  # Regulatory: no automated denials
  - name: no_automated_denials
    description: AI cannot deny claims without human review
    tool: deny_claim
    action: require_approval
    message: "All claim denials require licensed adjuster review"
    approvers: ["licensed-adjuster"]

  # PII access logging for GLBA compliance
  - name: log_pii_access
    description: Log all customer data access
    tool: get_customer_data
    action: allow
    log: true
    log_fields: ["args.customer_id", "args.fields_requested", "context.agent_id"]

The tiered approval structure mirrors how most insurance companies already handle claims authority. The difference: it is enforced at the tool-call boundary, not by prompting the model to "check with a supervisor."

Underwriting authorization policies

Underwriting guardrails reduce below-guideline quote exposure, enforce risk appetite boundaries, and block the use of prohibited rating factors under state regulations.

policies/underwriting.yaml

rules:
  # Enforce minimum premium rates
  - name: premium_floor
    description: Block quotes below actuarial minimum
    tool: generate_quote
    when: args.premium < args.minimum_guideline_rate
    action: deny
    message: "Premium {{args.premium}} is below minimum guideline rate"

  # Large policy binding authority
  - name: large_policy_authority
    description: Senior underwriter approval for policies over $100K
    tool: bind_coverage
    when: args.annual_premium > 100000
    action: require_approval
    message: "Policies over $100K annual premium require senior approval"
    approvers: ["senior-underwriter"]

  # Risk appetite enforcement
  - name: risk_appetite_check
    description: Block binding outside risk appetite
    tool: bind_coverage
    when: args.risk_class NOT IN ["preferred", "standard", "substandard"]
    action: deny
    message: "Risk class '{{args.risk_class}}' outside appetite guidelines"

  # Prohibited factor blocking (Colorado SB21-169)
  - name: prohibited_rating_factors
    description: Block use of prohibited factors in pricing
    tool: calculate_rate
    when: args.factors_used CONTAINS_ANY ["race", "national_origin", "religion", "genetic_information"]
    action: deny
    message: "Prohibited rating factor detected in pricing model"
    log: true

Regulatory evidence mapping

Insurance AI regulations are fragmented across state lines. Veto policies map to the specific requirements your review team cares about.

NAIC Model Bulletin

Used as the state template for insurer AI governance. Requires a formal AI Systems (AIS) Program with documented policies, an oversight committee, risk management processes, and internal audit schedules.

Veto policies serve as documented AI governance controls

Decision records provide regulatory review documentation

Human review workflows create oversight evidence

Colorado SB21-169

Requires insurers to document controls for unfair discrimination risk. Annual CRO attestation and disparate-impact testing make the evidence record matter.

Prohibited-factor policy blocks configured discriminatory inputs

Audit logs support disparate impact analysis and testing

Policy version history provides attestation documentation

NY DFS Circular Letter No. 7

Requires insurers to maintain documentation explaining AI model functionality, input data, assumptions, and how outputs influence decisions. Explainability mandate.

YAML policies are human-readable decision documentation

Decision records capture decision context: inputs, policy matched, outcome

Git-tracked policies provide change history for auditors

Adverse decision laws

California SB 1120, Florida HB 527, and Arizona HB 2175 prohibit AI from being the sole decision-maker for claim denials. Require licensed professional review.

Deny-claim tool routes to human approval by policy

Approver routing can target licensed adjusters by state

Decision record captures both AI recommendation and human final decision

Integration with claims management systems

Veto wraps your existing tool implementations. Your Guidewire API calls, Duck Creek integrations, and document-management operations stay outside the policy surface. The SDK intercepts at the tool boundary. It does not replace your claims system or require data migration.

claims_agent.ts

import { Veto } from "veto-sdk";

const veto = new Veto({ apiKey: process.env.VETO_API_KEY });

// Your existing claims tools, existing dispatch point
const claimsTools = {
  approve_claim: async (args: {
    claimId: string;
    amount: number;
    fraud_score: number;
    policy_coverage_limit: number;
  }) => {
    // Your existing Guidewire or Duck Creek API call
    return await claimsSystem.approveClaim(args);
  },

  deny_claim: async (args: {
    claimId: string;
    reason: string;
    automated: boolean;
  }) => {
    return await claimsSystem.denyClaim(args);
  },

  get_customer_data: async (args: {
    customer_id: string;
    fields_requested: string[];
  }) => {
    return await customerDB.getFields(args);
  },
};

// Wrap each tool with Veto
const protectedTools = veto.wrapTools(claimsTools, {
  policy: "claims",
  context: { agent_id: "claims-processor-v2" },
});

// Use protectedTools in your agent framework
// LangChain, OpenAI, Anthropic, CrewAI

The authorization check adds local decision-path overhead. Policy evaluation happens locally in your process when using the SDK. Approval routing goes through Veto's cloud or your self-hosted instance.

Frequently asked questions

How is this different from prompt engineering or system prompts?

System prompts are suggestions. Veto policies are enforcement. A system prompt that says "do not approve claims over $50,000 without supervisor review" can be overridden by prompt injection, ignored through reasoning errors, or lost during long conversations. A Veto policy evaluates the actual tool call arguments deterministically, if the dollar amount exceeds $50,000, the call is routed to approval based on policy, not model belief.

Can guardrails block governed use of prohibited rating factors?

Guardrails can block prohibited rating factors from being used in pricing calculations and route non-standard risk assessments for human review. They cannot detect all forms of proxy discrimination or bias embedded in training data. Veto policies are one layer of a fairness program: they complement disparate impact testing, bias monitoring, and actuarial review, but do not replace them.

What happens when a claim is routed for approval?

The tool call is paused. The designated approver receives a notification through the configured approval channel or Veto workspace) containing decision context: tool name, arguments, the policy rule that triggered review, and any additional context your agent provides. The approver can approve, deny, or modify the request. The agent waits for the response before continuing. The entire interaction is recorded as a decision record.

Does this work with our existing claims management system?

Yes. Veto wraps your existing tool definitions, the functions that call Guidewire, Duck Creek, your document management system, or any other API. Your underlying systems, data models, and workflows can remain intact. The SDK adds an authorization check at the tool boundary. If the check passes, your original function executes normally.

How do we support a NAIC audit request?

Each governed tool call decision can be recorded with timestamp, tool name, arguments, policy rule matched, outcome (allow, deny, or require_approval), and approver identity for human-reviewed decisions. These records can be exported for regulatory filings. The YAML policies themselves serve as documented AI governance controls. They are version-controlled, reviewed in pull requests, and show a clear history of what rules were in effect at any point in time.

Is the SDK open source?

Yes. The TypeScript SDK and CLI are Apache-2.0 licensed. Python is available as a preview package for local tool-call checks. The policy engine runs locally in your process. You can self-host the core policy engine and approval path when your deployment requires it. The managed cloud adds the workspace, team management, approval UI, and decision-record retention, but the core authorization logic is yours to inspect and modify.

Financial Agents

Payment controls, trading guardrails, and wire-transfer approval patterns

Healthcare Agents

PHI access control and clinical human oversight for health-adjacent claims workflows

EU AI Act

Article 14 human oversight and Article 12 logs for insurance AI deployers

Install the SDK

Wrap claims, underwriting, and policy-servicing tools with Veto

Insurance AI that operates within bounds.