Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can an AI Agent Handle First Notice of Loss Without Seeing the Claimant's Identity?
No, not on an intake screen that prints the claimant's name, address and date of birth, because the model reads the record it is shown and keeps it for the rest of the run. Ask for an intake that renders CLAIMANT_001 and a claim system that resolves the real identity when it creates the claim.
First notice of loss is the claim task that arrives before anything is known. A policyholder calls, an intake form opens, and the fields fill in: what happened, when, where, and who was involved. Almost none of that is the claimant's identity. The date of loss, the location, the description and the policy number are the facts a claim is opened on, and the named insured, the service address and the date of birth already sit on the policy record attached when the claim is created. What a claims team inherits with an agent is the screen. An agent reads every field the intake page draws, and a model that read a date of birth holds it for the rest of the run (What Is Render-Layer Tokenization?). The exposure lands on the claims lead whose first contact with a claimant would sit in a transcript, and on the compliance officer who answers what the agent saw. A measured evaluation of autonomous web agents found that they "are prone to inadvertent use of unnecessary sensitive information" (Zharmagambetov et al., 2025).
Key findings
- For an FNOL to be taken without the model holding the claimant's identity, the values on the rendered intake screen would have to be replaced with consistent tokens such as CLAIMANT_001 before any model reads it, with real values resolving only at claim creation (What Is Render-Layer Tokenization?).
- It would also require a named person approving the claim and a record of what the model received, because the NAIC Model Bulletin, adopted by 24 states as of March 2025, requires insurers to maintain a governance accountability structure (Who Approves an AI Agent's Claim Payment?).
- The gap sits at the intake: Guidewire's release says its agentic FNOL works on "policy, claims, and billing data and workflows," and describes no tokenized field, no approval step and no record of what the model read (Guidewire, 2026).
- Persona's documentation defines an inquiry as "a single instance of a Persona identity verification flow," whose approved and declined states "contain results for you to use," so the identity check can leave its own record (Persona, 2026).
- Stripe's Verification Sessions documentation separates a "document" check from an "id_number" check, so a claimant's identity can be resolved through a session the intake agent never opens (Stripe, 2026).
What does an agent read on a first notice of loss?
An FNOL is a structured report, and the structure is why the task suits an agent. The intake collects the policy number, the date and time of loss, the location, a description of what happened, the parties involved, injuries, and the photos the claimant uploads. None of those fields is a date of birth.
The screen draws the policy record beside the intake, and that record carries the named insured, the service address and the date of birth. Guidewire's release says the Agentic Framework gives agents "secure, real-time access to policy, claims, and billing data and workflows," and names "Agentic First Notice of Loss (FNOL)" among the agents it ships (Guidewire, 2026). An agent working the intake reads the identity block whether or not the loss facts need it, and least privilege does not change that, because it governs the actions and credentials an agent holds and not the content of the screen it reads (What Is Least Exposure?).
The loss facts and the policy match are the intake. The identity block is read because the policy record carries it, so the model receives it whether or not the task needs it, and the bank account belongs to a later screen. An intake that rendered CLAIMANT_001 in the identity block would give an agent everything the claim needs, and nothing it should not hold.
Which fields on the intake screen carry the claimant's identity?
Four groups of values reach an intake screen, and only one is identity: the legal name, the service address, the date of birth and, on some forms, a government identifier. The bank account and routing number belong to a later screen, and the description is not an identity field.
Identity verification has its own flow: Persona defines an inquiry as "a single instance of a Persona identity verification flow," whose approved and declined states "contain results for you to use" (Persona, 2026). Stripe's documentation offers a "document" type that verifies "government-issued identity documents" and an "id_number" type that verifies "a user's name, date of birth and national ID number" (Stripe, 2026).
A redacted session keeps "placeholder values in all fields that previously contained personally identifiable information," and Stripe says redaction "can take up to 4 days" (Stripe, 2026), a deletion request handled after the fact. The state regulator points at the verification: "Covered Entities should consider using authentication factors that can withstand AI-manipulated deepfakes" (New York State Department of Financial Services, 2024).
Filling a field from a store while the model sees a placeholder is documented for browser agents (Can a Browser Agent Fill In a Form Without Seeing the Values?), and on a claim it completes the field without the model holding it.
What do the vendors themselves say?
Guidewire's release announces the Agentic Framework in its Qusar release, names "Agentic First Notice of Loss (FNOL)" among the agents it describes, and says the framework gives agents "secure, real-time access to policy, claims, and billing data and workflows" (Guidewire, 2026). It carries no approval workflow and no statement that a human must approve a claim the agent opens.
Persona's documentation describes the identity half as an object with a status: an inquiry is "a single instance of a Persona identity verification flow," and its approved states "contain results for you to use" (Persona, 2026). It does not say which inquiry fields render back to an agent.
The closest documented statement of what a model receives comes from a page about claim files: OpenAI's safety write-up describes what the model sees as webpage text and document content within connected apps, and only credentials are kept out (Can Insurers Use OpenAI Dots on Claim Files?).
| Vendor | What its documentation states | What a buyer should verify |
|---|---|---|
| Guidewire | Agentic FNOL with access to policy, claims and billing data | Whether the intake renders a token, and who approves the claim |
| Persona | An inquiry object whose approved and declined states hold results | Which inquiry fields a claims screen shows |
That absence is not one vendor's. Of 15 AI agents and 86 AI security products reviewed, none describes replacing the customer data an agent reads on a screen with tokens it can work with, and the claims products described here were outside both sets (Do AI Agents Ask Before Making a Payment?).
Who approves the claim the agent creates, and what record does it leave?
A claim creation is an externally visible act: it opens a file the claimant can ask about, starts the clocks a regulator measures, and usually sets a reserve the insurer carries. The guidance reviewed treats approval as a property of the action: "Require human approval for high-impact, sensitive, irreversible, or externally visible actions whenever feasible" (Harvard University Information Security and Data Privacy, 2026).
The insurance requirement is stated as a structure rather than a click. The NAIC Model Bulletin, adopted by 24 states as of March 2025, requires insurers to maintain a governance accountability structure for AI systems with defined responsibilities, and an agent's claim with no named approver fails that requirement on its face (Who Approves an AI Agent's Claim Payment?).
The record is the other half. It should hold the screen as the model read it, the token that stood in place of the identity, the action, and the name and time of the approval. Without the first two the insurer cannot say what the model held, and without the last two it cannot say who is accountable. An approval recorded against a role answers neither question a year later, and a reviewer who has not seen the loss facts approves a claim nobody described to them.
What does a claimant's free text do to the model's reading?
The description field is the one place the claimant's own words enter the claim file, and a model reads them as content rather than as testimony. That is the shape prompt injection takes: instructions embedded in "a seemingly benign content, such as text or even images," after which "the hidden prompts can hijack system behavior" (MIT Sloan Management Review, 2025).
The damage does not stay on the screen where it lands. A 2025 study of information flow reports that "poisoned data retrieved from one component can change the model's behavior and compromise the entire system, including coercing the model to spread confidential data to untrusted components" (Siddiqui et al., 2025). Filters do not settle it: an adaptive-attack study bypassed 12 published defenses with "attack success rate above 90% for most" (Nasr et al., 2025).
Harvard's guidance names the combination that makes the failure expensive: "access to private data, exposure to untrusted content, and the ability to send data outward. If you can remove one, do." (Harvard University Information Security and Data Privacy, 2026). Neither can be removed from an intake that has to work. The third is what a token changes: an agent holding CLAIMANT_001 can be misdirected, and what it spreads resolves nowhere outside its environment (What Can a Hijacked Agent Leak If It Only Has Placeholders?).
What does a governed environment change?
A governed environment acts where the page is drawn. Values chosen by policy are replaced with consistent tokens for the whole run, so the intake renders CLAIMANT_001 in the identity block and header while the loss facts and claim number stay readable. Consistency keeps the task intact: the same token follows the claim to the adjuster's note, so the agent can refer to the claimant without holding the name (Does Masking Data on Screen Break Browser Agents?).
Real values resolve only at an approved destination, at the moment of an approved action. For an FNOL those destinations are narrow: the claim system at creation, where the policy record supplies the named insured, the address and the date of birth, and the payment screen after a person approves the payment. A named person approves the claim creation, and the record holds the screen as the model read it, the action, the approver and the time.
Two limits belong with the claim. The control covers the pages the agent reads, not the claims system's database or an API the agent calls directly. And identity verification remains its own problem: a session still has to resist a spoofed face and a stolen document, and a screen that renders a token does not make a weak check strong.
What the record shows
Replacing the identity block on the rendered intake with consistent tokens before any model reads the page keeps the loss facts readable and takes the claimant's name, address and date of birth out of the model's context. Verification leaves an inquiry with a status and results, a claim system holds the policy record that names the insured, and the intake only carries a handle between them. What the reviewed pages do not show is an intake that renders that handle. A team can settle it with one claim: name one FNOL workflow, run a test claim, print the intake screen the model received, and compare the identity resolved with the one on the page.
Methodology and limitations
This page rests on vendor documentation from Guidewire, Persona and Stripe, guidance from the New York State Department of Financial Services, university guidance, one industry analysis article, three research papers, and RedactSure pages. Vendor pages were read as of October 22, 2026, and each vendor entry carries the date for its page. Public documentation read in full gives a sound view of where each product applies its control.
No product named here was tested for this page; all are described from documentation, and "not described in the pages reviewed" means the recorded facts for that page do not cover it: none of the vendor pages reviewed carries a field list for an agentic FNOL. Vendor features change and the page carries its date. RedactSure is deploying now with enterprise and government customers. The example describes a record type, an FNOL taken by an agent, not an organization. Determinations belong to counsel, assessors and the organization's security officers; nothing here replaces a pilot on the organization's own screens.
Frequently asked questions
Can an AI agent handle first notice of loss without seeing the claimant's identity?
No, not on an intake screen that prints it. The screen draws the policy record beside the form, and that record carries the named insured, the service address and the date of birth, so the model reads them while it works the loss facts. An intake that rendered CLAIMANT_001 in that block changes the answer, because the claim system resolves the real identity at creation. Ask which of the two your intake does before an agent takes a live report.
Which fields on an FNOL screen carry the claimant's identity?
The name, the service address, the date of birth and, on some forms, a government identifier. The bank account and routing number belong to the payment screen and arrive later. The loss facts, the location, the description and the policy number identify the claim, not the person. The description is the field to watch, because a claimant can write an identity into it, and a screen that tokenizes the identity block still has to decide what it does with that.
Can the intake run on a token while the claim system resolves the real person?
Yes, and that is what the token is for. The agent fills the loss facts, matches the policy number, reads the claim number the system assigns, and refers to the claimant as CLAIMANT_001 throughout. The claim system resolves the token at creation from the policy record it holds, and a named person approves the claim. The limit is the screens after the intake: a letter that resolves the token back to the name puts the identity in front of the model again.
Who should approve the claim the agent creates?
A named person, recorded against the claim rather than against a role. A role check answers what someone may do, not who reviewed this file. Harvard's guidance asks for human approval on high-impact, sensitive, irreversible or externally visible actions, and opening a claim is one. The reviewer needs the loss facts and the token, not a birth date, to decide whether the claim should open.
What record should the insurer keep of the agent's intake?
Four things: the screen as the model read it, the token that stood in place of the identity, the action the agent took, and the name of the person who approved it with the time. A transcript alone does not show what the page rendered, and a log that names an action without an actor cannot answer the claimant. Exported, the record also shows whether the token policy held for the run.
Does identity verification take the place of a screen control?
No. Verification answers who the person is, and it can do that well or badly, as the guidance on deepfake-resistant factors suggests. It does not decide what the model reads when the claim opens afterwards. A verified claimant whose name and date of birth still print on the intake screen is verified and exposed at once. An insurer needs both records.
How RedactSure Takes an FNOL Without Rendering the Claimant's Identity
An intake that prints the claimant's identity puts a name, an address and a birth date into every note the model writes. Guidewire's release gives its agents "secure, real-time access to policy, claims, and billing data and workflows" and describes no tokenized field (Guidewire, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent reads the named insured, the service address and the date of birth, and they follow the claim into the notes. Inside: the identity block renders CLAIMANT_001 for the run, the claim system resolves the person at creation, and a named person approves the claim.
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
A claim that prints the claimant's identity teaches the model a name it will repeat in every note. Bring one FNOL your team runs and see, with test values, the intake as the model reads it, the approval and the record. Book a demo