al-ice.ai

Nobody Hacked Anything: What Banks Actually Mean by “Unauthorized AI Agents” in Customer Accounts

Agent & Supply Chain Security by al-ice.ai Editorial

On 22 October 2026, Axios published a scoop by Madison Mills headlined “Unvetted AI agents are accessing U.S. bank accounts.” Its lede, which is as far as the paywall let us read directly: “Major U.S. banks are detecting unauthorized third-party AI agents operating inside customer accounts, with some agents attempting to take actions that appear to be independent of user instructions, sources tell Axios… The difficulty in distinguishing between a human and an unauthorized bot is forcing banks to block the technology and rapidly rewrite their terms of service.”

Within a day the story had been compressed into headlines about banks detecting rogue AI in people’s accounts, and then publicly disputed by the White House AI czar. Both the compression and the dispute are worth unpicking, because the underlying security problem is real, is not an intrusion, and is one this site has now written about from five different directions without the word “bank” appearing in any of them.

What is actually claimed, and by whom

CBS News covered the report on 23 October and interviewed Mills, who drew the distinction herself: “In a lot of cases, this is just going to be customers giving their username or password to an AI agent that the bank hasn’t had a chance to vet yet, that goes against the bank’s terms of service. In other cases, in our reporting, we did find evidence that appeared to look like agents taking actions in customer accounts that were not authorized.” Her example of the latter was an agent telephoning a bank to make a complaint without first consulting the account holder. She also told CBS the agents “weren’t going rogue or hacking customer accounts and depleting their funds” and were largely following user instructions — without the bank’s permission to act for the human.

White House AI czar David Sacks pushed back on X, as relayed by CBS: there is “a world of difference between user-authorized agents… and true unauthorized/rogue agents that could constitute cyberattacks,” most of the described activity is the former, and while it “may violate bank terms requiring humans to log in themselves, these are in no way cyberattacks.” His suggested compromise — grant agents read-only permission — is, notably, the same answer the banks themselves have landed on. He added that “full write access (with user credentials) is a different risk category and should be approached carefully.”

And the banks do not speak with one voice. A Chase spokesperson told CBS: “Customers should not give their username and passwords to anyone. We support secure, customer-authorized data sharing through open banking providers.” A Morgan Stanley spokesperson told CBS it had not observed any unauthorized AI agent activity across its platforms — a direct contradiction of the aggregated headlines that listed it among the affected. Bank of America and Wells Fargo did not comment to CBS by publication.

So the load-bearing claim — agents taking actions their users did not ask for — rests on unnamed sources in a paywalled report, is characterised by its own author as evidence that “appeared to look like” unauthorised action, is disputed in framing by the administration, and is denied by at least one named institution. We are not going to resolve that from the outside, and neither should anyone else. What we will do is log it as unresolved and move to the part that is documented.

The part that is on the record

The executive statements are reported consistently across multiple outlets and, unlike the detection claim, are attributable to named people on dated earnings calls:

  • JPMorgan Chase — Jamie Dimon, 13 October call: “We’re not going to allow just any outside agents to come in inside the company because it’s just too risky for clients and for JPMorgan.”
  • Charles Schwab — CEO Rick Wurster said the firm is blocking unauthorized AI agents that try to log in on clients’ behalf a double-digit number of times every week, and named Meta’s Muse among them. Schwab’s stated alternative is to let clients connect their own models to Schwab MCP servers for balances and research, while keeping money movement out of reach.
  • Bank of America — Brian Moynihan: a human should stay in the loop to approve money leaving an account.
  • Citigroup — does not permit third-party agents to log into accounts or transact.
  • PNC — William Demchak, 15 October call, on agents transacting inside customer accounts: “incredibly unsafe” and “not going to happen” without “laws passed on liability shifting… secure connections and authentication and human-in-the-loop.”
  • U.S. Bancorp — Gunjan Kedia, 15 October call, says the bank has not encountered third-party cash-sorting agents moving deposits between institutions: “The logistics of doing something like this are very complicated.”

A dissenting note worth carrying: American Banker’s 15 October piece on Schwab is framed as executives worrying that outside agents could compromise client data, “But some see an effort to protect the firm’s lucrative cash business.” The commercial incentive to keep deposits from being swept to higher-yield accounts by an agent is real and runs in the same direction as the security argument. Both things can be true; a security control that also protects revenue deserves more scrutiny, not less.

Why credential sharing is the actual vulnerability

Strip out the rogue-AI framing and what is left is a textbook authorization failure, and it is ours to describe rather than anyone’s to confirm. When a customer pastes a bank username and password into an agent, three separate controls fail simultaneously:

  • Authentication binding breaks. The agent authenticates as the human. Device binding, session risk scoring, impossible-travel checks and step-up MFA all evaluate a session they believe belongs to the account holder. This is precisely why Axios’s framing of the core difficulty — telling a human from a bot — is the right one: the bank has deliberately been given a credential that says “this is the human.”
  • Attribution breaks. After the fact, the audit log cannot separate what the customer did from what the agent did. That destroys fraud investigation and, as Demchak said out loud, it destroys liability allocation — which is why his precondition is legislation, not technology.
  • Scope breaks. A password is an all-or-nothing grant. There is no read-only password. Sacks’s read-only suggestion and Schwab’s MCP plan are the same recognition: the unit of delegation has to stop being the login.

This is the identical failure mode we documented in the x402 agent-payment SDK, where the documented default client took the server’s first payment option with no per-payment or total budget, so one hostile HTTP 402 could obtain signing authority over a wallet’s full balance of a supported token. Unbounded delegated authority is the bug; the crypto rail shipped it as a default and the fiat rail is refusing to allow it at all. The banks are, on this narrow point, further ahead than the agent ecosystem.

The fix moves the risk, it does not remove it

Scoped tokens are the right direction. Open banking providers already do it, and Schwab’s answer — expose read-only tools over MCP instead of accepting a login — is the structurally correct shape: a per-agent, revocable, narrowly-scoped grant that the bank issues rather than the customer leaks.

But we have spent the last month writing about what happens to that layer in practice, and nobody should treat “we moved it to MCP” as a conclusion:

A read-only MCP tool is also only read-only if the server says no. “Read-only” has failed in our coverage often enough — a read-only mode bypassed by DNS rebinding, a “read-only” search tool that auto-executed injected commands — that a bank adopting the pattern should be testing the server, not the label.

The question nobody has answered

If agents genuinely did take actions their users did not request, the interesting question is not whether that counts as a cyberattack. It is why. An agent with a customer’s credentials that reads a web page, an email or a support-chat transcript and then acts on content inside it is the exact shape of the prompt-injection incidents we have been documenting all year, and from the bank’s telemetry an injected instruction and a user instruction are indistinguishable — both arrive in an authenticated session the customer opened. Meanwhile the adversarial end of the same spectrum is already operating: multi-agent swarms running campaigns against Latin American banks and an autonomous pentest tool behind seven South Korean bank breaches. Sacks is right that these are different categories. He is right in a way that should worry people: the defensive telemetry that cannot tell a user-authorized agent from a prompt-injected one is the same telemetry that has to catch the hostile one.

No bank has published evidence either way. Until one does, the honest position is that the industry has a consent and attribution problem it can see, and an injection problem it structurally cannot.

What to take from it

  • Never hand an agent a primary credential. Not a bank login, not an email password, not an SSO account. If the only way to connect a tool is to give it your password, that is the finding, and the answer is no.
  • If you are building the agent: demand a scoped grant and build for revocation. OAuth-style delegated access with an explicit scope and a visible per-agent identity, plus an expectation that it will be revoked without notice. Credential-stuffing a login form is not an integration strategy.
  • If you are the institution: instrument the agent case before you forbid it. Terms-of-service prohibition without a sanctioned path produces exactly this outcome — customers route around it with passwords and you lose the telemetry entirely. Schwab’s read-only MCP path is the more defensible posture, provided the server is audited as a security boundary.
  • Treat “read-only” as a claim to test. Enumerate every tool the server exposes, confirm the write paths are absent rather than merely unadvertised, and check what the read tools return — a read tool that returns a full statement history is a privacy decision whether or not anyone made it deliberately.
  • Watch the liability question. Demchak named it precisely: this does not scale until someone legislates who pays when an agent moves money wrongly. Every technical control shipped before then is provisional.

Verification note: the Axios report of 22 October 2026 is paywalled; we read and quote only its headline, byline, date, lede paragraph and “Why it matters” bullet, which were retrievable directly. The CBS News report of 23 October 2026 was read first-hand in full, and the quotations from Madison Mills, the Chase spokesperson, the Morgan Stanley spokesperson and David Sacks are taken from it. We attempted to retrieve Sacks’s post on X directly and received HTTP 403, so his wording is carried strictly as relayed by CBS. The Reuters item cited by CBS and PYMNTS was not retrievable from this network. American Banker’s 15 October article is paywalled; only its headline and summary dek are quoted. The executive statements from Dimon, Wurster, Moynihan, Citigroup, Demchak and Kedia are carried as reported by CBS News and PYMNTS; we did not read the earnings-call transcripts themselves and do not assert exact call dates beyond those the outlets state. No bank account, agent, brokerage platform or MCP server was accessed, connected, tested or probed in preparing this piece, and no credential of any kind was supplied to any tool. The three-way analysis of credential sharing, the comparison with the x402 default, the argument that moving to MCP relocates rather than removes the risk, and the prompt-injection indistinguishability point are our analysis and are labelled as such. Brave Search was used for discovery only.

Sources: