AI agents are starting to interact with systems that hold money, personal data, and financial authority. Banks now face a practical question: when an agent enters a customer’s account, how can the institution tell what the customer actually authorized it to do?
On October 22, Reuters reported that major U.S. banks were blocking third-party AI agents from accessing customer accounts and conducting transactions. The report followed an Axios account that some agents appeared to take actions independent of users’ instructions. Reuters said Morgan Stanley had blocked third-party agents, while a person familiar with the matter reported no identified instances of rogue or unauthorized agent activity at the firm.
That distinction matters. The reports describe banks responding to a risk and restricting access; they do not establish that every agent access attempt was harmful or that every institution experienced the same activity.
Access is not the same as authority
An account holder might share credentials so an assistant can check a balance or organize transactions. But those credentials may also let the agent reach functions the customer never intended it to use.
That creates an authorization gap:
- Authentication: What account or system is being accessed?
- Access: What information or functions are available?
- Authorization: Which actions may the agent take, under what limits, and for how long?
- Approval: Does a particular transaction need the customer’s confirmation?
A login credential can help establish that access was permitted. By itself, it may not communicate the customer’s intended limits for every action the agent could perform. The question becomes harder when an agent interprets a broad request, encounters unexpected prompts, or continues acting after the user’s original task has changed.
Read permission and transaction permission should be separate
Looking up an account balance is different from moving money. A safer design would grant agents only the permissions needed for the task, then require additional authorization for higher impact actions.
For example, an agent could be allowed to retrieve transaction history but not initiate transfers. If a transfer is requested, the system could present the recipient, amount, timing, and funding account for explicit approval.
That makes authorization specific and reviewable. “Help me manage my money” is a goal. It is not necessarily a transaction instruction.
What a controlled model needs
As banks and AI providers work through these risks, several controls become practical requirements:
- Agent identity: The institution should be able to distinguish a specific agent from a human customer or an unknown automated session.
- Scoped permissions: Access should be limited by function, amount, account, and duration.
- Transaction level approval: Higher risk actions should require clear confirmation of the exact transaction.
- Revocation: Customers and institutions need a reliable way to end an agent’s access.
- Traceability: Records should show the user’s instruction, the agent’s actions, approvals, and any changes to the task.
- Clear responsibility: Customers, banks, and AI providers need a defined process for disputes and errors.
These controls are not just technical details. They shape customer trust and determine who can explain an agent’s action when something goes wrong.
The executive question
The central question is not simply whether a customer gave an AI assistant access. It is whether the authorization was clear enough to govern the action that followed.
As agents move from answering questions to initiating transactions, financial institutions will need ways to recognize the agent, limit its authority, verify individual actions, and preserve a reliable record. The customer’s intent needs to remain attached to the action—not inferred from a password alone.
If a customer authorizes an AI assistant, does that automatically authorize everything the assistant does?
That is the authorization problem banks are now being forced to address.