Somewhere in a US bank's fraud stack this week, a session opened with a valid username, a valid password, and a valid one-time code. Every check passed. The problem is that no human was behind it.
Axios reported on 22 October that major US banks, Morgan Stanley, Bank of America, JPMorgan and Wells Fargo among them, are detecting third-party AI agents operating inside customer accounts. In most cases the customer handed over their own credentials, which is exactly what every bank's terms of service forbids. Some agents have called support lines. Some have taken actions that look independent of what the user asked for. Executives used the word "horrifying."
Read that again. The credentials were real. The consent was real, at least at the start. And the bank still had no way to answer the only question that matters at 2am: did the account owner authorise this specific action?
The problem was never authentication
We spent twenty years making login hard to fake. Passwords, then MFA, then passkeys. All of it answers one question: is this person who they say they are?
Agents break that question in half. The login is genuinely the customer. The action may not be. And once an agent holds a session token, it looks identical to a very fast human, except it can act at machine speed and it never gets tired or suspicious.
Banks are now stuck with a control gap they cannot patch with better MFA, because the human part already succeeded. What is missing is a way to bind authorisation to a specific action, not to a session. That is not an authentication problem. It is an authorisation and attribution problem, and most organisations outside banking have the same hole.
What banks are doing right now
The first response is blocking. Morgan Stanley has started refusing third-party agents access to its platforms. JPMorgan, Bank of America and Citi are restricting them. Chase's line is blunt: never give your username and password to anyone.
The second response is narrowing the aperture. Most banks are moving toward read-only access, the same model that already lets budgeting tools like Quicken see balances without moving money. Read is a fundamentally smaller risk than write, and banks know it.
The third response is scenario planning. Several institutions are rehearsing the day after an incident: how to lock a customer out fast, how to restore access, how to prove what happened. That is a mature instinct, and it is also an admission that prevention alone will not hold.
Why attribution is the hard part
Here is the uncomfortable detail in the Axios report: many banks cannot parse whether agent activity was user-directed at all. They struggle to tell one agent from another, let alone whether a given agent had permission or simply had credentials.
That is a design defect, not a staffing one. If your only record of an action is "authenticated session performed transfer," you have no evidence trail. You have a timestamp.
Contrast that with what an agent-aware control plane would log:
- Who the agent is: a registered client identity with its own key, not a borrowed human session.
- What the human asked for: the actual instruction, captured at the point of intent.
- What scope was granted: a narrow, action-level permission with an amount cap and an expiry.
- What actually happened: the executed action, correlated to the grant that allowed it.
With those four records, a bank can answer the 2am question in seconds. Without them, it can only guess, and guessing means blocking everything.
What this means outside banking
If you run payroll, invoicing, procurement, CRM or infrastructure, the same pattern is already in your stack. An assistant or an agent that holds a long-lived credential can do everything that credential can do. We wrote about exactly this failure mode yesterday, after LiteLLM shipped a credential stealer to PyPI and put live tokens in front of anyone who installed it.
The lesson repeats because the architecture repeats. Agents are being given human credentials because it is easy, and human credentials are all-or-nothing.
A better shape looks like this:
- Separate identity per agent. A service account or OAuth client with its own key, revocable without touching a human's login.
- Scoped, short-lived grants. Read-only by default. Write access granted per action type, with limits and an expiry measured in minutes, not months.
- Consent captured at the moment of action. If the agent is about to move money, the human approves that transfer, not "the agent can use my account."
- An audit trail that names the grant. Every consequential action should point back to the permission object that authorised it, so a reviewer can replay the decision.
- Kill switches that do not require a password reset. Revoke the agent, keep the human working.
None of this is exotic. It is ordinary authorisation design, applied to a class of client that did not exist when most of these systems were built.
The takeaway
The awkward truth in the banking story is that the agents were not breaking in. They were being let in, with real credentials and real user intent, and the institutions had no language for the difference between "my customer asked for this" and "something with my customer's session did this."
Every organisation deploying agents is about to need that language. Start by assuming your agent will one day do something you did not intend, and design the log you would want to read the next morning. If you can't answer who authorised an action, what scope it had, and what it touched, you don't have agent security yet. You have an agent and a hope.
If you are mapping agent access across your stack and want a second set of eyes on the permission design, that is exactly the work we do at aratech.