In short, healthcare is adopting AI agents faster than almost any other industry. More than 85% of Epic’s customers already use Epic AI, Epic’s Agent Factory will let every health system build agents of its own from 2027, and 43% of health systems were piloting agentic AI at the start of this year. Every one of those agents runs next to Protected Health Information (PHI), and PHI comes with rules that were not written for autonomous software but land on it anyway: minimum necessary access, audit controls, business associate agreements, a 60-day breach clock. This post maps those rules onto what agent infrastructure must provide (identity, per-request authorization, live inventory, an audit trail across every hop), then shows where Tigera Lynx fits and what it does not do. It is written for the platform and security leaders who will be asked to produce the record.
Healthcare was supposed to be the cautious one. Regulated to the bone, allergic to unvetted vendors, still running a fax machine somewhere in the basement. Instead, it is adopting AI agents faster than almost anyone.
At HIMSS in March 2026, Epic previewed Agent Factory, a visual builder for health systems to create, customize, and orchestrate their own AI agents inside the Electronic Health Record (EHR), and said that more than 85% of its customers are already actively using Epic AI. By its August user group meeting, four health systems were building agents in it without writing code. A month later, 25 health systems spent three days building clinical ones: an agent that reads NICU notes for early signs of necrotizing enterocolitis, another that checks medication refill requests against clinical protocol. Training for the first early adopters starts in October, and general availability is planned for 2027. Oracle’s Clinical AI Agent drafts notes and proposes next steps for physicians across more than 30 specialties, and in September it reached inpatient nurses. And underneath the vendor roadmaps sits a quieter layer: internal teams wiring LangGraph agents and MCP servers to FHIR APIs, because the pilot worked and the backlog is long.
The numbers behind that are worth holding in your head. Research from Microsoft and The Health Management Academy, published in early 2026, found that only 3% of health systems had agents in live workflows, while 43% were piloting or testing them. That is the shape of a wave a year before it breaks. The same study named governance as one of the three barriers health system leaders say they have not solved. Gravitee’s State of AI Agent Security survey, a vendor survey from February, found that 92.7% of healthcare respondents had seen a confirmed or suspected AI agent incident in the previous year, the highest share of any sector it asked.
None of this is recklessness, and it deserves better than a scolding. A scribe agent that gives a clinician two hours of their evening back is one of the clearest AI wins in any industry. The adoption is rational.
But every one of those agents runs next to PHI, which comes with rules that are older than the transformer, attach to the data rather than the technology reading it, and are about to get sharper, not softer.
Does HIPAA apply to AI agents?
Yes, fully, and without an AI chapter. HIPAA does not need one. The Privacy and Security Rules regulate covered entities and their business associates, and they attach to the data, so an agent reading a chart is governed exactly as a clinician reading a chart is. Four existing requirements land directly on agents:
Minimum necessary. 45 CFR 164.502(b) limits PHI access to what a specific task needs. A human scheduler looking up an address sees a demographics screen. An agent doing the same job through a service account that can read the full clinical record is a minimum necessary problem, whether or not it ever reads past the address field. Agents do not get scoped down by the login screen. They get exactly the credentials someone gave them.
Audit controls. 45 CFR 164.312(b) requires mechanisms that record activity in systems holding electronic PHI (ePHI): who accessed what, when, and on whose authority. EHR audit logs answer this for humans, because a human is logged in. An agent is not a user. It acts on behalf of a user, through credentials of its own, often through a chain: a patient asks an agent, the agent calls another agent, that one calls an MCP tool, the tool queries the record, and somewhere a language model sees the result. “Who” is now a chain, not a name, and the audit trail has to hold the whole chain.
Business associates. Any vendor that processes PHI on your behalf needs a Business Associate Agreement (BAA). Every LLM provider your agents can reach is on that list. If one team’s agent carries an API key for a provider you have no agreement with, its plumbing has quietly created a compliance exposure nobody signed off on.
Breach notification. When PHI goes somewhere it should not, the Breach Notification Rule starts a 60-day clock, and the first question is scope: what data, which patients, over what window. You cannot report what you cannot reconstruct. And the bill for getting this wrong is highest here of anywhere: IBM’s 2026 Cost of a Data Breach report puts the average healthcare breach at $6.64 million, the costliest industry for the thirteenth year running.
If the clock sounds theoretical, Australia just lived through the version without PHI in it. On 18 June, an OpenAI agent under internal evaluation found its way around the access blocks on a Services Australia portal that holds Medicare statistics and read non-public files. OpenAI discovered the intrusion on 11 August, told Services Australia on 10 September by emailing a public inbox, and the Prime Minister announced it on 24 September, calling both the delay and the manner “unacceptable”. No patient records were touched. Everything else about the story was the pattern: an agent that, in the Prime Minister’s words, did not accept no for an answer, and an operator that took two months to notice and another month to say so. OpenAI has since apologised, and after a further incident it paused training, evaluation, and tool-use inference on its most capable models. Put PHI in that story and the 60-day clock would have started in June, on the day the intrusion should reasonably have been known, not in August when someone noticed.
One agent makes each of these a manageable exercise in process. Ten agents make it a spreadsheet nobody enjoys maintaining. A hundred agents, some built in a vendor’s visual builder, some homegrown, some a resident’s experiment that never got decommissioned, make it impossible to do by hand. That is not a prediction about a distant future. Agent Factory’s entire pitch is that your departments will build their own.
How is the HIPAA Security Rule changing for AI?
The rule is not changing for AI specifically, but it is tightening in exactly the places agents stress. In January 2025, HHS proposed the first major rewrite of the Security Rule in over a decade. The final rule has slipped: OMB’s regulatory agenda now targets July 2027, nearly 5,000 comments are still under review, and hospital groups, including the American Hospital Association, have asked for the proposal to be withdrawn. Proposals change before they land. The direction will not. Three items in the proposal read as if they were written with agent fleets in mind:
- A technology asset inventory and a network map showing how ePHI moves through your systems, reviewed at least annually. Every agent, every MCP server, every LLM endpoint is an asset on that map. A map drawn by interviewing teams is stale before the ink dries. Agents get built in an afternoon.
- Mandatory, auditable controls in place of “addressable” ones: encryption, multi-factor authentication, segmentation. The era of arguing that a control was not reasonable for your environment is closing.
- Annual written certification from business associates that safeguards are actually deployed. Your vendors will be certifying to you, and your auditors will expect you to know which vendors sit in the data path at all.
Nobody is waiting for the rule, either. The Office for Civil Rights (OCR) is enforcing the current rule’s risk analysis requirement hard, through a Risk Analysis Initiative that passed its fourteenth settlement in June, and a risk analysis is only as good as the inventory it starts from. The Ambry Genetics settlement in September is worth reading with agents in mind: besides the missing risk analysis, OCR faulted the company for never assigning unique IDs to track who touched ePHI. That was a finding against a workforce of humans. A fleet of agents sharing one service account fails the same test, for the same reason.
HHS ran a request for information on accelerating AI in clinical care over the winter and reported in June that what the sector asked for most was practical guidance on governing AI and tools to evaluate what vendors sell. It says the answers will shape how it regulates, reimburses, and funds AI in the clinic. States are moving faster. California’s legislature sent the governor AB 1979 in September, which would require any company whose AI health application reaches medical records, consumer chatbots included, to comply with the state’s medical confidentiality law, and the governor had until 30 September to act on it.
Whichever year the final rule takes effect, the gap between “we have a policy document” and “here is the map, and here is the log” is exactly where findings live.
What does HIPAA compliance require of AI agent infrastructure?
Put the current rule and the proposed one side by side, then translate each requirement into what it means once agents are in the data path:
| The rule asks | With agents, that means | So the infrastructure must provide |
| Minimum necessary access (164.502(b)) | An agent touches only the PHI its current task needs, not everything its credentials allow | Per-request authorization with default deny, not standing access |
| Audit controls (164.312(b)) | Every access attributed to a specific agent, acting for a specific person, through a specific tool and model | An identity-attributed audit trail across every hop, not just the EHR login |
| Asset inventory and ePHI network map (proposed) | Every agent, MCP server, and LLM provider is on the map, including the ones nobody registered | Continuous discovery of agents, not an annual questionnaire |
| BAA coverage for vendors in the data path | Agents can reach only the LLM providers you actually have agreements with | Central control over provider access, with credentials held outside the agent |
| Breach notification within 60 days | Scope a suspected leak: which agent, what data, which direction, what window | A reconstructable record of agent traffic with policy decisions attached |
Read column three again. Nothing in it is paperwork. Identity, authorization, discovery, audit: every row is infrastructure, and none of it can be delegated to the agent itself, because controls the agent can override are not controls. We have made that argument all year, from the accountability crisis through why network policies, API gateways, and RBAC cannot close the gap. Healthcare is where it stops being an argument and becomes an audit finding.
Notice, too, what the table does not contain. It does not ask the model to behave. Prompt injection is unsolved, and an agent that has been talked into exporting a patient list will do so with perfectly valid credentials. The five pillars of AI agent accountability we published earlier this year (traceability, authorization provenance, identity and ownership, policy at scale, human oversight) were written for any regulated industry. Lay them over that table and each pillar answers one or two rows. HIPAA just happens to have written the pillars into law before anyone called them that.
Where does Tigera Lynx fit?
This is the gap Tigera Lynx was built to close, and it maps onto that table almost row for row.
Every agent, MCP server, and LLM provider registers with Lynx and carries a verifiable identity (SPIFFE, OIDC, or a pod-owner binding for agents you cannot modify), including who the agent is acting for, so “which agent, on whose behalf” is a fact attached to every request rather than a forensic project after the incident. Authorization runs through Cedar policy at the gateway: default deny, evaluated on every request, with the caller’s identity, the target, and the operation as context. For MCP traffic the policy can see the operation, the tool name, and the tool arguments, so “this agent may call lookup_appointment but never export_patient_list” is one policy statement, and a call a policy marks as requiring human approval waits until a person signs off. That is minimum necessary expressed as executable policy instead of a training slide.
LLM provider credentials are injected at the gateway and never live inside the agent, which means the set of providers your agents can reach is exactly the set you have BAAs with, and a prompt-injected agent has no key to leak. Each token the gateway mints is addressed to one destination, so a token stolen from one hop is worthless at the next.
Agents that never registered, the experiment nobody decommissioned or the sidecar nobody audited, are detected from the node itself. An eBPF detector watches for connections to LLM endpoints, including a watchlist of your own self-hosted model endpoints, and inspects running processes for agent frameworks, then classifies each workload as sanctioned, shadow, or unknown with the evidence shown beside the verdict. That is the difference between an asset inventory you assert and one you can defend. A workload that should not be there can be quarantined on the spot, at the gateway and in the kernel, so it can no longer write to disk, launch processes, or open an outbound connection. The same detector now ships as a package for plain Linux hosts, because not every agent in a health system runs on Kubernetes.
And every request lands in the Agent Trail with the caller, the human authority, the tool, the policy decision, the token exchanged at each hop, and the model that actually served the call: your 164.312(b) mechanism and your breach-scoping record in one place, written by the enforcement plane rather than narrated by the agent.
To be precise about the claim: no software makes you HIPAA compliant, Lynx included. Compliance is contracts, risk analysis, process, and training, and the BAA with your LLM provider is a document your legal team signs, not a policy the gateway enforces. What Lynx provides is the layer those processes quietly assume exists: the ability to say, with evidence, which agents exist, what each one can touch, and what each one did.
Frequently asked questions
- Are AI agents subject to HIPAA? Yes. HIPAA attaches to PHI and to the covered entities and business associates that handle it, not to the technology in between. An agent that reads, creates, or transmits PHI is bound by the same minimum necessary, audit control, and breach notification requirements as any workforce member or system.
- Is my LLM provider a HIPAA business associate? If PHI reaches it, yes, and you need a BAA before it does. Most major providers offer one on specific enterprise tiers, and de-identified data falls outside the rule. Signing the BAA is the easy part. The engineering problem is guaranteeing that no agent can reach a provider you have not signed one with, and that is a routing and credential control rather than paperwork.
- Can an AI agent be “HIPAA compliant”? Not on its own. Compliance is a property of the organization and its processes. What you can make an agent is governable: it has a verified identity, its access is scoped per request, its traffic is logged with attribution, and it can be stopped. That is what an auditor can check.
- What does an AI agent audit trail need to contain? For every access to ePHI: which agent, acting on whose behalf, through which tool or API, against which policy decision, at what time, and which model saw the result. A log the agent writes about itself does not count. The record has to come from an enforcement point the agent cannot edit.
- What is the minimum necessary standard for AI agents? An agent should be able to reach only the PHI its current task requires, evaluated at the time of the request. Standing access through a broad service account violates the spirit of the standard even when the agent behaves, because the exposure exists whether or not it is exercised.
- Does the proposed HIPAA Security Rule apply to AI agents? It does not mention them, but its asset inventory, network map, mandatory encryption and MFA, and business associate verification requirements apply to every system that touches ePHI. Agents, MCP servers, and LLM endpoints are systems. The final rule is now expected in 2027 and may change, but the current rule’s risk analysis requirement, which OCR is actively enforcing, already needs a complete inventory to satisfy.
The auditor’s question
The vendors will keep shipping agents, and clinicians will keep adopting anything that gives them their evenings back. The industry conversation has already moved from “should we deploy agents” to “how do we validate and govern them.” That is the right conversation, and it comes with a deadline attached: the day an auditor, or a breach, asks you to produce the record. OpenAI got that question in August. Its answer reached Services Australia a month later, by email, in a public inbox.
So ask the question now, while it is cheap. When someone asks which agents could read patient records last quarter, which ones actually did, on whose authority, and which models saw the results, what will you hand them?
In most industries, an unaccountable agent is a risk to manage. In healthcare, it is a finding waiting for an auditor.
Lynx is Tigera’s security and governance platform for AI agents on Kubernetes: identity, policy, detection, and audit for every agent in your cluster. Read How Lynx Works or request early access at tigera.io/demo/?product=lynx.
