Banks Reportedly Restrict AI Agent Access After Unauthorized Account Activity

AI agents are being sold as the helpful co-op partner for everyday digital chores: ask one to organize information, make a booking, compare products, or complete a task across websites. That promise becomes substantially more alarming when the website is a bank and the task involves access to an account containing real money.

Several US banking institutions have reportedly identified unauthorized third-party AI-agent activity involving customer accounts. More concerningly, unnamed banking sources indicated that some agents appeared to take actions without a specific user instruction for each action. The reported behavior includes contacting bank call centers, a step that goes beyond merely displaying a balance or sorting transactions.

The reports do not establish a public, verified account of an agent independently moving a particular customer’s money, and there have not been many public accounts of AI-driven financial disasters so far. That uncertainty matters. But it does not make the risk theoretical: banks including Morgan Stanley, Bank of America, JPMorgan and Wells Fargo have reportedly acted quickly to contain it. Their responses have included blocking third-party agents in some cases, placing restrictions on access in others, and working toward read-only access that would prevent agents from making account changes.

For anyone who treats a login prompt as a quest marker rather than a security boundary, this is an important distinction. Giving an AI access to view financial information is one category of risk. Giving it the ability to transfer funds, purchase something, alter account settings, or speak to a support channel is another entirely.

The issue is not just AI; it is delegated authority

An AI agent is software intended to act on a user’s behalf, rather than simply respond with text. In this context, the key word is “act.” An agent may be instructed to navigate a website, complete forms, communicate with services, or carry out a sequence of tasks. Some agents, including Muse, can access a user’s bank account to perform actions for them.

That capability turns a familiar account-security question into a delegation problem. With a conventional banking session, the customer signs in and chooses each action. With an agent, the customer may supply account credentials and a broader objective, then allow software to determine the steps that fulfill it. The more broadly phrased the task and the more permissions the agent has, the less direct control the account holder has over each individual step.

A read-only setup is therefore meaningful. “Read-only” generally means the software can retrieve and display information but cannot change anything. It might be able to surface a balance or transactions, but it should not be able to submit a payment, shift money, update a profile, or launch a new conversation with a call center. It is not a magic security shield—sensitive information can still be exposed—but it removes the most immediate risk of the agent directly executing a financial action.

By contrast, an agent with action permissions has what amounts to a controller in hand. It may be authorized to take steps that have consequences. The worry in the bank reports is not merely that an agent could misunderstand an instruction. It is that tracked activity allegedly included behavior for which a specific instruction was not given.

Why bank credentials are a particularly dangerous shortcut

Many banks require the human account holder to log in personally. Providing a username and password to an outside agent can conflict with that expectation and creates a chain of exposure that is difficult for a customer to see or audit.

Once credentials are handed over, the customer is no longer simply using a service inside the bank’s own environment. A third party is involved in the route between the customer and the account. The software may gain access to highly sensitive information, and any ability to make changes introduces the chance of an unwanted transaction or account action. A mistake could arise from bad instructions, an overly broad instruction, software behavior that does not align with the user’s intent, or a scammer’s attempt to exploit the arrangement.

JPMorgan chief executive Jamie Dimon has warned that there could be thousands of rogue agents operating across financial platforms. Separately, a Chase spokesperson stressed that customers should not provide their usernames and passwords to anyone, including AI agents.

That advice is more direct than it may first sound. An agent is not made safe simply because it has a friendly interface, a playful name, or a useful purpose. Nor does calling it an “assistant” alter what it means to surrender a banking password. If the tool needs the same credentials a person would use to enter an account, the user should treat that request as a high-stakes permission decision, not a routine feature toggle.

What the reported bank restrictions signal

The bank responses suggest that financial institutions are trying to draw a bright line between information access and transaction access. Blocking third-party agents entirely is the bluntest option. Limiting their access in specific situations is a narrower approach. Moving toward read-only access is a middle ground that preserves some convenience while seeking to stop software from changing the customer’s financial position.

Those are practical controls, but they also reveal how awkward the current model can be. Consumer AI agents are often designed around convenience: one tool crosses several sites and handles several steps. Banking is built around accountability, authentication, and deliberate authorization. Those two models can collide when a tool that is meant to act autonomously encounters an account where every action may carry a monetary or legal consequence.

In gaming terms, a bank account is not a menu where it is harmless if an autopilot selects the wrong dialogue option. An erroneous click can change a payee, initiate a purchase, move funds, or reveal private account data. And a support call is not necessarily a harmless detour. It can be part of an account-management process that a customer did not intend to start.

The developing restrictions could also mean AI features work less smoothly with banks than users expect. A general-purpose agent may be able to summarize financial information in a user-provided document, for example, while being unable to sign into a bank site or do anything after login. That is a limitation, but it is a sensible one where the alternative is unclear responsibility for an action the customer did not personally perform.

Liability may be the harshest part of the risk

The most consequential warning is not only that an agent could do something unwanted. It is that getting the money back may be difficult if the customer voluntarily gave the agent access.

The reported concern is that banks may not be liable for restitution when an AI agent makes a damaging action after the account holder has handed over the credentials. The action could be treated as voluntary on the customer’s part under frameworks including the US Electronic Fund Transfer Act. Put plainly: the protections people associate with fraud may not apply in the same way if the account owner supplied the keys to the tool that acted.

This is an area where users should resist assumptions. “I did not personally press the button” is not necessarily the same as “I did not authorize access.” The legal and practical outcomes can depend on the facts and on the bank’s policies, but the reported warning is clear enough: delegating access can leave the customer with the risk when something goes wrong.

That makes preventative choices more valuable than after-the-fact arguments. It is easier to avoid sharing credentials than to prove, later, precisely what an agent was told, what it did, and why. A person who wants to use AI around money should separate low-risk assistance—such as explaining a statement the user already has—from direct account access as sharply as possible.

Practical guardrails for customers

The facts reported so far support a cautious default, not panic. There is no need to assume every AI system is secretly raiding accounts. There is, however, a strong reason not to give a third-party agent a bank username and password simply to save a few minutes.

Do not share bank usernames or passwords with AI agents. This aligns with the public warning from Chase and avoids granting an outside tool direct access to the account.
Prefer read-only access if an institution offers a legitimate, controlled method for it. Read-only permissions are still sensitive, but they aim to stop transactions and account changes.
Do not treat a broad request as a safe instruction for financial software. A request to “handle this” can be much less bounded than a person realizes when software is able to navigate, communicate, and act.
Keep account actions with the account holder. Transfers, purchases, profile changes, and calls involving account management are actions worth completing personally through the bank’s normal process.
Be skeptical of convenience pitches that require credentials. A friendly AI interface does not reduce the sensitivity of the data or authority being requested.

The broader technology industry is still deciding where agents should be allowed to operate and where they need firm limits. That tension is visible elsewhere in digital products as services change direction, including the recent report that Arc Browser will shut down as its developer shifts users to Dia. But banking is a special case: a product experiment or imperfect automation is one thing; delegated access to money is another.

For now, the useful rule is wonderfully unglamorous. Keep a human on the controls. Let AI help interpret information if needed, but do not give an autonomous tool the credentials and authority required to make financial moves on your behalf.