Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can an AI Agent Submit a Prior Authorization Without Seeing the Diagnosis?
No. The authorization form draws the diagnosis and procedure codes beside the member's identifiers, so an agent that fills it reads the diagnosis before it submits; a workflow that keeps those codes off the screen until the payer's own submit step is the only version that changes the answer.
No, not while the diagnosis code is a field the form draws. A practice that hands a prior authorization to an agent is asking it to assemble a request whose second step carries the diagnosis and procedure codes beside the service type, and the page is drawn for a person who already knows the diagnosis. The agent reads the page, so the code is in the model's context before the payer sees anything. A registered-user gate, a certification status and a confirmation prompt decide who submits; none of them decides what the page shows.
The record is a prior authorization with diagnosis code DX_001, filed before a procedure. The federal prior authorization rule requires payers to maintain a Prior Authorization API that can "identify documentation requirements for prior authorization approval" (Centers for Medicare & Medicaid Services, 2024), which turns the clinical basis of a request into something software reads. Whether the agent needs the code's meaning to choose the service type and the procedure, or only needs to place a value someone else chose, is the design question that decides which workflow gets a control.
Key findings
- For an agent to submit a prior authorization without reading the diagnosis, the codes on the rendered form would have to be replaced with consistent tokens before any model reads the screen, so the agent places DX_001 and PROC_014 while the payer receives the real values at its own submit (What Is Render-Layer Tokenization?).
- It would also require a named person approving each request 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 guide names every field the authorization takes and does not state that a value is replaced before a model reads the form (BCBSTX, 2022).
- The guide's second step takes the service type, place of service and admission date, then "Diagnosis Code(s)" and "Procedure Code(s) (if applicable)", with the tip "Add up to 12 Diagnosis Code(s) and Procedure Code(s)" (BCBSTX, 2022).
- A submission returns a "Certification Number and Status", and the authorizations dashboard "displays all requests submitted in the last 14 days", searchable by patient name and member ID (BCBSTX, 2022).
- NIST's red-teaming competition found "at least one successful attack was found against all of the target frontier models", so a model that behaves on one run is not evidence about the next (NIST, 2026).
What does a prior authorization form ask the agent to read?
The record is a prior authorization with diagnosis code DX_001. The payer's user guide describes "an online prior authorization tool in Availity Essentials that allows providers to submit inpatient admissions and select outpatient services" (BCBSTX, 2022). Step 1 collects the member's "Member ID", relationship, name and "Patient Date of Birth", then the requesting provider's "NPI Number" and specialty. Step 2 takes the service type, the place of service and the admission date, then "Diagnosis Code(s)" and "Procedure Code(s) (if applicable)" (BCBSTX, 2022). Step 4 accepts "up to 10 attachments, with a total file size of 40MB" (BCBSTX, 2022). The vendor path is already the common one for this data: 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 (How Many Healthcare Breach Victims Were Exposed Through a Vendor?).
A person filling that form has the chart open beside it. The diagnosis code is copied from the chart into the field, and the procedure code from the order. The page asks the reader to transcribe what the record already says, and the code is in the model's context from the moment Step 2 renders. A clinical note sent to support the request usually states the diagnosis in prose, so the attachment is a second copy.
Every field the step draws is something a model can carry out of the run, and no view shows the codes to the payer while withholding them from the reader. The payer's decision is about those codes, which is why the form draws them where a reader must see them (What Is the PII Wall?).
Does the agent need the diagnosis code to fill the form?
The answer depends on which part of the task the agent holds, because placing a value is not the same as choosing it. A diagnosis code that a clinician or a coding system has already selected can arrive at the form as a value to transcribe, and an agent can do that from a token (Can an AI Agent Work With a Placeholder Instead of a Real Credential?): the token sits in the field, the payer's submit resolves it, and the model never learns what DX_001 means. A procedure code chosen to match the diagnosis is a different task, because the choice depends on the diagnosis, the payer's coverage rules and the service type, and a token carries none of that.
De-identification is not the answer here. HHS describes two methods for de-identifying protected health information, and the Safe Harbor method removes the listed identifiers, among them "All elements of dates (except year)" for dates that relate to the individual. The same guidance warns that both methods "yield de-identified data that retains some risk of identification" (HHS, 2026). A payer deciding DX_001's request needs the identity and clinical basis de-identification removes, so the choice is substitution at the screen, not removal from the record.
OWASP states the exposure: "Personal identifiable information (PII) may be disclosed during interactions with the LLM" (OWASP, 2025). Gartner warns that "When the same controls are applied indiscriminately, organizations encounter two common failure modes" (Gartner, 2026). The split is available: the ordering clinician selects the diagnosis and the procedure, and the agent assembles the request. Where the agent must suggest the procedure from the diagnosis, it needs the meaning, and a placeholder either blocks the suggestion or leaves the agent inferring a code from a token.
What do the vendors themselves say?
The Availity authorization screens are documented by the payer that uses them, and the Texas guide is specific about what each step collects. It also states its own limit on access: "You must be a registered Availity user to access and utilize Authorizations" (BCBSTX, 2022). That sentence governs the account, not the screen, and an agent under a registered user's session inherits the whole page.
A submission 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 document is a 12-page PDF dated January 2022 whose running header reads "Receiving Medical Record Requests from BCBSOK" on a Texas guide, so the wording comes from the archive snapshot (BCBSTX, 2022); the live path now returns 404.
| Dimension | Availity authorization, per the payer guide | What a buyer should verify |
|---|---|---|
| Who can open it | Registered Availity users | Which human account the agent runs under |
| What the form takes | Member and provider keys in Step 1, service data and codes in Step 2 | Whether the agent chooses a code or places one |
| What Step 4 accepts | Up to 10 attachments, 40MB, PDF, TIFF, JPEG, XML | Whether the note with the diagnosis reaches the model |
| What comes back | Certification Number and Status, certified or pended | What the practice keeps beyond the status |
The last column is where the record stops. The guide describes the fields, the access rule and the payer's answer, and it does not describe a step between the page rendering and a model receiving it (Which Enterprise AI Agents Can Work on Screens With PII Today, and What Does Each One Read?).
Who approves a prior authorization the agent submits?
A prior authorization is a write. It puts a service on record with a payer, and the payer answers by approving the request, denying it with a reason, or asking for more information (Centers for Medicare & Medicaid Services, 2024). A read can be repeated; a certified request changes what the payer will pay for, which is why the approval belongs outside the model. Harry Ghuman, CEO of Alpha Decisions, put the authorization question in process terms on a HAL podcast: "But we still need to start from what is the business process and what are the main business processes that the client has and who in there is authorized to do what" (What Is the AI Delegation Frontier? Harry Ghuman on Who Gave the AI Its Authority).
The portal's own record does not supply it. The submission returns a status, and the dashboard keeps the request for 14 days, but neither records who decided that the agent should file. The account that submitted belongs to the registered user, so the payer's log credits a person who may have approved nothing. AWS's agentic guidance asks for the opposite in an audit trail: "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, 2026). A log that shows only the staff account fails that test.
OpenAI's governance paper gives the shape of the control. Human approval "is a standard way to limit egregious failures", and "at least one human entity is accountable for every uncompensated direct harm" (Shavit et al., 2023). For this form the approval that matters is a named person who sees the request and the screen behind it before the codes resolve at submit, with the name attached to the request rather than to the session.
What does a governed environment change?
It changes what the model receives, not what the payer receives. Values chosen by policy are replaced with consistent tokens before any model reads the screen, so the authorization draws MEMBER_041, DX_001 and PROC_014, and the work proceeds on them. For each task the planner proposes what to tokenize, starting from personal information, account numbers, credentials and record numbers. Real values resolve only at an approved destination, at the moment of an approved action, which for this form is the payer's own submit. A named person approves each request before the real codes resolve, and a record of the screen, the action and the approver exports to the organization's monitoring.
Two details decide whether it holds here. The first is the attachment, because a policy that covers the code fields and not the clinical note has covered the smaller copy. The second is the meaning the token removes. Consistent pseudonyms restored after the model's work reduce semantic utility errors, the evidence that tokenization does not break a task that only needs values placed (Does Masking Data on Screen Break Browser Agents?). A placeholder that guards only what the agent types leaves the page itself uncovered (Can a Browser Agent Fill In a Form Without Seeing the Values?).
The surrogate that replaces a diagnosis code is not a credential. The OAuth refresh token that keeps an agent signed in to the portal is one, and the OAuth framework states that "Refresh tokens MUST be kept confidential in transit and storage" (IETF, 2012). Substituting the first does not protect the second, and a practice that has tokenized the form still has to decide what the agent's session may do (What Is an Approved Destination for AI Agent Output?).
What the record shows
No, on the form as the payer guide describes it: the diagnosis code is a field Step 2 draws, the agent reads the page to fill the step, and Step 4 can carry the same diagnosis again in the clinical note. The registered-user gate narrows who may open the tool, and the certification status records the payer's answer; neither changes what the page shows. What changes the answer is a form on which the codes are tokens resolved at the payer's submit, a named approver, and a record of what the model read and who released the values. A practice can test one request before it files a live one: choose a test authorization, run the agent, and compare the fields the page drew with the fields the run recorded. If the diagnosis appears in both lists, the code reached the model, and the workflow needs the control class above.
Methodology and limitations
The page rests on public documentation: a payer user guide for the Availity authorization screens, the federal prior authorization fact sheet, HHS de-identification guidance, an OWASP entry, an OAuth specification, a NIST red-teaming summary, an agent governance paper and a Gartner release. The guide is a 12-page PDF dated January 2022, read from an archive snapshot because the live path returns 404. Public documentation read in full gives a sound view of where each product applies its control. The pages were read as of October 22, 2026.
The products on this page are described from their public documentation, and none was tested for this page, RedactSure included; the example describes a record type, not an organization, and vendor features change with the page's date. A behavior this page calls not described in the pages reviewed means the pages reviewed do not state it. Determinations about what a workflow may disclose belong to counsel, assessors and the organization's 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 submit a prior authorization without seeing the diagnosis?
No, not while the diagnosis code is a field the form draws. The guide's second step takes the diagnosis and procedure codes beside the service type, and the agent that fills the step reads them. A registered-user gate or a confirmation prompt changes who can open the tool, not what the page shows. The answer changes where the codes are tokens the payer resolves at submit, and the agent's task is to place them.
What does the agent read on an authorization screen?
Every field the request displays, which is the point of the form. Step 1 draws the member ID, relationship, patient name and date of birth; Step 2 the service type, place of service, admission date and the two code fields; Step 4 the clinical attachments. A model reading the rendered page receives the whole step. No view shows a field to the agent and withholds it from the reader.
Can the codes on the rendered form be placeholders the payer resolves?
Only where the agent has to place a value and not interpret it. A consistent token can stand in the diagnosis code field, the payer's own submit can resolve it, and the agent can complete Step 2 without holding the code. That design fails where the agent must choose the procedure or the service type to match the diagnosis, because a token carries no clinical meaning. The workflow has to separate the choice from the entry before substitution helps.
Who approves a prior authorization the agent submits?
The person whose Availity account submitted it, unless the practice names someone else. The portal records the registered user and returns a status, and neither shows who decided that the agent should file. A named approver outside the model, who sees the request and the screen behind it before the codes resolve, is the approval a governed workflow adds, and the record carries that name.
What record does a submitted authorization leave?
A certification number and a status, then a queue entry. The guide's dashboard displays requests from the last 14 days and searches them by patient name, certification number, member ID and requesting provider NPI. That is a record of what was submitted, not of what the model read or who approved it. Exporting the screen the agent received and the approver's name is a separate design, and a review asks for it.
Does a read-only role or a confirmation prompt change the answer?
No. Read-only access limits what the agent can change, and the diagnosis reaches the model on the page it reads, so removing writes leaves the exposure in place. A confirmation prompt asks a person to accept an action after the model has already read the screen. Both narrow where the agent goes and what it may do; neither decides which values the page draws.
How RedactSure Keeps a Diagnosis Code Off the Agent's Screen
The request is decided on a diagnosis, so the code is on the form, and the controls above govern who may submit, not what the page shows.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the agent opens Step 2 with the member's real member ID and the diagnosis and procedure codes in the clear, and the attachment carries the note. Inside the governed environment, the page draws MEMBER_041, DX_001 and PROC_014, the payer's submit resolves the real values, and a named person approves the request before they resolve.
RedactSure is deploying now with enterprise and government customers. The same guide caps the form at "Add up to 12 Diagnosis Code(s) and Procedure Code(s)", so one screen carries the diagnosis twice.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
The request is as defensible as the record of what the agent read. Bring one prior authorization and see, with test values, the page as the model receives it, the approval and the record. Book a demo