Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can an AI Agent Post Remittances Without Reading Patient Names?
No, not on the posting screen as it draws today: the agent reads the rendered page, and the claim carries the patient, so the model gets the name. The match needs only the claim number and the amount, so a consistent token in the name's place leaves the posting intact.
The payment posting desk works from a file of claims and a set of payments: the payer says this claim was paid this much, and the clerk puts that amount against the claim the practice already owns. The patient's name is on the page because the page is built for a person who has to know whose claim it is. An agent that works the same page reads what the person reads.
Volume makes the question urgent. A practice that hands posting to an agent is choosing what the model will hold for the length of the run, and whether the record of that run can be handed to an auditor. The claim number and the amount are the keys; the name is a label the page carries beside them. A payment role and a mask on a bank field decide who may act and what part of a value a person sees, and neither decides what the page draws. The posting screen is where the money meets the clinical record, and the agent's view of it is the part the practice cannot audit from the ledger or reconstruct after the run. If the name reaches the model, the run has disclosed who was treated. The ledger is not the record of the reading.
Key findings
- For an agent to post remittances without reading patient names, the patient name on the rendered screen would have to be replaced with a consistent token before any model reads it, so the run works the claim as CLM_8841 and never learns who was treated (What Is Render-Layer Tokenization?).
- It would also require a named person approving each posting run and a record of the screen the model received, because an audit trail has to attribute "every action unambiguously to either an agent or a human actor" (AWS, 2026).
- The posting documentation reviewed describes the fields, the batch summary and the out-of-balance amount, and does not state that a value on the screen is replaced before a model reads it (athenahealth, 2026).
- The athenahealth help page says each charge line starts with "The claim ID number assigned by athenaOne", and the batch summary's Out-of-Balance is "The amount that must be posted to complete the payment batch" (athenahealth, 2026).
- Waystar advertises "automated claim-to-remit matching, payment posting, reconciliation", on an undated page that offers no API or data-field documentation (Waystar, 2026).
- BILL separates the roles that enter bills from the roles that pay them: "The Accountant role can manage the payables processes, but cannot pay bills", and "A Payer cannot enter or approve bills" (BILL, Roles, 2026).
What does the posting screen ask the agent to read?
The record is an ERA posted. A payment arrives for a batch of claims, and the posting screen is where each payment goes against a claim: the charge line, the amount from the EOB, the remit code for the payer's reason, and the batch summary that says how much is still open.
The batch is keyed by the claim: each charge line starts with "The claim ID number assigned by athenaOne", and the payment comes from "the payment column on the EOB" (athenahealth, 2026). The batch summary's Out-of-Balance is "The amount that must be posted to complete the payment batch", and a person closes the batch when that figure reaches zero (athenahealth, 2026).
The claim carries the patient: the claim summary in a clearinghouse guide shows "the patient associated to the claim", and the remittance information lists "the Check/EFT number and the Amount Paid" (Change Healthcare, 2019). The remittance is identified by its check or EFT number and amount, and the patient by the claim, which is why the name is a label rather than a key in the match. A token in the name's place keeps the claim and the amount intact, so the posting proceeds (Can a Browser Agent Fill In a Form Without Seeing the Values?). The control has to cover what the page draws rather than a list of fields (What Is the PII Wall?).
A model reading a rendered page receives every field the page draws, so the posting screen, not the ledger, decides what the agent knows (What Is Render-Layer Tokenization?).
What do the vendors themselves say?
Waystar calls Remit Manager "one platform for all payer payments" and says it will "Track, view, and download 835s from all enrolled payers", on an undated page that offers no API or data-field documentation (Waystar, 2026). The claim is about moving and reconciling files; the page does not say what a model reads when an agent works one.
BILL's role model is the clearest statement of separation: "The Accountant role can manage the payables processes, but cannot pay bills", and "A Payer cannot enter or approve bills" (BILL, Roles, 2026). Its masked view is a partial reveal: a user with Manage Vendor permissions sees "the last four digits of the bank account, and the full routing number", so a mask shows part of a value to a person while a token replaces the value the model receives (BILL, ePayment, 2026).
The athenahealth page documents the batch and the out-of-balance amount for a person working the batch, and its page warns that the service normally posts remittances for the practice, so the manual path is the one it covers (athenahealth, 2026). NetSuite draws the payee, the check number and a "For Electronic Bank Payment" box on a payables form that never mentions matching a payment to an invoice (Oracle NetSuite, 2026).
A step between the screen rendering and a model reading it is not described in the pages reviewed. That absence is the finding.
| Dimension | What the vendor documentation records | What a buyer should verify |
|---|---|---|
| Posting key | "The claim ID number assigned by athenaOne" | Whether the agent gets the claim ID or a token |
| Remit intake | "Track, view, and download 835s from all enrolled payers" | Whether the model reads the 835 body or the totals |
| Who pays | "The Accountant role can manage the payables processes, but cannot pay bills" | Which role the agent runs under |
| Masked value | "the last four digits of the bank account, and the full routing number" | Whether a mask or a token sits before the model |
| Payment form | "For Electronic Bank Payment" | Whether the agent's page and the posting page are one screen |
What happens when an injection reaches a posting agent?
A posting page carries payer-supplied text: a remit code, a denial reason, a note. Any of it can carry an instruction, and the agent has the practice's session and the posting screen in front of it.
The strongest result in the injection literature is narrow: a tool-input "Minimizer" and a tool-output "Sanitizer" form a "simple, modular, and model-agnostic defense operating at the agent-tool interface" that, the authors report, "achieves perfect security with high utility across all four public benchmarks" (Bhagwatkar et al., 2026). The same paper concludes that "existing agentic security benchmarks are easily saturated by a simple approach", so a benchmark win is not evidence about a rendered posting page (Bhagwatkar et al., 2026). The defense sits at the tool interface, and the posting page is drawn in a browser before any tool output is filtered.
Task drift is the measurable version of that failure: "We define this deviation as task drift", where the deviation is from the user's original task under injected instructions (Abdelnabi et al., 2025). An agent sent to post a batch that ends up reading the rest of the claim has drifted, and the drift is measured after the page is in the context.
The useful question is what the injected agent collects. If the page drew CLM_8841 and PAT_2210, the injected run collects tokens, and the practice learns from the record that the agent read a page it should not have (What Can a Hijacked Agent Leak If It Only Has Placeholders?). If the page drew the claim and the patient's name, the same injection collects both.
What should a revenue-cycle team ask for in writing?
The first question is what the model receives from a rendered screen, because that answer does not change when a role, a mask or a confirmation setting changes (Which Enterprise AI Agents Can Work on Screens With PII Today, and What Does Each One Read?). The second is who approves the release, and the third is what record survives the run.
Posting is often a vendor's job, and the breach record shows what is at stake: more than half of the people affected by large healthcare breaches in 2025 and 2026, 123.9 million of 220.0 million, were exposed in breaches that came through a vendor, a business associate under HIPAA (How Many Healthcare Breach Victims Were Exposed Through a Vendor?).
Ask the vendor to name the values the page may draw and the ones it may not. Ask whether the patient name and the member ID are in the second group, and how the page is made to draw a token in their place. Ask what the agent's session can do when the batch will not balance, as in Does an AI Agent Need the Vendor's Routing Number to Schedule a Payment?.
The log has to attribute the action to one actor: "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, 2026). A posting batch leaves a trail of amounts; that trail records the money, not what the model read. A reviewer asking how a posting run was decided needs the screen and the approver beside the amounts.
BILL's role model shows what the approval is not: the accountant maintains the payables and "is not able to manage users or view/manage banking information", while the administrator holds the signing authority (BILL, Roles, 2026). That separation governs who may act, not what the page shows the agent.
What does a governed environment change?
The posting run changes in three places, and none of them is the ledger. For each task the planner proposes what to tokenize, starting from personal information, account numbers, credentials and record numbers. The page draws tokens instead of values: the claim line shows CLM_8841 and the patient shows PAT_2210, with the same surrogate for the same patient across the batch. The agent posts each payment against those tokens and closes the batch on the real out-of-balance amount. The real claim number resolves only at the posting destination, at the moment the approved posting runs, where the ledger needs it (What Is an Approved Destination for AI Agent Output?).
A named person approves each batch before the real values resolve, and the record of the screen, the actions and the approval exports to the practice's own monitoring. That record is what makes a non-zero injection rate survivable: an injected agent working from tokens can collect only tokens, and the record shows what it tried.
The scope has to be stated with the same care. A governed browser environment covers the rendered page the agent works, not the 835 file the posting engine ingests directly, and not the payer's own system on the other side. The condition this page's question turns on is narrow: if the page the agent reads draws a token in place of the patient, the posting proceeds and the model never learns who was treated.
What the record shows
What the agent knows after a posting run is set by the page it read, not by the ledger entry. The batch is keyed by the claim ID and closed on the out-of-balance amount, the patient is a label the claim carries, and the vendor pages reviewed describe those fields without describing a step that keeps the label off the model's side. A mask on one value is not that step: BILL's masked view still shows "the last four digits of the bank account, and the full routing number" (BILL, ePayment, 2026). A practice can test one posting run before it turns the queue over: stage a single ERA, run the agent, and compare the fields the page drew with the fields the run recorded. If the patient name appears in both, the agent read it, and the workflow needs substitution at the screen, a named approver and an exported record.
Methodology and limitations
The page rests on public documentation: help pages for a payment posting batch and an automated remittance platform, a payables role model, a payment form, a claims clearinghouse guide, and the research record on injection defenses and task drift. 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 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. RedactSure is deploying now with enterprise and government customers. Determinations belong to counsel, assessors and the organization's security and compliance officers, and nothing here replaces a pilot of one workflow on the practice's own screens.
Frequently asked questions
Can an AI agent post remittances without reading patient names?
No, not while the screen draws the claim the payment belongs to. The batch is keyed by the claim ID and closed on the out-of-balance amount, and the claim carries the patient, so a model reading the screen reads the name. A role that cannot pay bills, a mask on one field or a confirmation prompt changes what the agent may do. The answer changes when the name is a token the posting system resolves after the agent's work.
What does an agent read on an ERA posting screen?
Every field the page draws. The athenahealth help page lists the payment amount from the EOB, the kick or remit code, a contractual amount the system calculates, and a batch summary with the out-of-balance amount still to post. Each charge line starts with the claim ID. A person reads those fields to know which claim the money belongs to, and a model receives the page as the person does.
Who should approve a posting run the agent prepares?
A named person on the practice's staff, before the payments are released, with the approval attached to the run rather than to the session. athenahealth's page describes the batch and its out-of-balance amount; BILL's role model separates the accountant who manages payables from the administrator who can authorize a payment. Neither approves the agent's own run. The record should name the person, the batch and the amount released.
What record should a posting run leave?
One that shows what the model read and who approved the release, not only what the ledger posted. AWS's agentic guidance asks for logs that attribute every action to one actor, an agent or a human. A posting batch already leaves a trail of amounts and an out-of-balance figure; that trail records the money, and a reviewer asking about the agent needs the screen and the approver beside it.
Does masking the patient name protect the record?
Only partly. A mask hides part of a value from a person reading the screen; BILL's masked bank view shows the last four digits of the account and the full routing number, so the reader still holds most of the number. A consistent token is a different design: the page draws a surrogate the posting system can resolve later, and the model never receives the value behind it. A mask on a field the agent must read still leaves the agent reading the page.
Can the agent post a denial or a secondary claim from the same screen?
A denial can need the member ID and the payer's reason, so the fields the agent has to read grow beyond the claim and the amount. Waystar's page lists a search by payment date and patient number, which is a human search key rather than a description of the auto-match. The workflow has to decide per task which values the page may draw, and a token that stands for the patient keeps the same patient consistent across the run.
How RedactSure Keeps Patient Names Off the Posting Screen
The batch is decided on the claim number and the amount, and the patient's name rides along on the page the agent reads.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the agent opens the batch with the real claim ID, the amount and the patient's name on the page, so the whole screen enters the model's context. Inside the governed environment, the page draws CLM_8841 and PAT_2210, and the real values resolve into the ledger at the approved posting, after a named person approves it.
RedactSure is deploying now with enterprise and government customers. BILL puts signing authority with the administrator and keeps the accountant out of the payment, a separation of people, not of what the screen shows (BILL, Roles, 2026).
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
The posting run is only as defensible as the record of what the agent read. Bring one ERA and see, with test values, the page as the model receives it, the approval and the record. Book a demo