In Part 1, we looked at how patient-deployed AI agents are creating a governance gap that most health systems haven't named yet, with real stakes across security, accessibility, and enforcement. Part 2 is about where that problem actually lands inside the organization.
The clinical triage failure mode
Agent-generated portal activity doesn't only fall to a governance committee. It lands in a nursing inbox.
Consider the scenario your triage nurses are already facing. A secure message arrives at 6:30 AM. It reads: "I'm feeling worse and I think we should stop the new medication." The nurse triages it on tone, urgency, and implied patient intent. She makes a clinical judgment about how to respond. She has no way to know whether a patient wrote that message or an agent did. There's no metadata flag, no session-level attribution, and no clinical decision support that fires on a secure message the way a BPA might fire on a medication order. The entire triage decision is based on assumptions about authorship that may not be true.
If that interaction triggers a care plan change that later becomes the subject of a patient safety review or a litigation hold, there is currently no reliable forensic path to reconstruct whether a human initiated it. No major EHR platform currently offers session-level metadata distinguishing agent-generated portal activity from patient-generated activity as a purpose-built governance capability. Attribution is a genuinely hard technical problem. Agents designed to mimic human portal behavior, introducing timing variation and replicating navigation patterns, are specifically built to be indistinguishable from human users. Conversations with EHR vendors about what telemetry is possible and what detection might look like are worth starting now, with realistic expectations about what those conversations are likely to produce in the near term.
There is no clean interim guidance here. Every option available today carries real tradeoffs. Requiring confirmation of agent-originated messages before acting on clinical change requests adds workflow burden that nursing teams at volume will struggle to sustain. Treating all portal messages as potentially agent-generated lowers institutional confidence in portal communications more broadly. Accepting the risk explicitly and documenting that decision at least makes the approach visible and deliberate. None of these is fully satisfying. The field does not yet have a settled answer to this problem, and organizations that acknowledge that honestly are better positioned than those that reach for operational solutions before the problem is well enough understood to solve.
What health systems can do now
No playbook exists yet for patient-deployed agents. The Joint Commission and CHAI guidance on responsible AI use was written with organizationally deployed tools in mind. It does not address tools patients bring. That gap will get filled eventually. Organizations that prepare now won't be scrambling when it does.
Several things are within a health system's control right now.
1. Identify the clinical failure mode. CNIOs and CMIOs should bring this to clinical informatics leadership and the patient safety committee as an emerging risk category, starting with the questions that need answering before any operational guidance is deployed: What is our current portal message volume for clinically significant requests? What do our triage workflows assume about message authorship? What would change if those assumptions broke?
2. Bring the right people into the same conversation. Security, clinical operations, legal, and governance each see a different piece of this problem. The failure modes connect across all four. That conversation is worth having before an incident makes it urgent.
3. Know your enforcement approach. Whether your organization has made a deliberate decision about automated-access portal restrictions, or simply has not gotten there yet, that approach is worth understanding: what it is, whether it is documented, whether security operations knows about it, and whether clinical workflows reflect it.
4. Start the EHR vendor conversation. Session-level attribution for portal activity is the instrumentation foundation that any future detection capability depends on. The organizations that begin that conversation now will be better positioned when the technical landscape shifts.
5. Understand your position before sizing any investment. Before detection investments or governance buildouts reach a board deck, work with legal counsel to assess your organization's actual exposure: what portal telemetry currently exists, what your EHR vendor can realistically expose, and what your current workflows assume about message authorship. Structure that assessment under attorney-client privilege. The goal is to understand your actual position before committing to investments sized against assumptions that may not hold.
6. Think about detection and expanded API access as connected goals. Detection infrastructure addresses the credential-based agent problem as it exists today. Expanding the standardized API channels patients can use for portal actions addresses the reason it exists. FHIR write-back refers to developing authorized API pathways that allow patients and their agents to schedule, message, request refills, and manage care through governed channels rather than credential-based portal scraping. Da Vinci implementation guides for scheduling and messaging are in active development. USCDI scope is expanding. Closing that functional gap over time shrinks the problem. A board conversation that treats detection and API expansion as separate problems gives risk-averse leaders permission to defer the structural fix indefinitely.
The harder governance question
For most organizations, the harder governance question — whether to allow patient agents — has already been answered by default. The work that remains isn't the decision. It's whether to govern what's already happening deliberately or by accident.
Health system AI governance has been built around a specific model: the organization evaluates a tool, deploys it, monitors it, and maintains accountability for how it influences decisions. Patient agents don't fit that model. The tool was chosen and deployed by the patient. The accountability structure wasn't designed for interactions that originate outside your perimeter.
The legal landscape requires precision here, because the analysis differs by access channel.
For FHIR-based API access, the information blocking framework is well established. In December 2025, ASTP/ONC issued new information blocking FAQs (sub-regulatory guidance that signals enforcement intent but does not carry the weight of rulemaking) stating that practices which materially discourage automated access to electronic health information, including by AI agents operating through standardized API channels, can implicate the information blocking rules. On that channel, the argument that health systems face real constraint in blocking patient agents is well-grounded in current regulatory direction.
For credential-based portal automation, the analysis is genuinely unsettled. The PointClickCare case, in which the Fourth Circuit found that using technical controls to block automated access likely constituted information blocking, involved a health information network operating through certified health IT pathways under the Cures Act actors framework. It was not about a patient's agent using credential-based portal scraping, and the ruling doesn't transfer cleanly to that fact pattern. HTI-5's proposed language defining "access" and "use" to include autonomous AI systems is a proposed rule that drew meaningful pushback during the comment period, not settled direction.
What this means practically: most health systems face an unresolved governance question, not a clear legal prohibition. Many have already effectively taken an enforcement position on credential-based portal agents without a deliberate, documented decision. The approach itself may be entirely defensible. The failure to document it, brief the CISO on it, and build clinical workflows around it is what creates exposure.
Any board briefing on your organization's enforcement approach should be structured as routine governance hygiene, handled under attorney-client privilege with counsel present. That structure is appropriate for any board conversation involving enforcement decisions and litigation exposure, not a signal that something has gone wrong. Bring your general counsel before you bring your board chair.
The work now is making that position explicit, building the operational infrastructure to manage it responsibly, and being honest about what that costs and how long it takes.
Missed Part 1? It covers the enforcement position most boards haven't been briefed on, the security exposure your SOC may not know to threat-model, and the accessibility dimension that complicates any portal restriction before general counsel reviews it. Read Part 1. Part 3 takes up the question underneath all of it: by what authority does a patient's agent act? Read Part 3.
