AI Agents in Insurance Guide: Securing Claims, Underwriting and Service Agents

Insurers are giving AI agents real authority over claims, quotes and policy changes, and every one of those agents reads documents, photos and messages that a fraudster or an attacker can write. A claims agent that triages first notice of loss, requests documents and proposes reserves sits on the same path that organised claims fraud already targets, while an underwriting agent that pulls external data into pricing decisions brings insurance regulators' discrimination and transparency rules into scope. This guide covers what changes when agents do insurance work: where they sit in the policy life cycle, the threats that are specific to them, how to scope their identities and authority, what US, EU and UK supervisors expect, and how to roll out and monitor them. It is written for insurance CISOs, claims and underwriting technology owners, model risk and compliance teams. The broader security programme for carriers is covered in the Insurance Sector Cybersecurity Programme Guide; this page goes deeper on agents only.

Source note: legal and regulatory points on this page summarise the cited official texts and secondary analyses, with status checked on 11 November 2026. Confirm against the official text before relying on it.

Key takeaways

• Claims evidence is untrusted input. Photos, invoices, repair estimates, medical reports and claimant emails can all carry manipulated content or hidden instructions, so an agent's permissions, not its judgement, must cap the loss from one bad file.
• Agents recommend, authorised people and systems decide. Payment release, claim denial, policy cancellation and adverse underwriting decisions stay with people or with rules enforced in the core platform, not in the prompt.
• Regulators treat agents as AI systems under existing rules. The NAIC Model Bulletin, NYDFS Circular Letter No. 7 (2024), Colorado Regulation 10-1-1 and the EU AI Act all reach agents that influence underwriting, pricing or claims outcomes.
• Each agent needs its own identity and authority limits. Separate identities per agent role, short-lived credentials into policy admin and claims systems, and value limits set in the claims platform make agent actions attributable and bounded.
• Evidence is a product requirement. Inventories, decision logs, the inputs an agent saw and bias testing results are what an examiner asks for, so build them before go-live.

Where agents sit in the insurance life cycle

The risk of an insurance agent depends less on the model than on what it is allowed to change and whose outcome it affects. The table maps typical deployments in 2026 to the failure that matters most.

The EU AI Act lists AI systems intended for risk assessment and pricing of natural persons in life and health insurance as high-risk (Annex III, point 5(c)). An agent that performs or materially shapes that work in the EU is inside the high-risk regime, whatever the vendor calls it. See the EU AI Act High-Risk AI Systems Guide.

Threats specific to insurance agents

• Manipulated claims evidence: edited photos, fabricated invoices and altered medical documents are long-standing fraud tools. An agent that reads them can be convinced at scale, and generative tools make the fakes cheaper. The Insurance Fraud Detection Guide covers the fraud typologies; the agent-specific point is that evidence checks must happen in tools outside the model.
• Indirect prompt injection in documents: text hidden in an estimate, a PDF or an email can tell a claims agent to raise a reserve, skip a document check or mark a claim as verified. OWASP LLM01:2025 Prompt Injection covers injection through external content, and MITRE ATLAS tracks it as AML.T0051.001 LLM Prompt Injection: Indirect. Images matter too; see the Multimodal Prompt Injection Guide.
• Excessive agency: OWASP LLM06:2025 Excessive Agency describes agents given more functions, permissions or autonomy than the task needs. A FNOL agent that can also approve payments, or a servicing agent that can change payee bank details, turns one manipulated conversation into a loss (ATT&CK T1657 Financial Theft).
• Policyholder account takeover through the agent: a conversational servicing agent that changes contact details or resends documents becomes a social engineering target. The Meta AI Instagram account takeover, where an AI support assistant sent recovery links to attackers, is the pattern to design against.
• Sensitive data disclosure: claims and underwriting files hold health, financial and identity data. OWASP LLM02:2025 Sensitive Information Disclosure applies when an agent can retrieve another claimant's file or echo underwriting notes to a customer. Exfiltration through tool calls is tracked as ATLAS AML.T0086 Exfiltration via AI Agent Tool Invocation.
• Partner and vendor credentials: brokers, TPAs, repair networks and data vendors connect through portals and APIs. The Scania insurance portal breach, where an IT partner's infostealer-stolen login exposed claim documents, shows how partner credentials reach claims data; agent tokens on the same integrations carry the same risk (ATT&CK T1528 Steal Application Access Token).
• Silent unfairness: no attacker is needed for an underwriting or claims agent to produce disproportionate adverse outcomes for a protected group. That is a regulatory failure in its own right.

What insurance supervisors expect

Insurance regulators have mostly applied existing law to AI rather than writing agent-specific rules, so the obligations below reach agents through their effect on consumer outcomes. Status as checked in November 2026; individual states adopt the NAIC bulletin in their own form.

Data security rules apply as well. Where a state has adopted the NAIC Insurance Data Security Model Law, agent credentials, logs and the data they reach fall inside the information security programme and its third-party service provider oversight.

Scoping agent identity and authority

OWASP's Excessive Agency mitigations translate directly: limit the tools offered to the agent, limit what each tool can do, enforce permissions at the identity the tool uses in the downstream system, and require human approval for high-impact actions. In an insurer that means role-based agent identities with limits in the core systems.

• One identity per agent role: do not share an integration user across agents, and do not let an agent act through an adjuster's or underwriter's session where its actions would look like the person's. See the Agent Identity and Access Guide.
• Authority limits outside the model: claim value limits, reserve ceilings and payee rules configured in the claims and payments systems. A limit stated in a prompt is guidance, not a control. See the AI Agent Action Approvals and Spending Limits Guide.
• Customer-bound access: a servicing agent should only reach the records of the policyholder authenticated in that session, enforced by the API, not by instructions.
• Payee and bank detail changes: agents may flag them, never commit them; a person verifies through a channel held on file and a second person approves, as in the Invoice Redirection and Supplier Bank Detail Fraud Guide.
• Partner-facing agents: brokers' and TPAs' agents should authenticate as their own organisation with scoped, short-lived tokens, never with a shared broker login. See the Insurance Sector Identity Security Guide.

Human oversight and adverse decisions

The decision rights matter more than the model. Decide which outcomes an agent may complete alone and which it may only prepare.

Human review only works if reviewers see what the agent saw: the original documents, the extracted fields, the data sources used and the agent's stated reasons. NYDFS expects adverse underwriting notices to name the data relied on, so record sources at the moment of the decision. The EU AI Act Article 14 Guide covers oversight design for high-risk systems, and the Explainable and Fair AI Guide covers explanation and fairness testing methods.

Implementation: a phased rollout

1. Inventory: list every agent and AI feature across distribution, underwriting, claims and servicing, including features switched on inside core insurance and CRM platforms, with owner, identity, permissions, data sources and the decisions it touches. This doubles as the AIS inventory regulators ask for.
2. Classify by consumer impact: use the life cycle table above; anything that affects pricing, eligibility, claim payment or cancellation is high impact and gets bias testing and model validation.
3. Shadow mode: run the agent alongside adjusters or underwriters for a defined period and compare outcomes, override rates and error types, including by consumer segment where lawful testing data is available.
4. Prepare-only go-live: the agent drafts and proposes; people approve every consequential action.
5. Narrow straight-through processing: allow automatic completion only for low-value, low-risk cases with limits in the platform, and sample them.
6. Vendor diligence: for vendor agents and data sources, obtain testing evidence, audit rights and cooperation with regulators in the contract, as the NAIC bulletin and NYDFS letter expect. See the AI Contract Clauses Guide.
7. Rollback: keep the manual workflow staffed and documented, with a switch that returns the agent to prepare-only or off within minutes, and test it before go-live. See the AI kill switch definition.

Decision guidance

• Personal lines versus commercial: personal lines carry the heaviest consumer protection and discrimination rules, so straight-through processing should start there only for servicing and simple claims, not for pricing.
• Build versus vendor: vendor agents do not move responsibility; NYDFS states the insurer remains responsible for outcomes. Choose vendors that provide testing data and logs you can examine.
• Small carriers and MGAs: keep scope narrow (FNOL intake, document chasing), rely on platform-enforced limits, and use the core system's audit trail rather than building new tooling.

Detection and measurement

• Log every agent action with agent identity, claim or policy number, tool called, inputs referenced and outcome (NIST SP 800-53 AU-2 and AU-6), and keep the source documents with the decision record.
• Watch for drift and manipulation: sudden changes in an agent's tool use, reserve levels, approval rates or payee changes; claims with high document similarity across claimants; injected-text patterns found by document scanning.
• Monitor partner and agent tokens for use from new locations, unusual volumes or out-of-hours bulk reads.

Metrics that show the programme is working:

1. Adjuster or underwriter override rate of agent proposals, by agent and by segment.
2. Share of high-impact agents with current bias testing and validation on file.
3. Payments or payee changes completed without the required human approval (target zero).
4. Claims leakage and fraud referral hit rate before and after agent deployment.
5. Mean time to move an agent to prepare-only or off when an incident is declared.
6. Complaints and adverse decision appeals linked to agent-handled cases.

Framework mapping

Common failure patterns

• Payment authority in the prompt: the agent is told not to pay above a threshold, but its claims platform role can, so one injected instruction or model error pays out.
• One integration user for every agent: nobody can tell which agent changed a reserve, and revoking one agent stops them all.
• Vendor opacity accepted: the vendor will not share testing or reasons, leaving the insurer unable to explain adverse decisions or answer an examiner.
• Bias testing at launch only: no retest after the model, prompt or data source changes, which NYDFS expects after material change.
• Servicing agent without customer binding: the agent can look up any policy if asked the right way, turning a chatbot into a data disclosure channel; the DPD chatbot incident shows how easily customers steer a public bot off its rules.
• Partner logins shared across brokers: stolen or reused credentials give access to many policyholders, as the Scania portal breach showed.

Practitioner checklist

• Maintain an inventory of every insurance agent with owner, identity, permissions, data sources and decisions affected.
• Give each agent role its own identity with short-lived credentials and platform-enforced authority limits.
• Keep claim denial, adverse underwriting decisions, cancellation and payment release with authorised people.
• Bind servicing agents to the authenticated policyholder's records at the API.
• Scan and validate claims evidence outside the model and keep originals with the decision record.
• Test high-impact agents for unfair discrimination before production, regularly and after material change.
• Put audit rights, testing evidence and regulator cooperation into vendor contracts.
• Log agent actions with inputs and sources, and review override and payee change metrics monthly.
• Test a switch that returns each agent to prepare-only or off.

Standards and references

• NAIC: Model Bulletin on the Use of Artificial Intelligence Systems by Insurers
• NYDFS: Insurance Circular Letter No. 7 (2024), Use of AI Systems in Insurance Underwriting
• Colorado Division of Insurance: SB21-169, Protecting Consumers from Unfair Discrimination in Insurance Practices
• EU AI Act: Annex III, High-Risk AI Systems
• EIOPA: Opinion on Artificial Intelligence Governance and Risk Management
• FCA: Our approach to AI
• OWASP: Top 10 for LLM Applications 2025 (LLM01, LLM02, LLM06)
• MITRE ATLAS: LLM Prompt Injection: Indirect

Related NHI Mgmt Group resources: Insurance Sector Cybersecurity Programme Guide · Insurance Fraud Detection Guide · AI Agents in Financial Services Security Guide · AI Agents in Finance Operations · AI Model Risk Management Guide