Is that the patient, or their agent?

A username and password prove only that someone had them. When a person hands their login to an AI agent, every system downstream sees the person, and that is now a live problem for any product with an account holder behind it.

Axios reported on Oct. 22 that major U.S. banks are detecting unauthorized third-party AI agents operating inside accounts, with some agents attempting actions that appear independent of user instructions, according to people familiar with the issue. Axios describes these as generally cases where an agent or AI assistant accesses an account with the user's permission and login credentials, which goes against most banks' guidelines requiring that people log in to their own accounts.

Axios names Morgan Stanley, Bank of America, JPMorgan, Wells Fargo, and others as racing to contain agent risks, and reports that Morgan Stanley has begun blocking third-party agents and that JPMorgan, Bank of America, and Citi are also restricting them. A Morgan Stanley spokesperson told Axios the bank had not observed instances of "rogue AI agents accessing our platforms." The detail that matters most for everyone else is this one: according to Axios's sources, many banks are broadly not able to parse whether agent account activity is user-directed, and one executive said they struggle to tell whether an agent was authorized or has gone rogue.

Why this travels to patient portals

Banks are early because the money makes it urgent. The same pattern applies to any login that sits in front of personal data and lets the user do things: patient portals, insurance accounts, pharmacy apps, telehealth platforms, benefits sites.

Think about what a patient portal lets a logged-in person do. Read test results and visit notes. Message a care team. Request refills. Schedule and cancel appointments. Update contact details and proxy access. Pay bills. Every one of those is a task a person might reasonably ask an AI assistant to handle, and every one of them is something you would want to know was done by an agent.

Patients already share portal access informally with family members and caregivers. Agents make that easier and less visible. A patient who gives an assistant their portal password to "keep track of my appointments" may not realize the assistant can also read every note in the chart and send messages in their name.

What the bank story tells product teams

Three things stand out from the Axios reporting, and each one maps to a health product.

The credential is the user's own. In the cases Axios describes, the user handed the login over. Your fraud controls, which look for credentials used by the wrong person, may see nothing unusual.

The agent may do more than asked. Axios's sources describe agents that contact call centers or appear to take actions independent of user instructions. In a portal, that could be a message to a clinician, a cancelled appointment, or a changed phone number.

Blocking is the first response, and it does not last. Axios reports that most banks have authorized or are moving toward read-only access, as they already do for third-party budgeting apps, and that executives see the need for a middle ground because users will want these agents. Health products should expect the same arc and design for it now.

Three design questions for any product with a login

These are the questions I would put to any product team whose users log in to see or act on sensitive data.

1. Can we tell a person from an agent? Look at what you can actually observe: how sessions start, how fast actions happen, what software is making the requests, whether behavior looks scripted. You may not be able to tell reliably today. The point of asking is to find out whether you can, and to stop assuming every session is the human.

2. Is there a sanctioned way in for agents? If the only way for an assistant to help a patient is to use the patient's password, that is what people will do. A delegated, scoped access path, read-only by default, with the patient able to see and revoke it, gives agents a front door and gives you a way to tell them apart. Banks are moving toward read-only access for exactly this reason.

3. Which actions should always require the person? Decide which actions are too consequential to accept from a session you cannot attribute: changing contact details or proxy access, messaging a clinician, cancelling care, moving money. For those, require a fresh confirmation from the person through a channel the agent does not control.

The governance question underneath

For leadership, the question is who is accountable when an agent acts in a patient's name. The patient authorized it, the agent's maker built it, and your product executed it. Your terms of service probably say users must not share credentials. Axios reports banks are rapidly rewriting their terms of service for this reason. A clause will not tell you which session was the person, though. That takes product design.

This belongs on the AI readiness agenda even for companies that have no AI features of their own. Your users' agents are coming whether or not you build anything.

Start with your own logs

Pull a week of portal or account sessions and look for ones that do not look like a person: unusual speed, unusual software, actions in bulk. Then pick the three most consequential actions in your product and ask whether any of them could be completed today by an agent holding a patient's password, with no further confirmation.