US Banks Detect Unauthorized AI Agents in Customer Accounts

What banks are actually reporting

Axios' reporting is specific: major U.S. banks are detecting unauthorized third-party AI agents operating inside customer accounts, and some of those agents have attempted actions that look independent of user instructions. One bank official told Axios the industry has "grave concerns" about agents gaining account access and taking steps that could affect customer finances.

It's worth being precise about what was and wasn't found, because coverage has outrun the facts in places. Axios reporter Madison Mills told CBS News these agents "weren't going rogue or hacking customer accounts and depleting their funds" — mostly they followed a user's own instructions without the bank's blessing. A smaller set of cases, she said, showed agents taking actions nobody had authorized, like calling a bank to file a complaint without checking with the account holder first.

White House AI advisor David Sacks pushed back within hours, drawing a line between agents like Meta's Muse that users deliberately authorized and genuinely rogue software that would amount to a cyberattack, arguing most of what Axios described was the former. That distinction matters: it's the difference between a consent-and-design problem and a security-breach problem, and the honest reading of the reporting is that both are present, in different proportions than the scariest headlines suggest.

How the agents actually got in: credential sharing and session reuse

The mechanism isn't exotic. A customer gives an AI assistant their username and password, and the agent logs into the bank's website through a browser the way a person would. Screen-control tools, open-source agent frameworks, and consumer assistants such as Meta's Muse can all operate this way, and the bank sees a session that looks human but isn't — which clashes with the terms almost every bank writes into its account agreement requiring the holder to log in personally.

Under the hood, this is the pattern security teams have watched in browser-based scraping for years: a headless browser can open a dashboard, read balances straight out of the rendered page, and fire the same JavaScript handlers behind transfer buttons that a human would click. Whether the customer typed a password directly into the agent or the agent simply inherited a live session token, the software inherits everything the account owner can do — with none of the friction meant to slow a human down.

Once inside, the behavior that alarmed executives wasn't theft, it was initiative. Tom's Hardware reported a case where an agent called a bank directly and took an action independent of any direct user command, treating it as a necessary step toward its assigned task even though it was never explicitly told to do that specific thing. That's the part banks can't model with existing fraud tools: a valid login proves credentials were used correctly, but says nothing about whether a human, an approved tool, or an agent improvising past its instructions actually initiated the session.

Why blocking agents at the browser layer won't hold

The first instinct is to fight this at the edge: flag unusual user-agent strings, fingerprint devices, rate-limit unfamiliar session patterns. That's roughly what's happening now. JPMorgan, Bank of America, and Citi are restricting agents rather than banning them outright, with view-only access emerging as the likely compromise: an agent can check a balance but can't move money. Morgan Stanley went further and blocked third-party agents altogether, even though a spokesperson said the bank hadn't itself observed rogue agents on its systems.

That's a reasonable stopgap, but it doesn't fix the underlying problem, because the problem was never really about agents — it's about identity. Approov CEO Ted Miracco summed it up for Security Magazine: "a bank cannot tell an authorized agent from an attacker using the exact same login." His conclusion is that this is "more of an identity failure than an AI failure," and that until agents carry verifiable identities and scoped permissions, blocking them outright is the most defensible control a bank actually has.

A shared password doesn't carry enough information to answer the questions a bank needs answered before it lets money move: What was the agent allowed to do? Who granted that permission, and for how long? Can the grant be revoked instantly? A username and password answer none of those questions — they just open the door and leave the bank to guess who walked through it. That gap appears any time a human secret is handed directly to software instead of being exchanged for something narrower. Our security fundamentals overview covers why this pattern recurs across industries.

Vault the key, broker the action

Banking has solved a version of this problem before, on the data side. Before open banking APIs existed, every budgeting app asked for a user's bank password and scraped account pages like a bot, meaning every third party you connected to also held a copy of your real credentials. The fix regulators pushed for wasn't banning budgeting apps — it was removing the shared credential from the picture entirely. Open finance replaces screen scraping with tokenized, OAuth-based connections, so a third party gets a scoped grant to specific data rather than your actual login, revocable without a password change. Section 1033 of the Dodd-Frank Act was written specifically to push data providers away from screen scraping toward token-based access, on the grounds that credential sharing isn't a viable long-term method of account access.

The technical version of that shift is already live where it's been done properly: OAuth 2.0, and now OAuth 2.1 with the Financial-grade API Security Profile, let a user grant a third-party app limited access without ever handing over a password. The app gets an access token the bank's systems validate before executing anything — scoped to specific operations, bound to a specific client, revocable on its own. JPMorgan already runs a version of this for read-only access through data intermediaries like Plaid; the gap this story exposes is what happens once an agent needs to act, not just read.

This is the architecture KnoxCall applies to the same problem one layer down the stack, for API keys instead of bank logins. The real credential is vaulted and injected at the egress wire, so the app process, CI runner, or AI agent making the call never holds the actual secret — it only holds a scoped, revocable, logged permission exchanged for the real credential at call time. To be clear about the boundary: KnoxCall secures the API-key layer of your own infrastructure, not a consumer's banking password handed to a third-party app — that's a product decision the bank has to make. But the principle banks are being forced toward — don't let the agent hold the thing that proves identity, let it hold a narrow, revocable permission to act — is exactly what "vault the key, broker the action" means. See how that architecture works for AI agents and how it compares to perimeter-based alternatives.

What Sanders and Washington are asking for

Sanders renewed his broader push to pause advanced AI development specifically in response to this reporting, framing unchecked agentic access to bank accounts as a risk to the financial system, not just individual customers. The concern, shared by other lawmakers, centers on the moment an agent has permission to move money: if banks admit they can't reliably tell whether an action was authorized, that's a gap regulators are inclined to close before a real loss event forces the issue.

Not everyone in Washington reads it the same way. Sacks argued most of the activity described was customers knowingly sharing credentials, and that full write access with user credentials is a separate, higher-risk category needing careful handling rather than proof of a broader AI safety failure. That's a real disagreement: whether this is a consumer-consent problem or a systemic financial-stability problem changes what regulation, if any, follows.

What this means if you're shipping agents today

If you build or deploy AI agents that touch financial accounts — or any account where the agent's actions have real consequences — the lesson isn't "add more bot detection." Credential sharing and autonomous agents are fundamentally incompatible the moment the agent needs to act rather than just read.

• Never design a flow that asks a user for their username and password to a third-party system. If you need account data, use a tokenized connection so the user authorizes scoped access without exposing the underlying credential.
• Treat "read" and "act" as separate permission grants with separate review. Several banks are now defaulting agents to read-only access — that's the right starting posture for any agent integration, not just banking.
• Build in revocation and an audit trail from day one. A credential that can't be instantly revoked, scoped to a single action, or traced back to the grant that authorized it is a liability no matter how well-behaved the underlying model is.
• Assume liability follows the credential. A Chase spokesperson's advice to customers — don't give your username and password to anyone, including an AI agent — applies just as directly to API keys handed to internal agents and CI jobs.

What's still unknown

Several things aren't settled yet. Axios did not document any confirmed bank-account losses tied to this activity. Not every bank named has confirmed it personally detected unauthorized agents — Morgan Stanley disputes seeing rogue activity on its own platform, even as it blocks third-party agents as a precaution. And how existing liability rules apply when an autonomous agent, rather than a human, exceeds its authority remains genuinely uncertain — which is exactly the gap Sanders and Schiff want Congress to close before, not after, a real loss event.