Passwords were never a delegation mechanism. Customers are using them as one anyway, handing the keys to a chatbot that promises to sort their finances, and the biggest banks in the US have noticed.
The part worth your attention is the admission underneath the bans. The banks apparently cannot tell who is at the keyboard.
What the banks actually said
Start with what is on the record. On JPMorgan's third-quarter earnings call on 13 October, Jamie Dimon said he did not want rogue agents, and that there could be thousands of them. A bank spokeswoman told CNBC the firm does not let third parties into accounts using customers' banking credentials, as Cybernews relays it. Outside agents can see some account data read-only. They cannot send money or pay bills.
Axios reported on 22 October that major US banks are detecting third-party agents operating inside customer accounts, some of them apparently acting without the customer's instructions. The Hacker News weekly recap of 26 October put the core difficulty plainly: the agent logs in with the user's own permission and credentials, so the problem becomes telling a human from a bot. Banks are either restricting these agents or allowing read-only access. Citi, per the IBTimes summary, bars agent logins and direct transactions but allows limited read-only access through approved open-banking providers.
Bank of America emailed customers, TechCrunch reported on 27 October, under the subject line "Protecting your finances in the AI World". The message tells people not to share online banking credentials with anyone, AI agents included, and says they are responsible for activity that results from that access. You will see this repeated as the bank voiding fraud liability. As far as I could find, no outlet I could read says that, and the bank had not commented on reimbursement. The email is a warning and settles nobody's refund rights.
IBTimes adds that none of this establishes widespread unauthorised transfers or customer losses. Treat it as a control gap spotted early.
Why a shared password is the wrong primitive
When a customer pastes a password into an agent, they grant standing access. Four properties go wrong at once.
Scope. The session can do anything the customer can, so an agent hired to read a balance can also add a payee. Time. The access lasts until the password changes. Revocation. The only off switch also locks the customer out. Identity. Every action in your logs carries the customer's name, so the agent does not exist as far as your audit trail is concerned.
This is a non-human identity problem in a consumer costume. Service accounts with standing privilege turn one compromised thing into an incident, and consumers have just rebuilt that pattern at scale.
For internal agents my answer is a separate identity per agent, just-in-time access through Opal so nothing holds production rights between tasks, and a gateway, Willow in my case, that evaluates identity, connection, action scope and risk on every call. That is how I think about it, and I would ask a retail platform to answer the same four questions about a customer's agent.
What the engineering side should build
The same four questions make a workable decision path for any request that might be an agent.
Delegation first. Let the customer pick an agent, pick read-only, pick a duration, and see and kill the grant from inside the app. Read-only by default. Money movement, if it ships at all, is a separate and narrower grant with a payee allowlist and a cap. Open banking already works on this consent model for aggregators. Agents are the same shape of problem with a more eager client.
Signals second. Password sessions driven by an agent tend to carry tells: automation-flagged browsers, datacentre addresses, machine-regular timing, no pointer movement. Score them, but never treat them as a verdict. An agent driving a real browser on the customer's own laptop passes most of that, and a password manager can trip it.
Step-up and terms
Anything that moves money, adds a payee, changes contact details or lifts a limit gets a step-up the agent cannot satisfy. That means a passkey or device-bound biometric held by the human. An SMS code the customer reads out to the agent defeats the purpose, because the agent now holds the factor too.
Axios also reported agents contacting bank call centres, so the support channel needs the same identity proof as the app. Bank of America's chief executive, Brian Moynihan, said in a 14 October CNBC interview, per IBTimes, that the bank is working with AI providers so a human authorises money leaving an account. Build to that.
Then terms. Say in plain language what a delegated agent is, what sharing a password does to the customer's position, and what you do when an agent misbehaves under a valid grant. Dimon described a liability transfer, which TFTC reads as customers carrying the loss when they authorise an outside agent. TFTC also says US rules tie liability to whether the account holder authorised a transaction, and that no federal banking regulator has yet written a rule for agents. That belongs to legal, but engineering should force the question now.
What it costs
Delegated access is a product build with a long tail: scope design, consent screens, revocation, audit views and support scripts. Customers will keep pasting passwords, because the agent works with a password today and not with your API tomorrow. Behavioural scoring produces false positives, and each one is a locked-out customer on the phone. Blocking without a sanctioned lane pushes the behaviour somewhere you can see less.
I know the shape of that bill from my own pipeline, where invisible controls meant AppSec absorbing the integration work. A consumer platform pays the same bill with a much bigger audience.
Verdict
Blocking is a stopgap. Treat a password handed to an agent as a compromise-grade event in your risk model, because the credential now lives somewhere you do not control. Ship read-only delegation as the sanctioned lane. Make money movement need a human factor the agent cannot hold. Write the liability terms before an incident writes them for you.
- Cybernews: JPMorgan blocks outside AI agents from customer accounts
- Let's Data Science: US banks harden defences against rogue AI agents
- IBTimes UK: US banks block AI agents from customer accounts
- The Hacker News: Weekly Recap, 26 October 2026
- TechRadar: Bank of America tells customers to stop sharing banking passwords with AI agents
- explainx.ai: Bank of America email, relaying the TechCrunch report
- TFTC: Rogue AI agents, bank accounts and the credential problem
No comments:
Post a Comment