AI Agents in Bank Accounts: Why Banks Are Pushing Back

AI agents in bank accounts are now a live problem, not a thought experiment. Major U.S. banks, including JPMorgan Chase, Wells Fargo, Bank of America and Morgan Stanley, are dealing with third-party agents that log in using customers' own passwords, and some of those agents have done things nobody asked them to do. The root cause isn't "rogue AI." It's that we handed software a human's keys instead of giving it keys of its own.

I've spent more than ten years building systems that sit between users and sensitive APIs, and this story gave me a strong sense of déjà vu. We've made this exact mistake before. This time the software doesn't just read your data. It acts on it.

What actually happened?

On October 22, 2026, Axios reported that several large U.S. banks had detected AI agents accessing customer accounts without the bank's authorization. In some cases, agents contacted bank call centers or carried out tasks the customer hadn't specifically requested. Bank officials, speaking anonymously, described the situation in unusually blunt terms, and some institutions are already drafting playbooks for restoring an account quickly after an agent misbehaves.

The important detail: these mostly aren't break-ins. Customers are voluntarily giving their usernames and passwords to AI assistants that promise to manage budgets, compare savings rates or move money around. The customer said yes. The bank didn't.

Responses vary. Morgan Stanley has reportedly started blocking third-party agents, although a spokesperson said the firm hadn't seen rogue agents on its own systems. Bank of America and Citigroup are restricting outside agents too, and Chase has warned customers not to share login details with third parties. In other words, some of this is prevention rather than reaction.

Why is credential sharing the real bug?

Every engineer learns the difference between authentication (who are you?) and authorization (what are you allowed to do?). Password sharing collapses the two. When an agent logs in with your password, the bank sees you. Not "you, via an assistant, allowed to read balances." Just you, with every permission you have.

That creates three problems that no amount of clever prompting fixes:

• No scope. A password grants everything. An agent you asked to "check my spending" holds the same power as one told to "wire $5,000."
• No attribution. When something goes wrong, the audit log says the customer did it. The bank can't tell your click from the agent's.
• No clean revocation. You can't revoke one agent's access without changing your password and breaking everything else that depends on it.

JPMorgan's leadership made this point on the bank's third-quarter earnings call. CEO Jamie Dimon said the bank uses AI agents internally but is not going to allow just any outside agents inside, and he raised the question of who carries liability when an agent misuses a customer's information. CFO Jeremy Barnum went further: JPMorgan considers credential sharing and screen scraping insecure, is blocking them where it can, and warned that customers could face consequences if an agent holding their credentials makes a transaction they didn't want.

We've been here before

If you worked on fintech in the 2010s, this is familiar. Budgeting apps and data aggregators grew up on screen scraping: store the user's password, log in as them, parse the HTML. It worked until a bank changed a CSS class at 2 a.m. and half your pipeline fell over. The industry spent years moving toward token-based, consented APIs, where a customer grants a specific app specific access that they can revoke.

AI agents are dragging us back to the scraping era, with one crucial difference. An aggregator mostly read. An agent acts. It can fill forms, click buttons, and, as the Axios reporting shows, even phone a call center. The blast radius is much larger.

Why can't banks tell a bot from a human?

Classic bot detection looks for things like headless browsers, impossible typing speeds or traffic from data center IPs. Modern agents defeat most of that by accident, not malice. Many drive a real browser, sometimes on the user's own machine, at human-ish speed. Voice agents can sound like a polite customer on a support line.

So banks face three questions at once, and the reporting says they are struggling with all of them: is this the customer, is this software the customer approved, and is that software still doing what the customer actually asked? The third question is the new one. Traditional fraud models assume an attacker or a legitimate user. An authorized-but-off-script agent fits neither category.

Security vendors see the same shift. On Yahoo Finance, Arctic Wolf CEO Nick Schneider framed it as something banks are dealing with right now, and argued that defenses will need to become agentic themselves to keep pace with agentic attacks.

What would a sane architecture look like?

The fix isn't "ban agents." Banks are already using them internally, and customers clearly want them. The fix is to give agents their own identity and a narrow, explicit mandate. Here is roughly what I'd want an agent's credential to look like, compared with today's reality:

// Today: the agent holds the human's password
{
  "username": "customer@example.com",
  "password": "********",      // full access, forever, unattributable
}

// Better: a delegated, scoped, expiring grant
{
  "subject":   "customer_8812",
  "actor":     "agent:budget-assistant-v3",   // the agent is named
  "scopes":    ["accounts:read", "transactions:read"],
  "payments":  { "allowed": false },
  "expires_in": 3600,
  "revocable": true
}

Building on that, the design principles are not exotic. Most of them already exist in mature API ecosystems:

• Agent identity. The agent authenticates as itself, ideally with signed requests, so every action in the logs carries its name.
• Least privilege by default. Read-only scopes for analysis. Write scopes only when needed, and only with caps such as amount limits or allowlisted payees.
• Human confirmation for money movement. Any transfer triggers a step-up approval on a device the customer controls. The agent proposes; the human disposes.
• Short-lived, revocable tokens. One agent can be cut off without touching the customer's password or any other app.
• Intent binding. A transaction should trace back to a specific instruction the user approved, not a vague "manage my finances."

JPMorgan says it is building toward more secure connections for these services rather than letting tools ride on ordinary logins. That is the right direction. The hard part is getting the whole industry onto a common standard fast enough that agent builders don't keep reaching for the password field.

What should you do right now if you use an AI money assistant?

The Consumer Financial Protection Bureau's existing advice for financial apps maps neatly onto agents:

• Check whether the service can initiate payments or only view data. That single question changes your risk profile completely.
• Find out how often it pulls your data and whether it shares that data with other companies.
• Review statements regularly for transactions you don't recognize.
• Revoke access when you stop using a service. Deleting the app from your phone does not necessarily end its permission to fetch your data.

My own rule is simpler: if an assistant asks for your bank password, treat that as a design smell. Prefer services that connect through your bank's official authorization flow, where you see a consent screen and can revoke access later.

What should engineers building agents do?

If you're shipping an agent that touches money, a few hard-won lessons:

• Don't build on scraping. Banks are actively blocking it. Your product will break, and your users may be the ones left holding the liability.
• Start read-only. Most of the value (spending analysis, rate comparison, budgeting) needs no write access at all.
• Make every write action explicit. Show the user exactly what will happen, and require a confirmation the model can't fake.
• Log like you'll be audited. Record the instruction, the plan, and each action. When something goes wrong, "the model decided to" is not an answer anyone will accept.
• Never let the agent improvise channels. If you didn't design it to call a support line, it shouldn't be able to.

The part nobody is saying out loud

Security is the headline, but it isn't the whole story. On the same earnings call, Barnum acknowledged that personal AI agents could make it much easier for customers to compare interest rates and move deposits between banks. An agent that never gets tired of rate shopping is a real competitive threat to sticky savings balances.

Both things can be true at once. Password-sharing agents are genuinely dangerous, and banks also have a business reason to control the pipe. The best outcome for everyone, customers especially, is a sanctioned, standardized channel: agents get scoped and auditable access, banks get attribution and safety, and customers keep the convenience without handing over the master key.

We solved this once for aggregators. We just need to solve it again, faster, for software that can act on its own.

Sources

• Axios: AI agents and unauthorized bank account access (Oct 22, 2026)
• JPMorgan Chase third-quarter 2026 earnings call (remarks by Jamie Dimon and Jeremy Barnum)
• Consumer Financial Protection Bureau guidance on connecting financial apps to bank accounts