Incident Report: Insurance Chatbot Exposed 80,000 Customer Records

Incident Classification: Confirmed | Severity: High | Sector: Insurance / Financial Services | Date Confirmed: May 2026

A UK-based insurance provider has notified the ICO and approximately 80,000 affected customers following the discovery that its AI customer service chatbot could be manipulated to retrieve policy documents and personal data belonging to other customers. The vulnerability was exploited for at least three weeks before detection.

Incident Summary

Field	Detail
Incident type	Insecure direct object reference (IDOR) + AI tool over-permission
Affected system	Customer-facing AI chatbot with policy management tool access
Data at risk	Policy documents, personal details, claims history, financial information
Estimated customers affected	~80,000
Duration	Approximately 3 weeks
Detection method	Anomalous API query patterns flagged by backend monitoring
Notified to	ICO, FCA, affected customers

Timeline

Month −2: The insurer deploys an AI chatbot to handle customer enquiries, integrated with an internal API allowing the bot to retrieve policy documents, coverage details, and claims status. The chatbot authenticates users via a knowledge-based verification step (date of birth, postcode).

Week 0: An attacker discovers that the chatbot’s document retrieval tool accepts a policy_id parameter that is sequential and predictable. Because the underlying API does not validate that the requesting user is the policy holder, providing a different policy_id returns that customer’s documents.

Weeks 1–3: The attacker systematically iterates through policy IDs, using the chatbot’s natural language interface to retrieve documents. Because requests are routed through the AI layer, they appear as legitimate customer enquiries in application logs.

Representative prompts used by the attacker (reconstructed):

• “Can you show me my policy documents for policy [ID]?"
• "What is the claims history on policy number [ID]?"
• "Please confirm the personal details on file for policy [ID]“

Week 3: The backend API monitoring system flags an unusually high number of distinct policy document requests originating from a single authenticated session. The security team investigates and identifies the pattern within 48 hours.

Root Cause Analysis

Root Cause 1: IDOR in Underlying API

The policy document retrieval API was designed for internal use only and did not implement per-request authorisation checks. It assumed that any caller with a valid authentication token was entitled to retrieve any policy. When exposed via the AI chatbot tool, this assumption was violated: the chatbot’s service account held a valid token but acted on behalf of individual customers.

This is a well-established vulnerability class (OWASP API Security Top 10: API1 Broken Object Level Authorisation) that predates the AI layer — the API was inherited from a legacy system.

Root Cause 2: Chatbot Tool Granted Excessive Access

The chatbot’s tool configuration used a single service account with read access to all policies, rather than scoping API calls to the authenticated customer’s own records. The correct architecture would pass the authenticated customer’s identifier as a mandatory filter parameter on every retrieval call.

Root Cause 3: Predictable Policy IDs

Policy IDs were sequential integers, making enumeration trivial once the IDOR was discovered. Opaque, non-guessable identifiers (UUIDs, HMACs) would not have prevented the IDOR but would have significantly reduced the scale of exploitation.

Root Cause 4: Weak AI-Layer Guardrails

The chatbot had no context-aware guardrail to detect that a user was requesting documents for a policy that did not match their authenticated identity. A simple check comparing the policy holder’s registered details against the authenticated user’s details would have blocked cross-customer retrieval.

Impact

Data accessed by the attacker included:

• Full name, date of birth, address for ~80,000 policyholders
• Policy coverage details and premium amounts
• Claims history including incident descriptions
• Bank account details where direct debit mandates were on file

The FCA has flagged potential violations of Consumer Duty (the obligation to deliver good outcomes for retail customers) in addition to GDPR implications.

Remediation Actions

1. Chatbot taken offline immediately on detection
2. API authorisation patching — all policy retrieval endpoints updated to validate that the requesting identity matches the policy holder record
3. Tool permission redesign — chatbot now passes authenticated customer ID as a mandatory, non-overridable parameter; service account access scoped accordingly
4. Policy ID migration — sequential IDs replaced with non-guessable UUIDs across affected systems
5. Pre-launch API security testing — mandatory OWASP API Top 10 assessment added to AI tool integration review process
6. Enhanced monitoring — anomaly detection added to flag high-volume or cross-customer API access patterns

Recommendations for Organisations Deploying AI with API Tool Access

1. Never inherit legacy API trust models — APIs designed for internal use are not safe to expose through AI tools without an authorisation review. Assume the AI can be prompted to make any call the API supports.
2. Scope tool calls to the authenticated user — every data retrieval tool should enforce that the response is filtered to data the authenticated user owns. The AI layer is not a substitute for API-layer authorisation.
3. Test AI tools with OWASP API Top 10 — IDOR, broken authentication, and excessive data exposure are as relevant to AI-integrated APIs as to any other API consumer.
4. Use non-guessable identifiers — opaque IDs reduce the impact of any IDOR that does exist.