Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Is It Safe to Let an AI Agent Work Insurance Claims?
No, not while the agent reads the adjuster's screen: a claim file carries the claimant's identity, medical reports and bank account, and the model receives all of it beside the loss facts it needs. Require consistent tokens on the rendered claim, a named adjuster's approval of the payment, and a record of what the model received.
An insurance claim is a stack of records written for a person to read: a loss report, a policy, medical reports, an estimate, a reserve and a payment instruction. The adjuster opens them in the carrier's claims system, reads the loss against the coverage, sets the reserve and releases the payment. An agent that takes the work reads the same screens, and the model receives everything those screens draw.
The screen draws more than the loss. The claimant's name, date of birth, medical detail and bank account sit beside the date of loss and the repair estimate, so a model asked to summarize the damage also holds details it was never asked about. The claim file is the most complete personal record a carrier holds.
The work suits an agent: facts of loss, coverage and reserve arithmetic across a claims system, an estimating tool and a payment queue. What decides the answer is what the model receives when it opens the claim, who releases the payment, and what record survives. The record type used throughout is a property claim worked on placeholders, with a date of loss, a coverage position, an estimate, a reserve and a payment to the claimant.
Key findings
- For an agent to work a claim safely, the values on the claims screen would have to be replaced with consistent tokens such as CLM_0912 before the model reads it, so the run works from the claim number while the claimant's name, medical detail and bank account stay out of its context (Can an AI Agent Work Guidewire Claims Without PII?).
- It would also require a named person, the adjuster who owns the file, approving each payment, and a record of the screen the model received, because an approval the model can decline to request is not a gate (Who Approves an AI Agent's Claim Payment?).
- The pages reviewed describe the claim screen, the settlement options and the audit trail; none of them states that a value is replaced before a model reads it, or names who releases a payment (Guidewire, 2026; Duck Creek Technologies, 2026).
- A study of autonomous web agents finds they "are prone to inadvertent use of unnecessary sensitive information," the failure a claims screen invites because the whole record arrives at once (Zharmagambetov et al., 2025).
- Duck Creek's claims sheet lists "Multiple settlement options, automated recovery, and integrated payments for faster closure" and "full auditability, so automation is safe, explainable, and governed," with no authority limit or approver named (Duck Creek Technologies, 2026).
- Guidewire's Qusar release says the Agentic Framework gives AI agents "secure, real-time access to policy, claims, and billing data and workflows" and names Claim Summarization and Agentic FNOL, while saying nothing about human approval (Guidewire, 2026).
What does an agent read when it opens a claim?
The record is a property claim: a first-party loss with a date, a coverage position, an estimate, a reserve and a payment to the claimant. The claims system draws the file on one or two screens because the adjuster has to see the loss, the policy and the payment together.
In its 2019 ConnectCenter guide, Change Healthcare shows what a claims portal puts on its screens. Claims "are either keyed into ConnectCenter using the 1500 and UB-04 claim forms or submitted into the system by using the claim upload functionality," and the Claim Summary page shows "the patient associated to the claim" (Change Healthcare, 2019). A model that opens the summary to read the loss also reads the patient.
OWASP records that "Personal identifiable information (PII) may be disclosed during interactions with the LLM," the exposure a claim screen creates as its fields enter a context (OWASP, LLM02, 2025).
Every control a security team owns finishes its work before the page is painted: the proxy, the data loss prevention agent, the identity provider and the network policy (What Is Render-Layer Tokenization?). The agent reads the painted page, so the claim reaches the model in full even when the path to it is governed. A record that carries a name, a medical detail and an account number into a model's context is what the PII wall is meant to stop (What Is the PII Wall?). Claims vendors sit outside the 15 AI agents a review of agent pages counted, and not one of those 15 describes a working page where the claim data is replaced with tokens the agent can work with (Do AI Agents Ask Before Making a Payment?).
What changes when the claim screen renders with placeholders?
A placeholder is not a redaction after the fact; it is the value the page is drawn with. The screen renders the claim as CLM_0912 and the account as ACCT_014, the model works on the loss, the coverage and the reserve, and the real values resolve at the payment the adjuster releases. Token consistency lets the agent match the claim across the claims system, the estimating tool and the payment queue without holding the identity.
The steps themselves are routine enough to move onto a tokenized screen: Jim Sinkoff, Deputy CEO and CFO, Sun River Health, said on a HAL podcast that "if you're billing a medical claim, it's very routinely routinized" (Who Owns the Data When AI Touches Patient Records? A Health System CFO on AI Governance).
Most of the file survives substitution. A date of loss, a coverage limit, a deductible, an estimate and a reserve are the facts the adjuster reasons with, and none identifies the claimant. The name, the date of birth, the medical reports and the bank account travel as tokens, so a draft still prices the claim.
What substitution changes is the value of a successful attack. A model that holds CLAIMANT_003 cannot be persuaded to send a bank account it never received. The claim still moves through the same screens and the adjuster still reads the real file; the difference is what the model was shown.
A claim spanning two systems makes consistency concrete. The token on the claims screen has to be the same token in the industry database result and on the payment page, or the agent cannot tell whether it is looking at one claim or two (Can an AI Agent Work in Duck Creek Without PII?).
What do the vendors themselves say?
The vendor pages reviewed come from claims platforms and a claims clearinghouse. They describe the screens a claim passes through, the payment options a carrier can turn on, and the audit trail the platform keeps. None describes a step that replaces the values on a rendered claim before an agent's model reads it.
Guidewire's Qusar release advertises the Agentic Framework and names Claim Summarization and Agentic FNOL among the agents an insurer can build. It also marks availability: "Certain release features may not be available in all regions," and some features are "available for Early Access customers only" (Guidewire, 2026). The release describes what an agent can reach and which customers can turn it on.
Duck Creek's claims sheet lists "embedded controls to reduce manual effort, errors, and leakage across the lifecycle" and "Open REST APIs, pre-built vendor integrations, and valuation services for straight-through processing" (Duck Creek Technologies, 2026). Controls over manual effort and leakage govern the process, and the sheet describes no authority limit and no approver.
| Dimension | What the documentation states | What a buyer should verify |
|---|---|---|
| What the claim screen shows | Change Healthcare's summary shows "the patient associated to the claim" | Whether the agent needs the identity or a token |
| Access to claims data | Guidewire gives agents "secure, real-time access to policy, claims, and billing data" | Which fields the model receives |
| Audit trail | Duck Creek says decisions are "backed by full auditability" | Whether the record shows what the model read |
| Approval of an agent's action | No page reviewed names the approver | A written rule naming the person and the limit |
Who approves a claim payment the agent prepared?
An approval is a decision by a person who can see the file and the coverage, taken before the payment leaves. In a property claim the adjuster owns that decision: the coverage position, the reserve and the amount are the adjuster's judgment, and the carrier's written process says so in words the platform does not enforce.
A platform can make approval the default and leave a switch beside it. The AI Agent Index entry for Breeze Agents records that "The default is that approval is required," though users can switch that off, and automatically triggered agents then run without approval (AI Agent Index, 2026). The switch is available to whoever administers the account.
OWASP names the risk an approval answers. Its excessive agency entry describes "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM," with excessive permissions and autonomy among the root causes (OWASP, LLM06, 2025). A claim payment fits: it moves money on the strength of a record a model read.
The approval that changes the answer is outside the model's context, so a manipulated page cannot supply it. It names the adjuster, the claim and the amount before the payment is released, and a confirmation dialog inside the run is no substitute, because it asks the model to click.
What record does a claim run leave?
The record a carrier needs answers three questions: what the model received, what the agent did, and who approved it. A platform's audit trail answers the second well, because it logs the transaction against the account that submitted it. The first and the third are what an examiner asks for when a claimant disputes a payment.
An agent that signs in under an adjuster's login leaves the platform's log crediting the adjuster. That records the account and not the actor, and it says nothing about which screens the model read before the payment was prepared. A carrier that cannot separate the agent's reading from the adjuster's own would have trouble showing either.
A control record holds the page the model was shown, with tokens where the values were, the action the agent took, and the name of the approver, and it exports to the carrier's own monitoring (What Is an AI Control Record?). That is the difference between a log of transactions and a record of a decision.
A log that credits a shared login is not that record, because it names no screen and no approver. DAPLab makes the same point from the other side: "AI agents fail across the entire stack," and "human oversight breaks under scale," so the record is what lets a person check a run after the fact (DAPLab, 2026).
What does a governed environment change?
A governed environment acts where the page is drawn, before any model reads it. Values chosen by policy are replaced with consistent tokens, so the agent works with CLM_0912 and ACCT_014, and the claimant's name, medical reports and bank details stay out of its context. Real values resolve only at an approved destination, at the moment of an approved action. A named person approves each payment, and every screen, action and approval goes to a record that exports to the organization's monitoring.
For a claim, the change is specific. The agent still reads the date of loss, the coverage, the estimate and the reserve, because it needs them to do the work. The real account resolves when the adjuster releases the payment the agent prepared.
The control class does not belong to the claims platform. A platform can require a confirmation, keep an audit trail and restrict a user's authority, and none changes what the model receives when the claim renders. Substitution at the render layer does, before the model reads the screen (What Is Supervised Delegation?).
A carrier running several claims tasks needs the policy per task. Gartner expects that "by 2027, 40% of enterprises will demote or decommission autonomous AI agents," and warns that applying the same controls indiscriminately produces two common failure modes (Gartner, 2026).
What the record shows
Claim work sits at the point where a rendered page decides what a model knows, and the page a claims system draws carries the claimant's identity and bank account beside the loss. The pages reviewed describe the screens, the settlement options and the audit trail, and none describes a substitution before the model reads or names the person who releases a payment. So the answer is no for the run as it usually happens, and the conditions are specific. A carrier can check its own setup before the next claim: open one claim as the agent opens it, list every field the page draws, and compare it with the fields the session recorded. Where they match, the run needs tokens on the screen, a named adjuster on the payment and a record of what the model received. A claims leader should run that comparison as a test before an agent works a live claim.
Methodology and limitations
This page rests on vendor documentation from three claims vendors, an AI Agent Index entry, two OWASP entries, a Columbia DAPLab paper and a Gartner press release. The vendor pages were read as of October 22, 2026, and each Sources line carries the date for its page. Public documentation read in full gives a sound view of where each product applies its control.
The products on this page are described from documentation, and none was tested for this page. "Not described" means the pages reviewed, and the page carries its date; features change. The example describes a record type, a property claim worked on placeholders, not an organization. Statements about RedactSure describe its environment from its documentation, and RedactSure is deploying now with enterprise and government customers. Determinations belong to counsel, assessors and the organization's own security and compliance officers, and nothing here replaces a pilot on the carrier's own screens.
Frequently asked questions
Is it safe to let an AI agent work insurance claims?
No, not while the agent reads the live claim screen. A claim file carries the claimant's name, date of birth, medical reports and bank account alongside the loss facts, and a model that opens the screen receives all of it. An agent can work the loss, coverage and reserve arithmetic from tokens, and the payment can wait for the adjuster who owns the file. What makes the work defensible is that substitution, the named approval and the record.
What does the model receive when it opens a claim?
The rendered page, not the fields the task names. That includes the claimant's identity, the medical reports, the policy terms, the repair estimate, the reserve and the payment instruction with the bank account. A model reading them can summarize the loss, price a reserve and send a payment to the account on the page. Nothing on the screen tells it which values the carrier wanted it to use.
Who approves a claim payment the agent prepares?
A named adjuster, outside the model's context, before the payment is released. A default approval setting is not that person, because an administrator can switch it off, and a confirmation dialog is not that person either, because it asks the model to click. The approval that counts names the adjuster, the claim and the amount, and it is recorded against the payment rather than the session.
Does the claims platform's audit trail show what the agent read?
Usually not. A platform log records the transaction against the account that submitted it, so an agent signing in under an adjuster's login leaves the adjuster's name on the payment. It does not record which screens the model received or which values were on them. The record a carrier needs is the rendered screen as the model saw it, the action and the approver, exported to the carrier's own monitoring.
Do vendor controls stop an agent from reading the claimant's bank account?
No, because they govern who may act rather than what a page shows. Permissions decide which actions a user or an agent can take, a settlement option decides how a payment closes, and an audit trail records what happened. None of those changes the values drawn on the claim screen. The bank account reaches the model unless something replaces it before the page is read.
Can an agent work a claim on placeholders without losing accuracy?
Yes, for the work that matters. The loss date, the coverage, the deductible, the estimate and the reserve are the facts the adjuster reasons with, and none of them identifies the claimant. Consistent tokens keep the claim matched across the claims system, the estimating tool and the payment queue, so a drafted summary still prices the right claim. Accuracy fails when the substitution is inconsistent, not when the identity is replaced.
How RedactSure Keeps the Claimant Off the Model's Screen
A claim screen carries the person and the bank account along with the loss. Duck Creek's sheet promises "full auditability" with no approver or authority limit named.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent reads the name and the bank account under the adjuster's login. Inside: the page draws CLM_0912 and ACCT_014, and the real account resolves only at the payment the adjuster releases.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
An agent can read a claim without reading the person, and the difference is the screen it was given. Bring one claim and see, with test values, what the model receives, who releases the payment and what the record holds. Book a demo