Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do You Protect Health Data When Using AI Agents?

Apply the two HIPAA standards that already exist, minimum necessary and de-identification, to the agent itself: let the model work on a de-identified view of each screen and allow real protected health information only at approved destinations. Check which identifiers your agent sees in the clear, and whether the step it was performing needed any of them.

Health-record fields pass through a layered filter that separates sensitive values from several permitted task outputs.

Apply the two HIPAA standards that already exist, minimum necessary and de-identification, to the agent itself: let the model work on a de-identified view of each screen and allow real protected health information only at approved destinations. Check which identifiers your agent sees in the clear, and whether the step it was performing needed any of them. The regulatory framework for answering this predates the technology by two decades and fits it well. The Privacy Rule's minimum necessary standard asks a covered entity to limit uses and disclosures of protected health information to what the purpose requires. The de-identification standard describes how information can be transformed so that it is no longer protected health information at all. An agent that reads a patient chart to perform a scheduling or billing task is a use of protected health information, and the two standards ask the same question of that use that they ask of any other: how much of the record did this purpose require? This page sets out what a computer-using agent actually sees on a clinical or billing screen, how the two standards apply, where the Security Rule's technical safeguards fit, how the research on screen-reading agents bears on the risk, what a de-identified working view looks like in practice, and how an organization should verify the result.

Key findings

  • HHS guidance describes two methods for satisfying the Privacy Rule's de-identification standard, Expert Determination and Safe Harbor, and either produces information that is no longer protected health information (HHS Office for Civil Rights, 2026).
  • The Privacy Rule's rules on uses and disclosures at 45 CFR 164.502 include the minimum necessary standard, which limits protected health information to what a use or disclosure requires (HHS, 45 CFR 164.502).
  • The Security Rule's technical safeguards at 45 CFR 164.312 require access control, audit controls, integrity protection, authentication and transmission security for electronic protected health information, and an agent process falls inside each (HHS, 45 CFR 164.312).
  • Screenshot-driven GUI agents may inadvertently expose sensitive information such as identities, accounts, locations and behavioral traces, because they perceive the whole rendered screen rather than the fields a task needs (Wang et al., 2026).
  • Agents given privacy-enhancing prompts still leaked sensitive information in 25.68 percent and 38.69 percent of cases for GPT-4 and Llama-3-70B, so instruction is not a safeguard for health data (Shao et al., 2024).
  • Controls that inspect documents and messages in sanctioned applications do not see what a computer-using agent reads from a rendered screen, which leaves a gap on the surface where health data is most often displayed (Does Purview DLP Cover Computer-Using AI Agents?).

What does an agent see on a clinical or billing screen?

Take a patient account screen in a billing system as the worked example. It shows the patient's name, date of birth, medical record number, address and phone number, the insurance member ID, the dates of service, the diagnosis and procedure codes, the billed and allowed amounts, and a notes field. An agent asked to check whether a claim has been paid needs the dates of service, the billed and allowed amounts and the payment status. It needs the medical record number or member ID only as a key, to confirm it is looking at the right account. It does not need the name, the birth date, the address, the phone number or the diagnosis codes for that task.

A computer-using agent does not receive the fields the task needs. It receives the screen, as a screenshot or a rendered page, and every identifier on it enters the model's context. The GUIGuard-Bench study describes the consequence directly: screenshot-driven GUI agents may inadvertently expose sensitive information such as identities, accounts, locations and behavioral traces, because perception is of the whole screen rather than of a selected subset (Wang et al., 2026). In a health setting every one of those categories is protected health information when it is linked to care.

The permissions question makes this worse rather than better. A billing specialist's credentials give access to the full account because the specialist sometimes needs it. An agent working under those credentials inherits the full view for every task, including the many that need a fraction of it. The exposure therefore does not come from the agent exceeding its permissions. It comes from the agent exercising permissions that were sized for a person's whole job rather than for a single step, which is the gap computer-using agents open in every application they read through the screen.

How do minimum necessary and de-identification apply to an agent?

The Privacy Rule's minimum necessary standard, part of the uses and disclosures provisions at 45 CFR 164.502, requires a covered entity to make reasonable efforts to limit protected health information to the minimum necessary to accomplish the intended purpose of a use or disclosure (HHS, 45 CFR 164.502). An agent reading a screen to perform a task is a use. For the payment check above the use required a handful of fields and the agent received the whole screen; the gap between the two is the minimum necessary question, stated for a process rather than a person.

The de-identification standard supplies the mechanism for closing the gap. HHS guidance describes two methods for satisfying it: Expert Determination, in which a qualified expert determines that the risk of re-identification is very small, and Safe Harbor, in which eighteen specified identifier types are removed (HHS Office for Civil Rights, 2026). Information that meets either method is no longer protected health information under the Privacy Rule. The same guidance notes that the covered entity may re-identify the information through a code, provided the code is not derived from the information and the mechanism is not disclosed. That provision is what makes the standard fit an agent. If identifiers on a screen are replaced with codes before the model reads it, and the covered entity retains the mapping from code to identifier, the model is working on a view the entity can treat as de-identified while the entity itself can restore the real values where the task finally needs them. NIST's guidance on de-identifying datasets describes the same family of techniques (NIST, 2023). Whether a given working view meets the standard is for the entity's counsel; the shape of the control is the shape the rule anticipated.

Where do the Security Rule's technical safeguards fit?

Technical safeguard, 45 CFR 164.312 What it requires What a buyer should verify for an agent
Access control Access only for authorized persons or software programs Is the agent's view scoped per task or inherited from the user?
Audit controls Record and examine activity in systems holding ePHI Is every screen read and every action taken recorded?
Integrity Protect ePHI from improper alteration or destruction Do record changes require a person's approval?
Person or entity authentication Verify the identity of whoever seeks access Are the agent's actions attributed to a named person?
Transmission security Guard ePHI in transit Where does screen content travel before the model reads it?

The access control standard at 45 CFR 164.312 names software programs alongside persons, which places an agent within it (HHS, 45 CFR 164.312). Each row of the table is a design question, and the last, where the rendered screen travels, is a question about the model's location.

HHS guidance on cloud computing addresses the last point: a provider that creates, receives, maintains or transmits electronic protected health information on behalf of a covered entity is a business associate and an agreement is required (HHS, 2026). A model provider receiving screens with real identifiers is receiving protected health information; one receiving codes in their place is receiving something counsel may treat differently. Controls built for sanctioned applications, such as Purview DLP, inspect documents and messages and do not see the rendered screen, so they do not answer the access control row.

What does the research say about agents and health information?

Two findings frame the risk. The first is perceptual: computer-use agents see the whole screen. The GUIGuard-Bench authors propose a general evaluation for privacy-preserving GUI agents precisely because the agents they studied may inadvertently expose identities, accounts, locations and behavioral traces that happen to be rendered alongside the task (Wang et al., 2026). The second is behavioral: agents cannot be relied on to withhold what they see. The PrivacyLens benchmark measured leakage of 25.68 percent for GPT-4 agents and 38.69 percent for Llama-3-70B agents even when privacy-enhancing prompts were applied (Shao et al., 2024).

Put together, the findings say that an agent holding a patient's name, birth date and diagnosis in context will, at a measurable rate, use them where the task did not call for them: in a note, a summary, a form field or a message. An instruction to protect patient privacy reduces the rate without closing it. The control that does close it is to prevent the identifiers from reaching the context at all, which returns the question to minimum necessary and de-identification.

The research also bears on a tempting alternative, which is to prohibit agents in health settings. Prohibition has its own documented failure mode: staff use the tools anyway, outside any control, and the organization loses visibility rather than risk. The evidence on whether banning AI tools stops employees using them points toward governing use rather than forbidding it. An organization that governs the agent's view can let the work proceed inside its safeguards.

What does a de-identified working view look like in practice?

Return to the patient account screen. In a de-identified working view the name reads PATIENT_001, the medical record number and member ID read as consistent codes, the birth date is replaced or generalized according to policy, the address and phone number are withheld or tokenized, and the diagnosis codes are tokenized unless the task reads them. The dates of service, the amounts and the payment status remain readable because the payment check reads them. The agent sees a screen it can complete the task from, and the eighteen Safe Harbor identifier types are absent from what the model receives.

Consistency is the property that keeps the task working. If PATIENT_001 on the account screen is also PATIENT_001 on the remittance screen the agent opens next, the agent can confirm the two refer to the same account without knowing who the patient is. If the code changed between screens the task would fail for reasons unrelated to the model. The approach described for protecting sensitive data from agents that navigate screens rests on exactly this run-scoped consistency.

Resolution is the other half. When the task reaches a step that requires a real identifier, such as entering the member ID into a payer portal, the real value appears at that destination at the moment of the approved action and nowhere else. The mapping from code to value is held by the covered entity, which is the arrangement the HHS de-identification guidance contemplates for re-identification. A gateway that filters prompts between an application and a model does not provide this, because it never sees the rendered screen; the distinction is drawn in the comparison of a render-layer design with an AI gateway.

What does a governed environment change?

In a governed environment, the model works on a de-identified view of each clinical or billing screen, so the minimum necessary question is answered by what the model received rather than by what the agent was instructed to ignore.

The mechanism is a class of control that sits between the display and the model. Sensitive values on the rendered screen, names, dates, medical record numbers, account numbers and the other Safe Harbor identifiers, are replaced with consistent tokens before any model reads them, and the task runs on those tokens. Real values resolve only at an approved destination at the moment of an approved action. A named person confirms what is tokenized and approves consequential actions, including record changes and submissions to outside parties. Every screen as the model received it, in token form, every action and every approval is recorded and exported to the organization's own logging.

This bears on the title question because both documented failure modes are about the view. Screenshot-driven agents perceive the whole rendered screen and may expose identities, accounts and locations the task never needed (Wang et al., 2026), and agents given privacy-enhancing prompts still leaked sensitive information in 25.68 percent and 38.69 percent of cases (Shao et al., 2024). The environment removes the identifiers from the view rather than asking the model to disregard them, and its record supplies the three verification points above.

The control does not change the EHR or billing system, staff permissions or the model, and it does not make the determination; whether the working view meets the de-identification standard and satisfies minimum necessary remains a decision for counsel and the privacy officer, made on the evidence the record provides.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. Its design is the de-identified working view described above, applied at the point where the agent perceives. The agent runs inside a governed environment in the customer's cloud, and substitution happens at the render layer, before any model reads the screen, so the patient's name, birth date, contact details and codes reach the model as consistent tokens such as PATIENT_001 for the whole run, while the dates and amounts the task reads stay readable. Real values resolve only at approved destinations at the moment of an approved action, such as a member ID entered into a payer portal. A named person confirms the tokenization policy and approves every payment, submission and record change under Supervised Delegation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM, which answers the audit controls question with a record of what the model saw. The design is model agnostic, needs no per-application integration, and leaves user permissions unchanged.

Deployments are in pilot. A pilot on the reader's own billing or scheduling workflow would show each screen as the model received it and which identifiers, if any, ever appeared in the clear. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on the text of the HIPAA Privacy Rule at 45 CFR 164.502 and the Security Rule's technical safeguards at 45 CFR 164.312, on HHS Office for Civil Rights guidance on de-identification methods and on cloud computing, on NIST SP 800-188 on de-identification techniques and governance, on peer-reviewed research and preprints measuring privacy exposure by GUI agents and language model agents, and on earlier RedactSure research pages on computer-using agents, DLP coverage, bans on AI tools, screen navigation and gateways. All sources were read as of October 16, 2026. Quantitative figures are the cited papers' own reported results and are not extrapolated.

No hands-on testing of any agent, model or product was performed for this page, and no determination is made that any working view meets the de-identification standard or that any arrangement satisfies the minimum necessary standard. Where a vendor capability is mentioned, the description is confined to the pages reviewed; what is not described there should be read as not described, not as absent. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The patient account screen, remittance screen and payer portal used as examples describe record types, not any organization; no covered entity, business associate or patient is described.

Whether a given agent deployment, working view or model arrangement meets the Privacy Rule, the Security Rule or a state health privacy law is a determination for the organization's counsel, its privacy and security officers and its assessors, not for a research page.

What the record shows

Health data protection for agents does not need a new framework; it needs the existing one applied to a new kind of user. The minimum necessary standard asks how much of the record a use required, and a computer-using agent that receives the whole screen for a task that reads five fields answers that question badly. The de-identification standard, with its provision for re-identification by the covered entity through a retained code, describes the control that closes the gap: identifiers replaced with consistent codes before the model reads, real values restored only where the task finally needs them. The research adds urgency, since screen-reading agents expose what they see and leak at measurable rates even when instructed not to. RedactSure's design applies the substitution at the render layer. The test is to name one agent and one task and ask which identifiers on the screen the step actually read, and which the model received anyway.

Frequently asked questions

Does an AI agent reading a patient chart count as a use of protected health information?

Yes, in the ordinary sense of the Privacy Rule. A use is the sharing, employment, application or examination of protected health information within the entity that holds it, and an agent that reads a chart to perform a task is examining it. The minimum necessary standard therefore applies, and the question becomes how much of the chart the task required. Whether a particular arrangement satisfies the standard is for the entity's counsel to determine.

Can a model work on de-identified data and still complete a billing task?

Usually, because billing tasks read dates, amounts, codes and statuses rather than identities. The identifiers on the screen serve as keys that let the agent recognize the same account across screens, and a consistent code performs that role. When a step requires a real identifier, such as entering a member ID into a payer portal, the value is restored at that destination. The task that fails under de-identification is one whose policy masked content the step needed to read.

Is a model provider a business associate if it receives screens from a clinical system?

HHS guidance on cloud computing states that a provider that creates, receives, maintains or transmits electronic protected health information on behalf of a covered entity is a business associate and requires an agreement. A provider receiving screens with real identifiers is receiving protected health information. Whether a provider receiving screens with identifiers replaced by codes is in the same position is a question for counsel, and the design determines whether it can be asked.

Does instructing the agent to protect patient privacy satisfy the Security Rule?

No. The Security Rule's technical safeguards require access control, audit controls, integrity protection, authentication and transmission security as implemented mechanisms, not as requests to a system. Research measured agents leaking sensitive information in 25.68 and 38.69 percent of cases under privacy-enhancing prompts, which shows that an instruction has a failure rate. Mechanisms that limit what the model receives and record what it did are the kind of control the rule describes.

Why not simply prohibit AI agents in health settings?

Prohibition removes visibility rather than risk. Research on bans of AI tools finds that staff continue to use them outside sanctioned channels, where no control applies and no record exists. An organization that governs the agent's view, records its actions and requires approval for changes keeps the work inside its safeguards. One that bans the agent may find the same work done in a personal account with nothing logged.

What should the audit record contain for an agent that handles health data?

Every screen as the model received it, every action the agent took, and every approval that preceded a record change or an external submission, attributed to a named person. The Security Rule's audit controls standard asks for mechanisms that record and examine activity in systems containing electronic protected health information, and for an agent the activity includes reading as well as writing. A record that shows only the changes made omits the part of the activity where the exposure occurs.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.