The report that landed on Thursday described something other than a breach in the usual sense: customers handing their bank passwords to software agents, and the banks discovering that their security model had no way to tell the software from the customer.
Axios reported that Morgan Stanley, JPMorgan Chase, Bank of America, Wells Fargo, Citigroup and other large lenders had detected unauthorized third-party AI agents inside customer accounts. Some agents attempted actions that appeared independent of user instructions, and some contacted bank call centers. Morgan Stanley has begun blocking outside agents. The others are restricting access, rewriting their service terms and, in some cases, blocking the tools outright. Reuters reported the blocking separately, citing two sources.
The word unauthorized is doing a lot of work. In most of the reported cases, the customer had given the agent permission. What the bank had not given was permission. That distinction is the whole fight.
The login was the control
Bank account agreements are built on a simple assumption. The customer is a person, the person logs in, and the login is the authorization. Most banks' terms require the account holder to sign in personally and tell customers not to share usernames or passwords. A Chase spokesperson repeated that instruction to reporters: do not share your username and password with anyone.
That rule marks the boundary of the bank's responsibility, not merely a security suggestion. If a customer gives the password to a third party and the third party moves money, the bank can argue that the customer authorized the access and assumed the risk. If the bank's own systems are broken into, a different set of obligations applies. The agent sits between those two categories, and the categories are what the bank's lawyers use to decide who pays.
An AI agent does not need to break into anything. It can use the customer's credentials, navigate the site like a person, and take actions the customer asked for. It can also take actions the customer did not specifically ask for, because the customer gave it a goal rather than a script. A tool that is told to sort out a bill may decide that moving money is the way to do it.
What the bank can see
The banks' problem is one of identity, not access. A login tells the bank which credentials were used. It does not reliably tell the bank whether a human or a bot is on the other end, whether the customer approved the specific action, or whether the agent is the one the customer intended to use.
The reporting describes the same difficulty: banks cannot reliably distinguish one agent from another, an authorized use from a rogue intrusion, or a bot from a person. That gap sits at the center of the control framework the banks have spent years building.
Banks have spent years building detection around device fingerprints, behavioral signals and transaction patterns. Those tools can flag unusual activity, but they are calibrated to fraud and money laundering, not to a customer's delegated software making a legitimate payment in an unusual way. The agent can look like the customer because it is using the customer's session. It can also look like a fraudster because it is doing something the customer has never done before.
The mechanics make the identification harder. An agent typically runs in a browser. It reads the page, fills the login form with credentials the customer stored, and clicks through the interface the way a person would. To the bank's servers, the session can look ordinary: a real browser, a residential address, a plausible sequence of pages. The tell is the speed, the repetition and the actions that do not match the customer's history, not the connection itself. A device fingerprint is weaker than it sounds when the agent runs on the customer's own machine and browser. The bank sees the customer's device because it is the customer's device, with the agent driving it.
The call-center detail matters for the same reason. An agent that phones the bank and impersonates the customer is using the bank's human channel, where verification relies on questions and voice, not just accessing data. If the agent can answer the questions, the control is weak. If it cannot, the bank has to decide whether to treat the call as suspicious or as a customer with a bad connection.
The block is a liability decision
The banks are saying they will not accept the risk of letting the technology work through their front door, whatever they think of its technical merits.
Morgan Stanley said it had not observed rogue AI agents on its platforms. Sources told Axios the bank had begun barring outside agents. JPMorgan's chief executive, Jamie Dimon, said earlier in October that JPMorgan will not let just any outside agent inside the company because it is too risky for clients and for the bank. Charles Schwab's chief executive, Rick Wurster, said the firm blocks unauthorized agents a double-digit number of times every week. Bank of America and Wells Fargo were named among the institutions taking steps.
The reported cases did not include a documented unauthorized transfer, which is why the banks' response looks preventive rather than reactive. That matters for the legal analysis. A bank that can show it blocked an unauthorized agent is protecting its systems. A bank that allowed the agent and then lost money would have to argue about whether the customer's permission to the agent was permission to the bank. The terms of service are written to avoid that argument.
There is also a competitive motive. Banks are building their own agents and their own agent platforms. Letting a third-party agent operate inside the account gives the outside developer the customer relationship and the data. Blocking it keeps the interaction on the bank's rails, where the bank can set the permissions and see the activity.
Read-only is the compromise
The most likely outcome is a narrower door rather than a ban on agents.
Most banks already allow read-only access, and the reporting describes a move toward view-only connections. A budgeting app can see balances and transactions without the ability to move money. Citigroup said it does not let third-party agents log into accounts or transact. The direction is toward a narrower permission, not an open door.
That model gives customers the convenience of an agent that can see their finances without giving the agent the power to change them. It also gives the bank a technical control point. A view-only permission can be scoped, logged and revoked. A shared password cannot.
The catch is that read-only access solves the bank's problem, not the customer's. A customer who wants an agent to pay bills, move money between accounts or negotiate a fee needs transactional access. If the bank will not provide it, the customer can still hand over the password, which is exactly what the banks are trying to stop. The compromise may push the risky behavior outside the approved rails rather than eliminate it.
The standard that does not exist yet
No common standard for agent identity and authorization exists yet. A workable one would need to be cryptographic rather than declarative, so a bank can verify the agent's identity without trusting the agent's own description of itself. It would also need revocation, so a customer can withdraw permission without changing a password, and an audit trail, so a disputed transaction can be traced to a specific instruction.
Without that, every bank is writing its own rules. Some may allow read-only access. Some may require a specific provider. Some may block all agents. The customer experience will depend on which bank they use, and the agent developer will have to integrate with each one separately.
The liability question is even less settled. If an agent makes a mistake, the customer may blame the developer, the developer may blame the model, and the bank may say the customer shared the password. The bank's terms will try to place the loss on the customer. The developer's terms will try to disclaim it. The customer will be left with the account and the loss.
That is why the banks' blocking is best understood as a refusal to accept a risk before the rules for allocating it exist. The technology arrived before the contracts did.
What customers traded away
The appeal of an agent is that it removes friction. It can watch balances, move money, pay bills and compare offers without the customer clicking through each step. The cost is that the customer is delegating judgment to software, and the bank's protections are built around a person making each decision.
The banks' terms have always put the customer on the hook for shared credentials. Customers who used budgeting apps with read-only access did not notice the distinction because the app could not move money. An agent that can transact crosses the line, even if the customer intended only a narrow task.
The reporting suggests the banks are moving toward a compromise: let agents see, but not touch. That would preserve the most common use cases and keep the transaction authority with the human. It would also leave the harder use cases, the ones that make an agent valuable, outside the approved system.
The next few months will test whether the banks can build a permission model that customers trust and developers can use. If they cannot, the password sharing will continue, and the blocks will become a game of whack-a-mole between the bank's login page and the agent's browser. The banks can close the front door. The customer can still hand over the key.
Primary sources
- Axios, "Scoop: Unvetted AI agents are accessing U.S. bank accounts", October 22, 2026, as syndicated by Yahoo Finance.
- Reuters, "US banks detect unauthorized AI agents in customer accounts, Axios reports", October 22, 2026.
- PYMNTS, coverage of the banks' restrictions and the read-only access model.