Yesterday, Reuters reported that major U.S. banks were detecting unauthorized third-party AI agents inside customer accounts, with some apparently trying to do more than their users had instructed. Reuters was reporting an Axios story and said it could not immediately verify the claims. Axios described customers handing over their login credentials and banks struggling to distinguish customer-directed activity from actions an agent initiated on its own. Morgan Stanley, however, said it had not observed “rogue AI agents” accessing its platforms.
A customer might invite an agent into an account without the bank approving that access, and the agent could still go beyond the customer’s instructions. The reporting doesn’t explain how reliably banks can distinguish those situations. Meanwhile, Credit and Collection News, citing Financial Times reporting, described restrictions at Citi and Bank of America. The restrictions may reflect concerns about both security and competition for deposits, particularly if agents can move customers’ money to better-paying accounts elsewhere.
The banks are already setting terms
On JPMorgan Chase’s October 13 earnings call, CFO Jeremy Barnum described blocking agents that use shared credentials to access and move money, citing security concerns. He also warned that customers could bear the consequences of unwanted agent actions. Chase’s published terms require AI agents to identify themselves, label their traffic, answer questions about whether they are automated, and stop when told. Chase also reserves the right to restrict access and assigns users responsibility for certain unintended or excessive agent actions. Wells Fargo’s forthcoming agreement, effective November 24, takes a similar approach. Section 15 treats agent instructions as customer-authorized in specified circumstances, puts monitoring and revocation duties on users, and reserves controls over access methods and registration.
How much responsibility a bank can shift to its customer still depends on the law. Wells Fargo expressly makes key provisions subject to applicable law, and protections such as the Electronic Fund Transfer Act’s nonwaiver provision can limit what an agreement accomplishes. The account, transaction, and facts determine which protections apply.
Similarly, healthcare organizations also need to know who is accessing a patient’s records and what that person or software is allowed to do. But before borrowing a bank’s restrictions or liability language, they also need to carefuly consider their legal obligations to give patients access to those records.
Now send Larry to the patient portal
A colleague of mine sends an AI agent, whom I’ll call “Larry,” to make haircut appointments and book airline tickets. My colleague supplies the timing, budget, and preferences, and Larry handles the rest. I can appreciate outsourcing the “hold” music.
A patient could just as easily ask an AI assistant to log into a portal, retrieve recent test results, and organize them before an appointment. But once Larry starts accessing medical records, a few questions follow:
* Who is responsible for the agent?
* Is it legally acting as the patient (i.e., “stepping into the patient’s shoes”)?
* Is the vendor operating the AI agent also receiving the records?
* If the patient asked for last month’s labs but Larry downloads the entire chart, whose problem is that?
Calling software an “agent” doesn’t automatically give it the legal status of one. Under ordinary agency principles, an agent acts on another person’s behalf and subject to that person’s control, in a relationship that carries fiduciary duties. Whether the AI vendor has taken on that role depends on the law and the arrangement.
Federal law also recognizes an “electronic agent”. Under the E-SIGN Act, automated transactions can have legal effect when the system’s actions are legally attributable to the person being bound. See 15 U.S.C. § 7001(h). That doesn’t make the software a healthcare decision-maker or mean every automated click amounts to valid consent.
HIPAA’s personal representative rules generally look to state or other applicable law to determine who can make healthcare decisions for a living adult individual. Within the relevant scope, and subject to HIPAA’s exceptions, that representative is treated as the patient or health plan member. An AI bot doesn’t gain that status because someone calls it an agent, and permission to download records doesn’t automatically give its operator authority to make healthcare decisions. The patient may simply be using software to exercise an access right or directing records to a chosen third-party recipient. Either can be lawful without making the bot or vendor a personal representative. Applicable state law and any required consent formalities still apply, and permission to retrieve records doesn’t necessarily give the AI vendor permission to use or further disclose them for other purposes.
Covered entities already have HIPAA obligations to verify identity and authority when unknown, subject to the rule’s exceptions. The Security Rule also requires authentication, access controls, and audit controls for covered entities and business associates. Those duties don’t go away just because an AI vendor runs the portal. For patient-directed transfers to a third-party recipient, OCR permits reliance on the patient’s written identification of the recipient and destination, with reasonable safeguards. That does not always require an independent investigation of the recipient.
Neither rule prescribes a universal AI detector, but an agent with valid credentials may still exceed its instructions. The setup also affects the risk: a tool running locally may keep records on the patient’s device, while a cloud-based agent may send screenshots, prompts, and files through several companies and locations.
Information Blocking complicates things further
A healthcare organization can’t just “copy and paste” a bank’s AI bot policy into its portal terms. In a December 19, 2025 FAQ, ONC said that “interfering with access” through robotic process automation or agentic AI could implicate information blocking. The rules can apply whether a patient clicks through the portal personally or sends software to do it.
For a restriction to violate the information blocking rules (IBR), the organization must qualify as an “actor,” the information must be electronic health information (EHI), and the other elements must be met. Under 45 C.F.R. § 171.103, healthcare providers must know that a practice is unreasonable and likely to interfere with access, exchange, or use of EHI. Developers of certified health IT, HIEs, and health information networks face a “knows or should know” standard concerning interference. Practices required by law or covered by an exception are excluded.
The IBR Security Exception may protect a restriction, but it must directly safeguard EHI, be tailored to the specific security risk, and be applied consistently and without discrimination. If the organization relies on a security policy, that policy must be written, respond to assessed risks, align with applicable standards or best-practice guidance, and set objective timeframes and other parameters for handling security incidents. Without that policy basis, the organization needs a determination grounded in the particular facts that the restriction is necessary and no reasonable, appropriate alternative would address the risk with less interference. General unease about AI is unlikely to satisfy those conditions. An AI agent bypassing access controls or reaching another person’s records could give the organization a specific risk to address, but its response should fit that risk while preserving lawful access where possible. Failing to meet an exception also doesn’t automatically establish information blocking; the other elements of a violation still have to be met.
The IBR Privacy Exception may protect a refusal when a legally required consent or other prerequisite is missing, provided its conditions are satisfied. In specified circumstances, that includes reasonably helping the individual correct a defective consent or authorization. Actor-organizations can’t create a new legal prerequisite just by putting it in their portal terms. They also shouldn’t insist that a recipient become a personal representative when the patient has validly directed the disclosure to a third-party recipient, even if that recipient is an AI vendor.
Who is responsible when access goes wrong?
Under OCR’s app-liability guidance, a covered entity that properly sends requested records to a patient’s independently chosen app generally isn’t responsible under HIPAA for what that app does afterward, if the app is neither a covered entity nor a business associate and is not provided by or on behalf of the covered entity. The provider doesn’t need a special AI waiver to get that result. However, an app working on the provider’s behalf can create a HIPAA BA relationship, with HIPAA responsibilities and potential liability for later impermissible disclosures. That depends on what the vendor actually does; helping a patient obtain records alone doesn’t establish a HIPAA BA relationship. Also, neither arrangement excuses the provider’s own improper disclosure or security failures, and importantly OCR’s HIPAA guidance doesn’t insulate organizations fromm possible state-law claims.
If another patient’s chart was exposed, an access limit communicated to the organization was ignored, or the system released records beyond a valid request, the organization needs to investigate. Downloading an entire chart, however, isn’t inherently improper. The patient may want the whole thing, and HIPAA’s minimum necessary standard genreally does not limit disclosures to the individual himself/herself. On the other hand, a request for one lab report also doesn’t necessarily authorize continuing access to every record. And a private instruction to Larry may never reach the portal.
To work out who is responsible, we need to know what the patient actually instructed, what permission the organization received, and what its system allowed.
The vendor’s terms and settings should also explain what happens to downloaded records, including whether they are retained, used for general AI training, reviewed by people, or shared with others, and whether the patient can have them deleted. Even when HIPAA doesn’t cover the recipient, the FTC Act, Health Breach NOtifiation Rule, and state consumer protection laws may impose compliance obligations. Note, a disclaimer doesn’t automatically cure a deceptive practice or provide legally required consent. Portal terms should help patients understand who will receive their information, what the agent can access or do, how long access lasts, and how to end it. Permission to download shouldn’t automatically become permission to send messages or change account settings. Patients should also understand that disconnecting an AI agent generally won’t get back copies it has already downloaded.
Finally, I’d be careful about borrowing a sweeping “you assume all liability” provision from banking. A patient’s acknowledgment cannot erase HIPAA duties, and whether a release limits a civil claim depends on the law, the wording, the patient’s assent, and the claim itself. Requiring patients to sign away claims as a condition of legally proteced access could also raise HIPAA and information blocking concerns. And, if Larry clicks “I agree” to terms shifting liability to the patient, what reallyh shows that the patient authorized that agreement anyway?
Putting Patient Permission into Practice
NIST’s February 2026 concept paper and public-comment summary explore how to identify AI agents, define their authority, and track or stop their activity. They can help organizations design controls, although they don’t determine who is legally entitled to medical records. Providers, plans, HIEs, and portal vendors should check whether those controls connect the patient’s communicated permission to what the agent can actually do. Tools such as SMART on FHIR can support limited, revocable access, but the limits still need testing. Could the AI agent inadvertently retrieve another household member’s records through a proxy account? Could it keep accessing records after permission ends? Organizations also need to understand where the AI agent sends or stores information, including copies in logs. Even an agent carrying out a legitimate request can follow malicious instructions hidden in a document, turning a valid patient login into a Trojan horse. Records of the permission granted and the activity that followed will help an organization investigate when something goes wrong; So, preserve logs and audit trails.
The IRB intends to help patients access and use their records without unnecessary barriers; but accepting unverified or excessive access doesn’t advance that goal. Healthcare faces many of the same security problems as banking, including shared passwords, unclear authority, and software that exceeds instructions or keeps going after permission ends. The legal requirements differ, but even read-only access can expose an entire medical history. Regulators need to explain how organizations can verify an AI agent’s authority and address these risks while preserving lawful patient access. Agent vendors should make permissions enforceable and help investigate when their software exceeds them. Healthcare organizations, in turn, should be able to explain the specific risk behind an access restriction and how patients can still obtain their records.
At the end of the day, my colleague can ask an AI agent to book a haircut without giving it permission to choose a new hair color. Patients should be able to set similar limits on what an agent does with their medical information, and portal operators and AI vendors should be required to enforce those limits. When the next request arrives under a patient’s name, will we know what the patient actually authorized, or just that the AI agent had the right password?