Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can an AI Agent Work in an EHR Without a Business Associate Agreement?
No, not when the agent reads the chart, because the model vendor then creates, receives, maintains or transmits PHI and becomes a business associate that needs a written agreement. Check what reaches the model from the rendered screen, and where the token mapping lives, before you accept a vendor's assurance.
A revenue-cycle lead who automates one task in an electronic health record signs two things at once. One is a contract with the vendor whose agent clicks through the chart. The other is a bet that the model behind that agent never receives the patient identifiers the chart prints, because a model vendor that receives them is a business associate, the same as a billing service or a clearinghouse, and the arrangement that makes the disclosure lawful is the agreement the title names. Neither a security questionnaire nor a setting that limits which sites the agent can open answers that bet, because both act on where the agent goes. What answers it is what the model receives from the rendered screen, which is a design question about the page rather than about the model. The record here is a chart rendered as placeholders, a patient banner whose name, medical record number and date of birth are replaced with stable tokens such as PATIENT_014 and MRN_0022 while the task fields stay readable. Two people carry the cost of getting it wrong: the compliance officer who has to answer for a disclosure nobody wrote down, and the patient whose diagnosis sits in a transcript. An explainer on agentic AI defines the class as "autonomous software systems that perceive, reason, and act in digital environments to achieve goals on behalf of human principals", and the perceiving half is the half this question turns on (MIT Sloan, 2026).
Key findings
- For an agent to work a chart without the model vendor becoming a business associate, the values on the rendered chart would have to be replaced with consistent tokens before any model reads it, so the model works on PATIENT_014 and MRN_0022 while the identifiers stay in the record (What Is Render-Layer Tokenization?).
- It would also require a named person approving each record change the agent proposes and a record of what the model received, because the written arrangement that permits a disclosure sets what the vendor may do with the chart (Does an AI Model Vendor Need a BAA for Patient Records?).
- The gap sits at the screen: the guidance describes the contracting duty and the vendor pages describe how far an agent reaches, and none of the pages reviewed describes a chart whose identifiers are replaced before the model reads it (Can an AI Agent Work in Epic Without Holding PHI?).
- HHS draws the line at whose work it is: "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 an agent vendor reading the chart for the practice is on the other side of that line (HHS, Business Associates, 2026).
- An evaluation of autonomous web agents found that they "are prone to inadvertent use of unnecessary sensitive information", which is what a chart screen invites when it prints a diagnosis beside a balance (Zharmagambetov et al., 2025).
- A benchmark of visual PII detection for computer-use agents reports a model "more than doubling text-extraction baseline accuracy (0.753 vs 0.357 mAP@50)" on rendered web pages, so finding the values on a screen is a measured task rather than an assumption (Zhao, 2026).
What does an agent read when it opens a chart?
The chart is not one page. An EHR draws a patient banner at the top of every screen, and the banner carries the name, the medical record number, the date of birth, the age and the insurer. The encounter below adds the problem list, the medication list, the results and the note the last clinician signed. A narrow task, such as posting a payment, sits inside that frame, because the agent has to find the account before it can post.
That frame is what the agent reads, and the agent does not choose to read the diagnosis: the banner sits above the field it needs, and the model receives whatever the page renders. Web agents are "prone to inadvertent use of unnecessary sensitive information", which is what a chart screen invites (Zharmagambetov et al., 2025). The fields that identify a patient sit beside the fields that carry the task.
Minimum necessary speaks to it. The Privacy Rule requires a covered entity to "make reasonable efforts to limit protected health information to the minimum necessary to accomplish the intended purpose of the use, disclosure, or request", and a screen that prints the whole chart for a payment post does not do that (Cornell Law School, 2026). The standard names no screen and no model, and whether a design satisfies it belongs to counsel.
A date of birth is the clearest case. The de-identification guidance removes "All elements of dates (except year) for dates that are directly related to an individual" under Safe Harbor, so the full date in a banner is an identifier (HHS, De-identification, 2026). The payment post needs the account and the amount.
| What the banner or chart draws | What a payment post needs | What the model receives without a control |
|---|---|---|
| Patient name | The account it is posting to | The legal name as the record holds it |
| Medical record number | A key to find the account | The identifier, unchanged |
| Date of birth | Nothing | The full date |
| Diagnosis and note | Nothing | The problem list and the note text |
| Balance and guarantor | The amount | The amount with the guarantor's details |
A chart rendered as placeholders gives the agent the same task. The banner draws PATIENT_014 and MRN_0022, the balance stays a figure, and the diagnosis renders as DX_001, so the agent posts the payment while the model holds tokens that mean nothing outside the environment (Can an AI Agent Work in Epic Without Holding PHI?). Form fields are documented the same way (Can a Browser Agent Fill In a Form Without Seeing the Values?).
Does reading the chart make the vendor a business associate?
Start with the definition: a business associate is an entity that creates, receives, maintains or transmits PHI for a covered entity, and the guidance lists "claims processing or administration, data analysis, billing, and practice management" among the activities that make one (HHS, Business Associates, 2026). An agent vendor reading a chart on a practice's behalf is in that list by function, and the model vendor behind the agent receives the same fields at the model call.
The guidance requires "satisfactory assurances, in the form of a contract or other written arrangement" before a covered entity may disclose PHI to that entity, and it narrows the conduit exception: entities that "access PHI on a regular or frequent basis to perform a service on behalf of a covered entity are not conduits" (HHS, Business Associates, 2026). An agent that opens a chart every day is not passing a message along.
Whose work it is matters as much as what is read. A provider's own biller working the chart is acting on the provider's own behalf; a vendor's agent reading the chart for the practice is not, and the difference is who the work belongs to rather than which buttons are pressed. A security questionnaire, a SOC 2 report and an encryption commitment describe how a vendor protects data it already holds. None of them changes what the vendor receives.
Large healthcare breaches that came through a vendor acting as a business associate affected 123.9 million people in 2025 and 2026, 56.3% of the 220.0 million people affected by large breaches in those two years (How Many Healthcare Breach Victims Were Exposed Through a Vendor?).
Whether PHI reaches the vendor is the test, and that answer sits on the screen the agent reads. A vendor that holds every certificate in the industry still needs the written arrangement unless the values on the chart are replaced before the model reads them.
What changes when the screen shows tokens instead of the chart?
The control that changes the answer sits at the render layer. Values chosen by policy are replaced with consistent tokens before any model reads the page, so the banner draws PATIENT_014 and DX_001 for the whole run, and the real values resolve only at an approved destination, at the moment of an approved action. The agent still finds the account and posts the payment, because it works on the token as it would work on the name (What Is Render-Layer Tokenization?).
For the agreement question, the effect is on what the vendor receives. A model vendor that never receives the identifiers, and never holds the key that resolves them, is not receiving PHI in that flow (Does an AI Model Vendor Need a BAA for Patient Records?). The qualification is where the mapping lives: an environment that holds the key and resolves values on request is handling PHI, so the party that operates it belongs in the same analysis as the model vendor.
A token is not de-identification. The Privacy Rule offers Expert Determination, where a person "determines that the risk is very small", and Safe Harbor, which removes a list of identifiers, and the guidance warns that both methods "yield de-identified data that retains some risk of identification" (HHS, De-identification, 2026). A consistent token stands in for a value inside one environment; it does not turn a chart into a de-identified data set.
Detection on a rendered page is a measured task, which is what makes a policy that names the fields enforceable (How Do You Run Claude Computer Use on Customer Records Without Exposing PII?).
What do the vendors themselves say?
1Password's post on browser agents states that "the AI agent and underlying LLM never need to see nor handle the credentials", with a value injected "if, and only if, the human approves the access", a design for credentials rather than for the chart a clinician reads (1Password, 2025). The shape is the one a chart control would take, and the page is about a password rather than about a diagnosis.
SAP's innovation guide states that "Joule Agents can access enterprise data and act across both SAP and third-party systems", which describes how far an agent reaches and not what its model reads or what agreement covers it (SAP, 2026). Reach is what makes an agent useful in a revenue-cycle workflow, and the sentence leaves this page's question open.
Dia's security page states that "Dia should not be used for work that involves PHI or other data you're obligated to protect under a law like HIPAA", which is a vendor answering the agreement question by excluding the work (The Browser Company, 2026). A browser that tells users to keep PHI out of it has decided not to sign the arrangement, and the decision is at least stated.
| Vendor | What its page states | What the page leaves open |
|---|---|---|
| 1Password | The model never needs to see or handle the credential, injected only on a human approval | What a model receives from a chart page, which is not a credential |
| SAP | Joule agents reach enterprise data across SAP and third-party systems | What the model reads on a screen and which agreement covers it |
| Dia | The browser should not be used for work involving PHI | An arrangement that would let the browser be used for that work |
None of the three describes a chart whose identifiers are replaced before the model reads it; the pages cover credential custody and reach, and that screen is not described in the pages reviewed.
What should a covered entity ask for in writing?
Five questions turn the vendor conversation into something a compliance officer can file.
- What the model receives from the rendered chart, field by field.
- Whether the vendor will sign a business associate agreement, and whether the model provider is a party to it. The content requirements for the written arrangement sit at 45 CFR 164.504(e), the clause counsel reads against the model provider's role (HHS, Business Associates, 2026).
- Where the token mapping lives, and who can resolve a token back to a value. A mapping the vendor holds is PHI under another name.
- Who approves each record change, and whether the approval names the person.
- What record shows what the model received, and whether it exports to the organization's own monitoring.
The first question is the one vendors answer least often, because it asks about a page rather than a policy. OWASP's entry for sensitive information disclosure states that "Personal identifiable information (PII) may be disclosed during interactions with the LLM", which is the disclosure a chart-reading agent puts in front of a model on every run (OWASP, 2025).
McKinsey's State of AI research finds 62 percent of organizations at least experimenting with AI agents and 23 percent scaling them anywhere, and the gap between those two numbers is where most agent programs sit (What Is the PII Wall?).
Two checks belong on the list because a demo will not show them. Ask for the screen the agent reads on a patient portal rather than the screen built for the sale (Can Healthcare Staff Use Gemini in Chrome on Patient Portals?), and ask what the agent does when the chart opens on a different patient than the task named (ChatGPT Atlas, discontinued in August 2026).
What does a governed environment change?
A governed environment acts where the page is drawn, before any model reads it. The values a policy names are replaced with consistent tokens for the whole run, so the chart renders PATIENT_014, MRN_0022 and DX_001 while the amount and the task fields stay readable. Real values resolve only at an approved destination, at the moment of an approved action, and the payment post is such an action. A named person approves each record change and each submission, and every screen the model was shown, every action and every approval lands in a record that exports to the organization's own monitoring.
For this page's question, the control changes two things an agreement cannot. The first is what the vendor receives: a model vendor that reads tokens and never holds the mapping is not receiving PHI in that flow (Does an AI Model Vendor Need a BAA for Patient Records?). The second is the record: an agreement says what a vendor may do, and a record says what the model actually received on each screen.
The control does not remove the agreement. A covered entity still owes its own duties under the Privacy Rule, the environment operator is a party to the analysis if it holds the mapping, and the determination belongs to counsel. What it removes is the part of the exposure no contract can reach: the identifiers a model would otherwise hold in a transcript, a summary or a later page.
Its scope is the rendered page. An agent that reaches the record through a direct API call is a different design with a different analysis.
Rishov Chatterjee, AI engineer at Curology and former Director of Data Science and AI at Integra Connect, said on a HAL podcast that the API route is part of how modern EHRs work: "even with a lot of like modern EHR systems these days, they also use APIs, right?" (HAL Transcript: Rishov Chatterjee).
What the record shows
Whether an agreement is required turns on what the model receives from the rendered chart, and not on which model reads it. A screen that draws PATIENT_014 and DX_001 leaves the vendor receiving tokens; a screen that prints the chart as the record holds it makes the vendor a business associate, whatever its questionnaire says, and the token mapping decides the middle case. A compliance officer can test this in an afternoon: name one chart screen and one task, capture the page the model is shown, list every field on it, and mark the ones the task does not need. Then ask the vendor which of those fields its model sees.
Methodology and limitations
This page rests on HIPAA guidance from the Office for Civil Rights on business associates and de-identification, the Privacy Rule text as republished by the Legal Information Institute, OWASP's entry on sensitive information disclosure, two studies of web agents, three vendor pages and existing RedactSure research pages. Public documentation read in full gives a sound view of where each product applies its control. Vendor pages were read between October 16, 2026 and October 23, 2026, and each Sources line carries the date for its page.
No product on this page was tested for this page. Where the page says a behavior is not described in the pages reviewed, the recorded facts do not cover it. Vendor features change, and a release after the page's date is unreviewed. RedactSure is deploying now with enterprise and government customers. The example describes a record type, a chart rendered as placeholders, and not an organization. Determinations about whether a 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 on the organization's own screens.
Frequently asked questions
Can an AI agent work in an EHR without a business associate agreement?
No, not when the agent reads the chart. The model receives the patient banner and the note, and a vendor that receives PHI for a covered entity is a business associate that needs a written arrangement. The answer changes only when the identifiers never reach the model and the vendor holds no key that resolves them. A practice that has not settled where the mapping lives has not settled the question, whatever the vendor's security page says.
Is the agent vendor's agreement enough to cover the model provider?
Only where the model provider is a party to it. The model provider is a separate entity that receives the chart at the model call, and the content requirements for the written arrangement sit at 45 CFR 164.504(e). Counsel reads the vendor's contract against that role. The shape to ask for is a chain in which each party that receives the chart is covered, not a single agreement with the reseller and a promise about the rest.
What record shows what the model read?
Usually none, unless the arrangement requires one. The vendor pages reviewed describe what an agent can reach and how a credential is kept from it, and they do not describe a per-screen record of what the model received. A covered entity that wants one has to ask for it in the agreement and check that it exports to its own monitoring. Without that, the answer to a patient's question rests on the vendor's summary.
Who approves the agent's record changes?
A named person, if the design has one. The approval is what separates an agent that proposes a change from an agent that makes one, and it matters more in an EHR because the change lands in a clinical record. Ask whether the approval names the person, what that person sees before approving, and whether a rejected change is recorded. A role account that approves its own work is not an approval.
Is a token on the screen enough to take the vendor out of the agreement?
Only where the vendor never receives the value and never holds the key. A token the vendor's own environment resolves is a pointer to PHI, and the party that can resolve it is handling PHI. The design question is where the mapping lives and who can read it. A token that changes from page to page also breaks the agent's work, so the substitution has to be consistent to be useful.
What should a covered entity ask a vendor about what the model receives?
Start with the screen: ask for the rendered chart as the model sees it, field by field, and for the list of fields the task does not need. Then ask whether the model provider is covered by the agreement, where the token mapping lives, who approves each record change, and what record of the page exists. Ask the same questions about the portal and claim screens the agent touches after the chart.
How RedactSure Keeps a Chart's Identifiers Out of the Model
An agent that reads a chart to post a payment receives the patient banner before it reaches the amount. OCR counts billing and claims processing among the work that makes a vendor a business associate.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the model reads the banner, the problem list and the note, and holds them for the rest of the run. Inside the governed environment: the banner renders PATIENT_014, the diagnosis renders DX_001, the amount stays readable, and a named person approves the post.
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 chart that prints a patient's name and diagnosis puts both in every summary the model writes. Bring one chart task your team runs and see, with test values, what the model reads and where the real values resolve. Book a demo