Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Is It Safe to Use AI Agents in Revenue Cycle Management?
No, not while the model reads the whole rendered screen, because a claim, denial or remittance page names the patient on every line. The work is governable when the identifiers are replaced with consistent tokens before any model reads it, a named person approves each submission, and the record shows what the model received.
A denials queue is a stack of pages that each name a patient: a claim number, a member identifier, a date of birth, a diagnosis code, an allowed amount and a filing deadline. An agent can open the payer portal, read the denial, check the remittance and draft the appeal in minutes, which is why billing offices are the ones asking whether this is safe. The answer turns on what the model receives when the page renders, and that is a question a buyer can put to any vendor.
Revenue cycle work is claim status, denial management, payment posting and appeals, and every one of those screens is built around identifying the patient and the claim. The tasks need the claim number, the codes and the amounts to be correct, so an agent handed the screen is handed the identifiers in the same pixels. HIPAA governs what the organization may do with protected health information; it does not change what the model saw.
Three things decide the answer, and a billing office can check each before a pilot: whether policy-chosen values on the rendered page are replaced before any model reads it, who approves a posting, a write-off or an appeal, and what record survives the run. The vendor pages reviewed here describe approval in general terms and say little about what a model receives from a screen.
Key findings
- For revenue-cycle work to be safe, the claim number, member identifier and date of birth on a denial or remittance page would have to be replaced with consistent tokens before any model reads the screen, so the agent works from CLM_8841 and MEMBER_2210 while the real values resolve only at the approved destination (What Is Render-Layer Tokenization?).
- It would also require a named person approving each posting, write-off and appeal, with a record of the screen that person was shown, because the approval default the AI Agent Index records is one a user can switch off (AI Agent Index, 2026).
- None of the pages reviewed describes a screen-level substitution for revenue-cycle screens: the vendor pages document posting workspaces, agent access and audit claims, and stop before what the model receives (University of Iowa Health Care, 2026; Duck Creek Technologies, 2026).
- The AgentDAM evaluation reports that web agents "are prone to inadvertent use of unnecessary sensitive information," which on a denial screen means the member identifier and the diagnosis arrive with the claim status (Zharmagambetov et al., 2025).
- Guidewire's Qusar release gives insurers' agents "secure, real-time access to policy, claims, and billing data and workflows," and the announcement says nothing about human approval of an agent action (Guidewire, 2026).
What does an agent read on a denial screen?
The worked record is a denials queue. Each row leads with the patient's name and balance, and opening a row shows the claim number, the member identifier, the patient's date of birth, the dates of service, the diagnosis and procedure codes, the billed and allowed amounts, the denial reason code and the appeal deadline. The task needs the claim number, the reason and the codes; the rest of that screen arrives with them.
Jim Sinkoff, Deputy CEO and CFO, Sun River Health, said on a HAL podcast that the denial carries the lesson: "the provider side can use it to actually understand all the reasons for the denials and use AI to obviate the original reason for the denial" (HAL Transcript: Jim Sinkoff).
An agent that opens the row and drafts the appeal has read the identifiers, and they stay in its context for the rest of the run. The AgentDAM evaluation reports that web agents "are prone to inadvertent use of unnecessary sensitive information," and a denial page is built to supply exactly that (Zharmagambetov et al., 2025). The queue is sorted by money and age, so the agent is pointed at the largest balances, which are the records with the most identifying detail attached.
The minimum necessary standard asks the organization to limit protected health information to what the task requires, and a model that reads the whole denial has not limited anything (Can Staff Use AI on Patient Records Without PHI?). An agent that reads a full patient account to check one claim status is the case that standard was written for (Can an AI Agent Work in Epic Without Holding PHI?).
The queue adds a second exposure. Every row carries a name and a balance, so an agent that scans the queue to triage it reads hundreds of patients to work one claim. Whatever the model is asked to do next, that scan is already in its context.
What do the vendors themselves say?
Vendor pages answer part of the question. Microsoft's SharePoint guidance for agents says they "respect existing permissions," and adds that "By default, SharePoint sets sharing settings to the most permissive option," so an agent inherits an account's reach rather than a task's needs, and permission decides which records the account may open rather than which values the model reads from a record it can open (Microsoft Learn, 2026).
Guidewire says its Qusar Agentic Framework "provides AI agents with secure, real-time access to policy, claims, and billing data and workflows," and the August 3, 2026 announcement names claim summarization and first notice of loss among the agents it ships without saying whether a person must approve an agent's action (Guidewire, 2026). The release also marks availability limits, noting that certain features may be limited by region or early access.
Duck Creek's claims sheet says decisions are "backed by full auditability, so automation is safe, explainable, and governed," which is marketing copy about an audit trail and not a description of approval controls or authority limits (Duck Creek Technologies, 2026). The sheet is undated and names no region or version.
| Dimension | What the page documents | What a buyer should verify |
|---|---|---|
| Access | Microsoft Learn: agents "respect existing permissions," with sharing permissive by default | Whether a permitted account still renders the patient identifier to the model |
| Agent reach | Guidewire: agents with "secure, real-time access to policy, claims, and billing data and workflows" | Whether a posting or an appeal needs a person's approval, and where it is recorded |
| Posting work | University of Iowa Health Care: "back-end payment posting workspaces and workflows" | Which fields the model reads on those screens, and what the confirmation shows |
| Audit | Duck Creek: decisions "backed by full auditability" | Whether the record shows what the model received, not only what changed |
The University of Iowa's payment-posting catalog lists "Posting Guarantor Payments (SBO030)", "Posting Insurance Payments (RHB030)" and "Working Remittance Workqueues (RPB031)", and says the training resources "describe back-end payment posting workspaces and workflows" without a field list, posting rules or error handling (University of Iowa Health Care, 2026). That is the shape of a posting screen from the training side: batches, workqueues and adjustments, with the identifiers as the key to each row.
What does a business associate agreement cover?
HHS lists "claims processing or administration, data analysis, billing, and practice management" among the activities that make a vendor a business associate, so a company reading denials and remittances for a billing office is covered by the rule (HHS Office for Civil Rights, 2026). A covered entity may disclose protected health information to that vendor only after obtaining "satisfactory assurances, in the form of a contract or other written arrangement," which is the agreement a practice signs before a pilot (HHS Office for Civil Rights, 2026).
The same guidance states that "A provider that submits a claim to a health plan and a health plan that assesses and pays the claim are each acting on its own behalf as a covered entity," and it limits the conduit exception to entities that "only provide transmission services for PHI" (HHS Office for Civil Rights, 2026). An agent vendor that reads a denial and drafts an appeal is not a conduit, because it is doing the analysis rather than passing the message. Whether the model vendor needs an agreement is a separate review that turns on the data it handles rather than on the technology (Does an AI Model Vendor Need a BAA for Patient Records?).
What the agreement settles is accountability: who may use the data, what safeguards apply, how a breach is reported. What it does not settle is what the vendor's model receives from a screen. A billing office can hold a signed agreement and still be unable to say whether the model read the member identifier.
The share is not marginal: about 1 in 3 large healthcare breaches came through an outside vendor acting as a business associate in each year from 2023 to 2026, limited to breaches of 500 or more people and on a self-reported flag (How Many Healthcare Breach Victims Were Exposed Through a Vendor?).
Who approves a posting, a write-off or an appeal?
Approval is the second part of the answer, and it varies by action. A posting moves money against a claim, a write-off adjusts the balance the practice expects to collect, and an appeal commits the practice to a clinical position it has to defend while the dispute runs. Each deserves a name rather than a queue.
The AI Agent Index entry for Breeze Agents records that "The default is that approval is required," and adds that users can switch the default off and that automatically triggered agents run without approval (AI Agent Index, 2026). The pattern holds across the category: a default is a setting, and the buyer has to ask what enforces it.
The vendor pages reviewed are quiet here. Guidewire's announcement says nothing about human approval of an agent action, Duck Creek's sheet states no authority limits, and the payment-posting catalog documents workqueues rather than signatures. None of them describes an approver who sees the screen the model read.
The operating record is not reassuring either. In a SailPoint survey of 353 IT professionals, 80% of organizations said agents took unintended actions, about 40% said agents "accessed unintended systems" and 23% said agents revealed credentials (How Do You Test Whether an AI Agent Can Reach Data Outside Its Assigned Task?). An approval step that arrives after an unintended action is a review, not a control.
An approver who sees a queue row is approving an item, not the screen behind it. On an appeal, the person signing commits the practice to a position built from a denial the model read; on a posting, the person releases a payment the model calculated from a remittance it read.
What should a revenue-cycle team ask for in writing?
Four questions in the contract or the security review cover the exposure. First, what does the model receive from a rendered screen: the full denial page, consistent tokens such as MEMBER_2210, or nothing at all. Second, who approves each posting and each appeal, and whether the approval is bound to the screen the model read. Third, what record of the run exists, and where it exports. Fourth, which values the organization can choose to withhold, and by what rule.
The screen question is the one vendors answer least often, and it is the one that decides the rest. A vendor that filters content on the way into the model is offering a defense with a measured failure rate: Nasr and co-authors bypassed 12 published defenses against jailbreaks and prompt injections with an "attack success rate above 90% for most," many of which had reported near-zero rates (Nasr et al., 2025). A filter that inspects a page is not the same control as a page that renders without the value.
Substitution does not cost the work its accuracy. Replacing identifiers with consistent pseudonyms and restoring them after the model has done its work reduces semantic utility errors by a factor of five compared with baseline techniques, which places the loss on inconsistent redaction rather than on substitution itself (Does Masking Data on Screen Break Browser Agents?). An agent that works from MEMBER_2210 and CLM_8841 can still find the claim, because the tokens are stable across the run.
The same question decides the review at scale. A pilot that cannot answer the screen question will not clear the review that scaling requires.
What does a governed environment change?
A governed environment changes what reaches the model, not only what the model may do. Policy-chosen values, the member identifier, the patient's date of birth, the claim number and the diagnosis code among them, are replaced with consistent tokens before any model reads the rendered page, so the agent works from MEMBER_2210, DOB_003 and CLM_8841. Real values resolve only at the approved destination, at the moment of an approved action, and for this record that destination is the payer portal submission or the posting a named person releases.
The record of that run is the second change. Every screen the model read as tokens, every action and every approval with a name is written to a record the organization can export to its own monitoring, rather than a dashboard the vendor keeps.
None of it can be assembled at one layer. Columbia's DAPLab writes that "trustworthy agent automation cannot be solved at a single layer of the stack," and a revenue-cycle task crosses the EHR, the clearinghouse and the payer portal (Columbia University DAPLab, 2026). A study of browsing agents reports findings that "include prompt injection, domain validation bypass, and credential exfiltration," failures of the browser an agent drives rather than of the page a person reads (What Is the Difference Between a Headless Browser and a Protected Browser for AI Agents?).
Nothing in that design asks a billing office to trust it. Render one denial with tokens for the member identifier, the date of birth and the claim number, ask an agent to draft the appeal, and confirm the real values appear only at the submission a billing manager releases.
What the record shows
An RCM agent is only as safe as what reaches its model: the denial or remittance screen is where the patient's identifiers are, so substitution before that read, a named approver for each posting and appeal, and an exported record are the three parts of the answer. The vendor pages reviewed automate posting workqueues, grant agents access to claims and billing data, and claim auditability in marketing terms, and they say nothing about a screen-level substitution or authority limits. The business associate agreement governs the data and not the reading. One denied claim is enough to check it: run the agent on a test copy of a denial with tokenized identifiers, capture the screen the model received, the posting it proposed and the approval, and compare that record with the remittance; if the capture holds a real member identifier, the exposure happened before the approval.
Methodology and limitations
This page rests on vendor documentation from Microsoft, Guidewire and Duck Creek, a university payment-posting catalog, HHS Office for Civil Rights guidance, two research papers, the AI Agent Index and Columbia's DAPLab, and RedactSure research pages. Vendor pages were read between October 16, 2026 and 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, and "not described in the pages reviewed" means the pages listed in Sources. Vendor features change, so the page carries its date. The example describes a record type, a denials queue, and not an organization. RedactSure is deploying now with enterprise and government customers. Whether an agent's reading meets a contractual or regulatory requirement belongs to counsel, assessors and the organization's own compliance officers, and nothing here replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
Is it safe to use AI agents in revenue cycle management?
No, not while the model reads the whole rendered screen. A denial, remittance or patient-account page carries the member identifier and the date of birth next to the claim number, and an agent that reads the page holds all of it for the rest of the run. The work becomes governable when those values are replaced with consistent tokens before any model reads the screen, a named person approves each posting and appeal, and the record shows what the model received. One claim can test the condition.
What does the agent see on a denial screen?
Whatever the portal renders: the patient's name, the member identifier, the date of birth, the dates of service, the diagnosis and procedure codes, the billed and allowed amounts, the denial reason and the appeal deadline. The queue row above it adds a name and a balance for every other patient on the list. Unless those values are replaced before the model reads them, they arrive in context together and stay there for the run.
Does a signed business associate agreement cover what the model reads?
No. The agreement governs how the vendor handles protected health information; it does not describe what the vendor's model receives from a screen. Federal guidance requires written assurances before a covered entity discloses protected health information to a business associate, and a contract can require safeguards without specifying a rendering step. A practice can hold a signed agreement and still be unable to say whether the model read the member identifier.
Who should approve a posting or an appeal?
A named person with authority over the claim, not a queue administrator acting on a default. A posting moves money, a write-off changes the expected balance, and an appeal commits the practice to a clinical position, so the signature belongs to the billing manager or the revenue-cycle lead who owns that account. An approval that a user can switch off, or that fires only above a dollar threshold, is a setting rather than a control. Ask who is named, on which action, and where the signature is recorded.
What record should exist after the agent posts a remittance?
One record that ties the screen the model read, the posting it proposed, the person who approved and the time to the remittance that came back. It should export to the practice's own monitoring rather than stay in a vendor dashboard, and it should show the tokens the model saw beside the values that resolved at the destination. A confirmation number from the payer is a receipt for the transaction, not a record of what the model knew when it proposed the posting.
What should a billing office ask a vendor in writing?
Ask what the model receives from a rendered screen: the full page, consistent tokens such as MEMBER_2210, or nothing. Then ask who approves each action, whether the approval is bound to the screen the model read, and where the record exports. Ask which values the organization can choose to withhold and by what rule. An answer the documentation does not support is unanswered until a test on one claim with no real patient data confirms it.
How RedactSure Keeps Patient Identifiers Off the Revenue-Cycle Screen
A denials queue hands the model the patient's name and date of birth to work a claim number. The adaptive attacks Nasr and co-authors tested reached an attack success rate above 90% for most of the defenses in their sample.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the denial renders the member identifier, the date of birth and the claim number, and the model carries them into the appeal draft. Inside: the page renders as MEMBER_2210, DOB_003 and CLM_8841, the draft is written on those tokens, and real values resolve only at the submission a billing manager approves.
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 denial is where the patient's identity and the money meet, and the screen is where the choice gets made. Bring one denial and see, with test values, what the model reads and who approves the appeal. Book a demo