This week major US banks started blocking third-party AI agents from customer accounts. The trigger: people handing their banking logins to consumer "do it for me" assistants that then log in, act like a human, and try to move money - with no declared bot identity and no clear human sign-off. Banks cannot tell those agents apart from an attacker, so they are shutting them out. It is a preview of what breaks when agents touch real systems without identity, least privilege, and a human in the loop - the same lesson, in a higher-stakes setting.
If you want one story that explains why "agent oversight" became the theme of the month, it is this one. On October 22, Reuters and Axios reported that several of the largest US banks - including JPMorgan Chase, Bank of America, Wells Fargo, and Morgan Stanley - were detecting unapproved third-party AI agents in customer accounts and restricting what they can do. The reporting put a date on a shift that had been building for weeks; JPMorgan's leadership and others had flagged the risk earlier in October. Brokerages moved too: Charles Schwab's CEO, Richard Wurster, said the firm was blocking unauthorized agents a double-digit number of times per week. (Morgan Stanley said it was restricting third-party agents but had not seen rogue-agent incidents on its own platforms.)
What actually happened
The core of it is mundane and worrying at the same time. Early adopters have started giving consumer AI agents - the "book my travel," "optimize my budget," "move my savings to the best rate" kind - their actual banking usernames and passwords. The agent then does exactly what it was told: it logs into the bank's website, navigates it like a person, and attempts actions on the account.
To be precise about what is proven: banks reported detecting these logins and suspicious attempts to act outside a customer's apparent instructions. They have not said agents successfully drained accounts - the blocking is pre-emptive. There is a legal wrinkle, too. Because customers handed over their own credentials, it is genuinely murky whether the resulting transactions would even count as "unauthorized," which is part of why banks are reaching for blunt blocking rather than fraud rules.
From the bank's side, the activity looks almost indistinguishable from an attack. A script is logging in with valid credentials from an unfamiliar place and trying to move money, with no signal that a human reviewed the specific action. Security systems are built to treat that as credential stuffing or account takeover - so they block it. On Bank of America's Q3 earnings call on October 14, its CEO, Brian Moynihan, put the principle plainly: a human needs to stay in the loop to approve money leaving an account.
Underneath the blocking is a bigger fear the industry has started naming out loud: automated deposit flight. If millions of "financial optimization" agents are authorized to move money, they could all chase the best advertised rate at once and drain deposits from a bank in minutes - a bank run at machine speed, with no human deciding to run.
Why this is an agent-design failure, not a bank overreaction
It is tempting to read this as incumbents resisting automation. It is not. Every control the banks are reaching for maps directly to something the agents are missing by design.
- No identity. The agent logs in as the user with shared credentials, so there is no way to know a bot is acting, who built it, or what it is allowed to do. An agent with no identity is just a stranger with your password.
- The "trust wall." Because consumer agents browse the site exactly like a human and never declare that they are automated, the bank's systems have to assume the worst. An agent that hides that it is an agent will get treated as an intruder.
- Over-permissioned access. Handing over a password grants full account access - read everything, move anything - when the task needed read-only balances or a single, bounded transfer.
- No human in the loop. The whole value proposition of these agents is that they act without you. For irreversible, high-stakes actions like moving money, that is exactly the wrong default.
None of this is new. It is the Hugging Face agent breach lesson - monitor behavior, enforce least privilege, keep a human on irreversible actions - transposed from a research lab onto your checking account.
An agent that logs in with your password and hides that it is a bot is not an assistant to the bank. It is an attacker that happens to be on your side.
The fixes the industry is converging on
The encouraging part is that the response is not just "block everything." The same week banks were slamming doors, the rest of the industry was building the doors that should have existed:
- Declared agent identity. Platforms are starting to give agents first-class identities - Microsoft's Entra Agent ID is one example - so a system can tell a known, governed agent from an anonymous bot. We dug into how the major clouds are approaching this in our teardown of enterprise agent platforms.
- Scoped, read-only access over shared passwords. Verified open-banking standards let an agent get narrow, revocable permissions - see balances, maybe initiate one approved payment - instead of the keys to the whole account.
- Human-in-the-loop for money movement. A living person signs off before funds leave. Boring, and exactly right.
- Liability that follows the builder. In early October, Senators Josh Hawley and Chris Murphy introduced the proposed AI Agent Accountability Act, which would put civil and criminal liability on the developers and operators of agents that behave recklessly or break into systems. It is a liability framework, not a banking rule, and still just a proposal - but it signals where the accountability is heading, in the same push that followed the Hugging Face incident.
It also rhymes with the hardware-level move we covered in this week's Signal / Noise digest: oversight for agents is being built into the platform, not bolted on after the fact.
What to do if you build agents
You do not have to be a bank for this to apply. The moment your agent touches a system someone else owns - a payment processor, a CRM, a customer's inbox - you inherit this problem.
- Never ask users for their raw credentials. Use scoped tokens or OAuth, request the narrowest permissions the task needs, and make them revocable.
- Declare your agent. Identify your automation to the systems it touches. Hiding that you are a bot is how you get classified as an attack.
- Keep a human on anything irreversible. Money, deletions, external messages, legal commitments - gate them behind an explicit human approval.
- Expect to be blocked, and design for it. If your agent behaves like a credential-stuffing script, it will be treated as one. Build on sanctioned integrations, not on screen-scraping someone else's login.
If you are putting AI agents anywhere near real accounts, payments, or customer systems, tell us the workflow - we will give you a straight read on the identity, permissions, and human-in-the-loop design it needs before it ships.