Banks Are Blocking AI Agents. Here's What Payment Builders Should Learn
Top U.S. banks are restricting AI agents that log in as customers. Why this is an identity problem, and how scoped access can fix it for payments.
This week Axios reported that some of the biggest banks in the U.S., including JPMorgan, Bank of America and Morgan Stanley, are restricting third-party AI agents. The reason: they found agents working inside customer accounts. Some of those agents logged in with the customer's own credentials, against the banks' rules. Some called support lines or took actions the user never asked for.
The response so far is defensive. Morgan Stanley is blocking third-party agents. JPMorgan, Bank of America and Citi are restricting them, and most banks are moving toward read-only access.
One detail in the story stayed with me. Most of the cases involved agents the user had actually approved, not hackers. But one bank executive said they are struggling to tell the two apart. For me, that is the real headline.
This is an identity problem, not an AI problem
When an agent logs in with your username and password, the bank sees you. It has no way to know that software is acting for you, what you asked it to do, or where your permission ends. So a helpful agent and a malicious one look the same from the bank's side.
That is not a model problem. A better model would still be logging in as a human. The problem is that we gave agents the wrong kind of key. A password says "I am this person." What we need is a credential that says "I am an agent, acting for this person, and I am allowed to do these specific things."
Payments already solved a version of this
I work on payment infrastructure at Payabli, building embedded payment components, partner and customer portals, and features like tokenization, ACH and digital wallets. A lot of that work comes down to one idea: never pass around the real secret when a scoped stand-in will do.
Tokenization is the clearest example. A merchant does not need the card number to charge a returning customer. It gets a token that only works in a specific context and can be revoked. Virtual cards follow a similar logic: a card that exists for one purpose, with limits.
Agents need the same treatment. Giving an agent your banking password is like giving a merchant your raw card number and hoping they only charge what you agreed to. We stopped doing that in payments for good reasons.
Read-only first is the right default
I also build AI-assisted workflows, including dispute handling and internal integrations that use MCP servers and agents. The way I think about it: MCP gives an agent access to a system, and a Skill gives it the know-how to use that system well. You usually want both. But access is the part that can hurt you, so that is where I start being strict.
The banks moving to read-only access are doing what I would recommend to any team. Let the agent read, gather context, summarize and prepare. Keep the actions that move money or change data behind a separate, explicit step. If you expose read tools and write tools through the same door with the same permissions, you have already made the decision that the banks are now trying to undo.
"Acting beyond instructions" is usually not the model being evil. It is the model being too helpful with too much access. You fix that with boundaries, not with better prompts.
What a better framework could look like
Blocking agents buys time, but it will not last. Customers want agents to handle boring financial tasks, and that demand will keep growing. So what should the cleared path look like? From a builder's point of view, I would want at least these pieces:
- Agent identity. The agent presents its own credential, separate from the user's login, so the bank always knows when software is acting.
- Scoped, revocable permissions. Specific actions, amount limits and an expiry date. The user can see and cancel them at any time.
- Human confirmation for money movement. Moving funds or making a purchase should trigger a confirmation in the bank's own interface, the same way a wallet payment asks for Face ID before it goes through.
- An audit trail. Every action tied to the agent, the user and the permission that allowed it.
That third point is where frontend work matters more than people think. The confirmation screen is the last line of defense. If it is vague, the user will approve things they do not understand. It has to say clearly what the agent wants to do, how much, and to whom, in plain language.
What I take from this as a builder
If you are building agents that touch financial systems, do not design them to log in as the user. That path is closing, and it should close. Design for scoped access from day one: read tools first, write tools behind confirmation, every action traceable.
The banks are not saying no to agents forever. They are saying no to agents they cannot identify. The teams that build the identity and permission layer properly will be the ones agents are allowed to work with when the doors open again.