Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can an AI Agent Quote a Policy Without Seeing the Applicant's Date of Birth?
No. A quote worksheet prints the applicant's date of birth beside the rating inputs, so an agent that prices the quote reads it and the model keeps a copy for the rest of the run; ask for a screen that renders DOB_001 and a rating engine that receives the real date only at submit.
A quote is the cheapest document an insurance producer makes and the one most often reworked. A producer enters an applicant on a call, the worksheet rates the case, and a premium comes back in seconds, which is why the step suits an agent. The date of birth is one of the first fields entered, because the price depends on age. An agent that completes the same steps reads the same field, and a model that reads a birth date keeps it for the rest of the run. Two people have something at stake: the producer whose book of business would sit in a transcript, and the security lead who has to answer what the agent saw when an applicant asks. What a vendor page does not show is what the screen hands the model, what the rating call needs, and what a team can require before an agent touches an application. The record here is a quote worksheet for a term policy, priced on age, and the control that changes the answer is substitution at the render layer (What Is Render-Layer Tokenization?).
Key findings
- For a quote to be priced without the model holding the date of birth, the values on the rendered worksheet would have to be replaced with a consistent token such as DOB_001 before any model reads the screen, with the real date resolving only in the rating call (What Is Render-Layer Tokenization?).
- It would also require a named person approving the submission and a record of what the model received, since AWS's guidance states that "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, 2026).
- The gap stops at the quote screen: Persona's inquiry page describes how a verified identity is retrieved, and no page reviewed describes a worksheet that renders a token in place of the date of birth (Persona, 2026).
- Anthropic's help page for Claude in Chrome states that "Claude sees what's on the page and can act on it," so a birth date left on a worksheet is inside the model's context for the rest of the run (Anthropic, 2026).
- Okta's connector reference lists "Birth Date" among the fields an automation can set, and the page does not say those fields are masked, restricted or redacted in Workflow logs (Okta, 2026).
- The BCBSOK eligibility guide requires "Patient ID (including three-character prefix)" and "Date of Birth" before an inquiry runs, so the date is a required key on an insurance screen (BCBSOK, 2026).
What does an agent read on a quote worksheet?
The worksheet collects the applicant's details and shows the rating result beside them. A term quote carries the name, the date of birth, the age, the coverage and the term, plus the premium the rating returned. The agent fills the first group and reads back the last figure, and every step passes through the band where the date of birth sits. None of the 15 AI agents or 86 AI security products reviewed describes replacing a value on a working page with a token the agent can use, so the date of birth on the worksheet is read as printed rather than as DOB_001 (Do AI Agents Ask Before Making a Payment?).
| What the worksheet shows | What the rating uses | What the agent needs |
|---|---|---|
| Applicant name | Nothing for the price | The name field it typed |
| Date of birth | The age at the effective date | The field, to fill it once |
| Age band | The band the rate table is keyed on | The band, to check the premium |
| Premium | The output of the rating call | The figure it reads back |
All four rows are values the agent uses, and one of them, the birth date, is needed only as a field to fill; the band beside it is what the pricing consumes. A screen that drew DOB_001 in that row and left the band in place would give the agent everything it needs.
The vendor pages make the exposure concrete. Anthropic's help page for Claude in Chrome states that "Claude sees what's on the page and can act on it," a description of a model reading the rendered page, not a selector that picks fields (Anthropic, 2026). The BCBSOK eligibility guide requires "Patient ID (including three-character prefix)" and "Date of Birth" before an inquiry runs, so the date is a key the workflow cannot skip (BCBSOK, 2026).
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?). The quote screen adds the band the agent reads back after the fill, which a placeholder in the field alone does not settle.
Which part of a date of birth does the rating use?
The rating engine prices from the applicant's age at the effective date, and the rate table is keyed on an age band, so the engine needs to know which band the applicant falls in. The day and month matter at a boundary: a birthday inside the term, or a product priced on age nearest birthday. The band is what the price depends on.
The federal de-identification guidance lists "All elements of dates (except year)" among the identifiers it removes for dates tied to an individual (HHS, 2012). The year survives because it carries the age and the band; the day and month are the identifying part.
The retrieval side has its own tier. Stripe's Identity documentation states that "Access to more sensitive fields require restricted API keys," and the restricted keys it describes reach "sensitive verification results for verifications processed in the last 48 hours" (Stripe, 2026). The window is a property of the key, not of the data, and a value behind a service key can reach the rating call without being printed on the page a model reads.
Masking the band instead of the date is the mistake to avoid. A screen that hides the date but leaves the age and the postal code still narrows the range, and a screen that changes the token from page to page costs the agent the thread of the run. Consistent tokens keep the task intact (Does Masking Data on Screen Break Browser Agents?).
What do the vendors themselves say?
Zendesk's help center states that an admin or agent with permission to edit user profiles "can take on the credentials of an end user to view and use Zendesk Support as that end user" (Zendesk, 2026). That is a control on identity: the agent acts as the applicant and sees the applicant's whole view, not the field the task needs. The article records no approval step or audit trail for the session.
Anthropic's page for Claude in Chrome states that "Claude sees what's on the page and can act on it," and that the side panel defaults to "Automatically approve" mode, pausing when needed (Anthropic, 2026). The default sets what the agent may do next, not what the page put in front of the model.
Stripe's documentation sits on the retrieval side. "Access to more sensitive fields require restricted API keys," it states, and its restricted keys cover "verifications processed in the last 48 hours" (Stripe, 2026). A key tier governs which service may ask for the date and how long the answer stays reachable, not what a worksheet prints.
Persona's documentation describes the record a verification leaves: an inquiry is "a single instance of a Persona identity verification flow," and approved, declined and needs_review inquiries "contain results for you to use" (Persona, 2026). That result can reach a rating call without a person opening the case.
What should an insurer ask for in writing?
Five questions settle it, and each answer can be checked against a vendor's own pages.
- Where the date of birth lives, and which service key can read it. Stripe's tiering is the model: a field that needs a restricted key can stay off the screen the agent reads (Stripe, 2026).
- What the model receives from the rendered quote screen, field by field. A vendor that cannot answer for a rendered page has not described the control.
- Whether the worksheet reprints the date on the confirmation or the PDF. A token that resolves to the real value in the PDF is not the same control.
- Who approves the submission, and whether the approval names the person.
- What record shows the page as the model read it. Okta's connector reference is the caution: it lists "Birth Date" among the fields an automation can set, and does not say those fields are masked, restricted or redacted in Workflow logs (Okta, 2026).
A screenshot of a vendor's own dashboard is not what the model received on the insurer's page. Ask for the rendered page, and for the log line that shows the token rather than the value.
Least privilege does not answer these questions. It governs the actions and credentials an agent holds, and an agent can satisfy it in full while holding every field its screen showed (What Is Least Exposure?).
Who approves the quote, and what record remains?
A quote is a priced offer, and someone at the insurer is accountable for the price. Today that accountability sits with the producer, and the approval is implicit in the click. An agent moves the click away, which makes approval and record separate requirements.
The default in agent products is not encouraging. The 2025 AI Agent Index entry for Glean Agents records user approval requirements as "None found, in the actual agent," a snapshot of one review, not a permanent property (AI Agent Index, 2026).
AWS's guidance separates the two actors: "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, 2026). A log that shows an action without the actor cannot answer the applicant's question.
The verification record shows the shape. Persona's inquiry object carries the status and results of a check, retrievable through its API or dashboard (Persona, 2026). A quote record should carry the page as the model read it, the token, and the name of the person who approved. The approved destination matters, since a token that resolves on an unapproved page is only a delay (What Is an Approved Destination for AI Agent Output?). An insurance desk that works a policy by its token rather than a member's name is the same substitution (Is Grok Bot Safe for Insurance Staff?).
What does a governed environment change?
A governed environment puts the control where the page is drawn. Values chosen by policy are replaced with consistent tokens for the whole run, so the worksheet shows DOB_001 in the applicant row while the age band stays readable. Real values resolve only at an approved destination, at the moment of an approved action, and the rating call is such a destination: it receives the date the engine prices from.
The agent still fills the row, runs the rating and reads the premium back. The model's context carries DOB_001 where the date would have been, and the confirmation, the PDF and the follow-up page carry the same token. A named person approves the submission, and the record shows what the model read on each screen.
Two limits belong with the claim. The first is scope: a control at the render layer governs the pages the agent reads, not the rating engine's database or the API it calls directly. The second is design: the age band has to stay on the screen for the agent to check the price, so the control substitutes one value and leaves the rest of the page alone. An identity control and a screen control answer different questions, and the Okta comparison sets out where an identity control stops (RedactSure vs Okta).
What the record shows
Replacing the date of birth on the rendered worksheet with a consistent token before any model reads it keeps the arithmetic that prices the quote and takes one protected identifier out of the agent's context. On the documentation reviewed, that is the only place the substitution can sit, because every other control acts on who the agent is or on where its output may go. A quote is priceable without the model holding the date only when the page renders DOB_001 and the rating call receives the real value at submit. Name one quote product and run one application with test values; print the worksheet the model received, mark the fields that carry a token, and compare the date the rating call used with the date on the page.
Methodology and limitations
This page rests on vendor documentation from Anthropic, Zendesk, Stripe, Persona, Okta and BCBSOK, one regulator guidance page on de-identification, one industry dataset, and existing RedactSure research pages. 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.
No product named here was tested for this page; the products are described from documentation, and "not described in the pages reviewed" means the recorded facts for that page do not cover it. Vendor features change, and the page carries its date. RedactSure is deploying now with enterprise and government customers. The example describes a record type, a quote worksheet for a term policy, and not an organization. Determinations about whether a quote workflow meets a regulatory or contractual requirement belong to counsel, assessors and the organization's own security and compliance officers, and nothing here replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
Can an AI agent quote a policy without seeing the applicant's date of birth?
No, not on a worksheet that prints the field. The applicant row carries the date of birth, the agent reads the row to complete it, and the model keeps whatever it read for the rest of the run. A token in place of the date changes the answer, because the model then works from DOB_001 while the rating call receives the real value. Ask which of the two the screen does before you let an agent price a quote.
Can the agent price a quote from a rendered worksheet that shows DOB_001?
Yes, and the arithmetic is unaffected. The rating engine needs the age band, which stays on the page, and the real date reaches the rating call at submit. What the agent loses is the ability to read or repeat the birth date, not the information the task requires. The limit is the pages after the quote: a confirmation or PDF that resolves the token back to the value puts it in front of the model again.
Who approves the quote submission, and what record shows what the agent read?
A named person should approve it, and the record should show the screen as the model read it. On the documentation reviewed, approval is not automatic: the AI Agent Index entry for Glean Agents found no user approval requirement in the agent. A log that names the actor and the page closes that gap, and it is the artifact an insurer shows when an applicant asks what the agent saw.
Does a restricted API key keep the date of birth out of the model?
Only out of the retrieval path, not out of the screen. Stripe's documentation puts more sensitive verification fields behind restricted API keys, and the restricted key reaches results for the last 48 hours, which governs who can fetch the value. A model reading a quote worksheet never uses that key; it reads what the page rendered. The key tier and the screen control are separate, and only one of them changes what the model sees.
What should an insurer ask a vendor in writing?
Ask where the date of birth is stored, which service key can read it, and what the model receives from a rendered quote screen, including the summary band after the rating. Add who approves the submission and what record of the pages exists. Okta's connector reference is the caution: it lists "Birth Date" among the fields an automation can set, and it does not say those fields are masked in Workflow logs.
What does a birth date on a quote screen cost the model's context?
It costs the run its deniability. A date of birth is a protected identifier that, with a name and a postal code, narrows to one person, and a model that read it can repeat it in a summary, a note or a later page. The cost is not the premium calculation, which needs only the band. It is the copy of the value that stays in the agent's context after the quote is priced.
How RedactSure Quotes a Policy Without Rendering the Birth Date
A quote worksheet prints the applicant's date of birth in the band the agent reads back, and the controls reviewed above leave that field in place. Anthropic's help page states that "Claude sees what's on the page and can act on it" (Anthropic, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the model reads the date in the row it fills and again in the summary it checks. Inside the governed environment: the row renders DOB_001, the rating call receives the real date at submit, and the model reads the band and the premium, with a named person approving the quote.
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 quote worksheet that prints the applicant's date of birth puts a protected identifier in every follow-up the model writes. Bring one quote your team runs and see, with test values, what the model reads and where the real date resolves. Book a demo