Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Is It Safe to Let an AI Agent Check Insurance Eligibility?
No. An agent that checks eligibility types the member ID and date of birth, then reads the portal's rendered response, so the answer turns on what the screen hands the model; ask for a check where those values are placeholders the portal resolves and only the coverage result reaches the agent.
A practice checks eligibility before every scheduled appointment, and the form it fills is short: a payer, a provider type, a member ID with a three-character prefix, a date of birth, an As of Date. The answer comes back as a Patient Card with membership status and plan dates, and an agent that completes the same form reads the same card, so the identifiers it typed sit in the run beside the coverage it returned.
An agent can run the eligibility check, and the payer guides show the fields it fills. What a practice has to decide is what the check leaves in the model's context and what it can show afterward. A portal session belongs to the staff member who signed in, the response belongs to the member, and the model's copy of both belongs to no one unless the design says otherwise.
An eligibility response is insurance-transaction data about a named person, and the portal keeps a list of recently checked patients on the same screen.
Accountability for the check rests on what the rendered page hands the model, who approves an action the agent takes, and what the record shows after the run. One record type carries the question: an eligibility check for a scheduled appointment.
Key findings
- For an agent to check eligibility safely, the values on the portal's response would have to be replaced with consistent tokens before the model reads the screen, so the agent works with MEMBER_041 and COV_014 while the member's name, date of birth and plan stay out of its context (What Is Render-Layer Tokenization?).
- It would also require a named person approving each prior authorization the agent submits and a record of the screen the model received, because human approval "is a standard way to limit egregious failures" (Shavit et al., 2023).
- The payer guides describe every field the request takes and every field the response draws, and none of the pages reviewed states that a value is replaced before the model reads the screen, which is the gap this page found (BCBSOK, 2021).
- The request carries the "Patient ID (including three-character prefix)" and "Date of Birth," a past-date inquiry can reach "up to 12 months prior to the current date," and a future-date inquiry is limited to the current month (BCBSOK, 2021).
- Results arrive as a Patient Card in a Patient History List that "holds up to 200 patients for 24 hours," so a screen opened for one member can carry records for many others, and the list is a convenience rather than a record of who read it (BCBSOK, 2021).
What does an agent read on an eligibility check?
Start with one record type: an eligibility check for a patient with a scheduled appointment. The inquiry repeats for every scheduled appointment, which is why it is a candidate for an agent at all. The BCBSOK guide tells a practice that an eligibility inquiry "should be completed for each Blue Cross and Blue Shield of Oklahoma (BCBSOK) patient prior to every scheduled appointment," and that "Only registered Availity users can access Eligibility and Benefits Inquiry" (BCBSOK, 2021). The vendor path is the common one: 123.9 million of the 220.0 million people affected by large healthcare breaches in 2025 and 2026, 56.3%, were in breaches that came through a business associate, so the member ID the portal renders is the exposure this check has to bound (How Many Healthcare Breach Victims Were Exposed Through a Vendor?).
The response is the part that matters. It arrives as a Patient Card with membership status and plan dates, and the portal keeps it in a Patient History List that "holds up to 200 patients for 24 hours" (BCBSOK, 2021). For an agent, that list is a second screen of member records beside the one it was asked about, and a model that reads the rendered page reads the list.
Nothing on the page is scoped to the question. The card draws membership status and plan dates. The patient it was run for is the subject of every field on the page, and the coverage result sits inside that frame. The page was built for a person who knows which member is on the line, and it does not know that its reader is a model.
The guide warns that an eligibility answer is not a guarantee of payment, so an agent that reports active coverage from the card reports a provisional answer as though it were final.
Where does the member ID go once the agent has read the response?
The identifiers are not only in the answer. They are the input. Before the portal returns a card, the agent holds the member ID and the date of birth to submit, and the typed value stays in the session's transcript. The request itself needs "Patient ID (including three-character prefix)" and "Date of Birth," plus an As of Date that can reach "up to 12 months prior to the current date" (BCBSOK, 2021).
A prior authorization adds clinical detail: "Diagnosis Code(s)" and "Procedure Code(s)" with the tip "Add up to 12 Diagnosis Code(s) and Procedure Code(s)," and "up to 10 attachments, with a total file size of 40MB" (BCBSTX, 2022).
Insurance law treats that material as protected. The NAIC model act bars an insurer from disclosing "any personal or privileged information about an individual collected or received in connection with an insurance transaction" unless the disclosure is authorized, including by "the written authorization of the individual," and it binds only a state that adopts it (NAIC, Model Act, 1992). Its "privileged information" covers only information that relates to a claim.
A member ID that exists only at the portal's submit step does the same work as one typed into a prompt, and the response can be reduced to the coverage result before it reaches the model (What Is the PII Wall?). The portal's log credits the staff member who signed in, and the agent's transcript holds the values that login retrieved (Can a Browser Agent Read My Session Cookies?).
What do the vendors themselves say?
Two payer guides describe the screens this page is about. The BCBSOK guide covers Eligibility and Benefits Inquiry, and its warning is explicit: "Checking eligibility and/or benefit information is not a guarantee of payment" (BCBSOK, 2021). The Texas guide covers authorizations in the same portal. It describes "an online prior authorization tool in Availity Essentials that allows providers to submit inpatient admissions and select outpatient services," and warns that "You must be a registered Availity user to access and utilize Authorizations" (BCBSTX, 2022).
The authorization flow ends in a status and a queue. A submitted request returns a "Certification Number and Status," and the authorizations dashboard "displays all requests submitted in the last 14 days," searchable by "Patient Name, Certification Number, Member ID, Requesting Provider NPI" (BCBSTX, 2022).
The guides record the limits too. The BCBSOK guide caps the code route at "up to eight valid CPT/HCPCS Code" and says the check "is not yet supported" for FEP and Medicare Advantage (BCBSOK, 2021).
What the guides do not describe is the step between the portal drawing a card and a model receiving it. They are user guides for a person at a desk.
| Dimension | Availity eligibility and authorization, per the payer guides | What a buyer should verify |
|---|---|---|
| Who can open it | "Only registered Availity users can access Eligibility and Benefits Inquiry" (BCBSOK, 2021) | Which human account the agent runs under, and what the portal's log credits |
| What the request takes | Payer, provider type, "Patient ID (including three-character prefix)," "Date of Birth," an As of Date | Whether the model holds those values or only placeholders |
| What comes back | A Patient Card with membership status, then a list that "holds up to 200 patients for 24 hours" | Which fields the card draws beyond the coverage result |
| What a prior authorization adds | "Diagnosis Code(s)" and "Procedure Code(s)," up to 12 of each, and up to 10 attachments | Whether clinical detail can stay out of the model's copy |
| What record remains | A queue that "displays all requests submitted in the last 14 days" (BCBSTX, 2022) | What export shows the screen the model read and who approved the request |
Who approves a prior authorization the agent submits?
An eligibility inquiry is a read. A prior authorization is a write, and that is where approval belongs. The agent fills it under a staff member's Availity login, so the portal records the account.
The federal prior authorization rule requires a payer's API to "communicate whether the payer approves the prior authorization request" or deny it with a reason, "within 72 hours for expedited" requests and seven days for standard ones, with API compliance beginning January 1, 2027 (Centers for Medicare & Medicaid Services, 2024).
Approval inside the practice is the part the portal cannot supply. OpenAI's governance paper calls human approval "a standard way to limit egregious failures," and it asks that "at least one human entity is accountable for every uncompensated direct harm" (Shavit et al., 2023). A named approver outside the model, who sees the request and the screen behind it, is the form that takes.
An approval record is a designed artifact. Google's payments protocol describes a mandate as "cryptographically-signed digital contracts that serve as verifiable proof of a user's instructions" (Google Cloud Blog, 2025). The authorizations dashboard keeps a queue for 14 days, and the Patient History List keeps 200 patients for 24 hours; neither records what the model read, which is what a review compares with the file (Is It Safe to Let AI Agents Act in Production Systems?).
Platform controls do not close the gap. The AI Agent Index's entry for watsonx Orchestrate reports no dedicated user approval settings and no way to stop an agent mid-run, while the vendor says "predefined guardrails and policies are enforced automatically" (AI Agent Index, 2026). The NAIC model bulletin asks for "governance, risk management controls, and internal audit functions" (NAIC, Bulletin, 2023).
What does a governed environment change?
A governed environment acts where the screen is drawn, before any model reads it. Values chosen by policy are replaced with consistent tokens, so an eligibility check works with MEMBER_041 and COV_014 instead of a name and a date of birth. Real values resolve only at an approved destination, at the moment of an approved action. A named person approves each prior authorization and each record change, and every screen as tokens, every action and every approval goes to a record that exports to the organization's own monitoring.
For an eligibility check, the portal still receives the real member ID at submit. A private adapter is a process outside the agent's sandbox that holds the credential, makes the requested call and returns only the result (What Is a Private Adapter for AI Agents?).
The work does not suffer for it: replacing identifiers with consistent pseudonyms and restoring them afterward reduced semantic utility errors by a factor of five (Does Masking Data on Screen Break Browser Agents?). Guardrails that govern what the agent may do next leave the response untouched (What Are AI Agent Guardrails?). DAPLab puts it plainly: "access control governs who can touch data, integrity constraints govern what gets stored, but neither governs how data flows and is used during agentic execution" (Columbia DAPLab, 2026).
What the record shows
A practice that runs the check can show a login and a queue, and what decides the answer is the distance between those records and what the model read. The guides describe the request and the card, and are silent on a replacement step. The portal's record is a queue for people: 14 days of authorizations, 200 patients for 24 hours. What is missing is the screen the model was given and the name against the submission. A practice can test one response before it runs a live member: choose a test record, open the eligibility screen the agent will use, and list every field the page draws beside every field the session recorded. If the two lists match, the model read the member's record, and the check needs the control class above.
Methodology and limitations
The page rests on public documentation: two payer user guides for Availity eligibility and authorization screens, the NAIC model act and model bulletin, the CMS prior authorization fact sheet, a payments protocol, an agent governance paper, an agent index entry and a research blog. Both payer guides are archived snapshots from 2021 and 2022. Public documentation read in full gives a sound view of where each product applies its control. Vendor pages were read as of October 22, 2026, and each Sources line carries the date for its page.
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. The example describes a record type, not an organization. Statements about RedactSure describe its environment from its documentation, like the other products, and it is deploying now with enterprise and government customers. Determinations about whether a workflow meets a state requirement belong to counsel and compliance officers, and nothing here replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
Is it safe to let an AI agent check insurance eligibility?
No. The portal returns a Patient Card with membership status and plan dates, and an agent that runs the check reads the rendered card with the identifiers it typed in its context. The payer guides describe the fields the request takes and the card it returns; they describe no step that replaces a value before a model reads it. The check becomes defensible when the identifiers are placeholders the portal resolves and the model receives the coverage result alone, with a named person approving the submission.
What does the agent read on an eligibility response?
The whole rendered response, not the coverage line alone. The card draws membership status and plan dates, and the portal keeps it in a Patient History List that holds up to 200 patients for 24 hours. An agent asked about one member can read a list of others on the same screen. The card is the member's record for that visit; coverage status is one field on it.
Can an agent check eligibility without the member's date of birth on screen?
Not through the portal as the guides describe it. The request needs "Patient ID (including three-character prefix)" and "Date of Birth," and a prior authorization adds the patient's name and relationship to the subscriber. The portal needs the real values to answer; the model does not, if a placeholder is resolved at submit. The question is where the substitution happens, not whether the check can avoid identifiers.
Who approves a prior authorization the agent submits?
The person whose login submitted it, unless the practice names someone else in the workflow. The portal records the account, and the session belongs to the staff member who signed in. None of that tells the practice who decided the agent should submit, which is the approval a governed workflow adds. A prior authorization puts a service on record with the payer, so the decision deserves a name.
What record does an eligibility check leave?
A queue entry and a session log, not a record of what the model read. The authorization dashboard keeps requests for 14 days and the Patient History List keeps 200 patients for 24 hours. Neither shows the screen the model received or the person who approved the submission. Answering a member's question means exporting the page as the model saw it, the action and the approver's name.
Does limiting the agent to read-only access make the check safe?
No. Read-only access limits what the agent can change, and an eligibility check is mostly a read already. The response still reaches the model, and the identifiers the agent typed are already in its context, so the exposure is unchanged by a permission that removes writes. Scope narrows where the agent goes; it does not decide which values the page draws. The answer turns on the screen.
How RedactSure Keeps a Member's Identifiers Out of the Eligibility Check
The check is short and the response is not, and the controls above govern where the agent goes, not what the card holds. One BCBSOK guide says the history list keeps up to 200 patients for a day, so one screen can carry a waiting room.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent opens the eligibility screen with the member's real ID and date of birth, and the card's identifiers stay in its context. Inside the governed environment: the page is drawn with MEMBER_041 and COV_014, the portal resolves the real member at submit, and a named person approves the prior authorization before the real values resolve.
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 practice that cannot name what its agent read on an eligibility screen cannot answer for the check. Bring one eligibility check and see, with test values, what the model reads and where the member ID resolves. Book a demo