U.S. Banks Block Third-Party AI Agents as Access and Liability Questions Grow

U.S. financial institutions are drawing boundaries around third-party AI agents that try to operate customer accounts. Public comments from JPMorgan Chase and Charles Schwab show that the restrictions were already being discussed before this week’s latest coverage.

The issue reaches beyond whether software can complete a banking task. An assistant needs a recognized route into the account and a clear limit on what it can do once there. A customer’s instruction to an agent does not, by itself, establish that the bank accepts that access method.

At JPMorgan’s 13 October earnings call, chief executive Jamie Dimon said the bank would not admit arbitrary outside agents because of risks to customers and the institution. He also described the bank’s own use of agents, making clear that its position concerns control over deployment rather than a rejection of the technology.

In an independent Bloomberg report published on 16 October, Schwab chief executive Rick Wurster said the company was blocking unauthorized agents attempting to move customer money. His concerns included users handing over passwords and uncertainty about responsibility if an agent made a mistake.

What the latest reporting establishes

Axios reported unauthorized agent activity; Morgan Stanley denied observing rogue agents on its platforms.

Reuters’ 22 October report attributed its account to Axios and explicitly said it could not immediately verify the report. Reuters’ coverage therefore should not be counted as a second, independent confirmation of the underlying incidents.

The distinction matters. Public statements establish that institutions are restricting outside agents. They do not establish the scale of any resulting losses, or show that every blocked interaction involved stolen credentials or criminal intent.

Identification is only one part of permission

Chase’s published terms require agents to identify themselves, label their traffic and answer truthfully when asked whether an interaction comes from a human or software. The bank reserves the right to restrict or terminate their access.

The terms also prohibit circumventing access controls and say users are responsible for agent errors, including unintended actions or activity exceeding the authority they granted. That is the bank’s stated contractual position, not a finding about how liability would be allocated in every dispute.

These requirements illustrate separate questions. Identifying an agent establishes what kind of actor is connecting. It does not establish which account it may use, which task the customer approved or whether a particular transfer falls within that approval.

Consider a hypothetical instruction to compare savings accounts. Reading balances might help complete that task. Moving the balance elsewhere would require a different level of authority. A system that treats both as a single permission leaves too much room for misunderstanding.

Banks already have connected-app controls

It would be misleading to suggest that banks have no mechanisms for managing third-party access.

Chase’s account-linking documentation describes a flow in which customers sign in directly with the bank, select accounts to share and can subsequently revoke an app’s access. The outside app does not receive the customer’s banking password through that flow.

The documentation also describes authorized transactions using substitute account numbers for eligible accounts. Existing third-party connectivity therefore cannot accurately be described as universally read-only. Its capabilities depend on the specific integration and authorization.

Separately, Chase announced a phased rollout of a Data Security Center on 25 September. The bank says it brings together controls for connected apps, permissions, access duration and linked accounts. That announcement describes a bank-managed control system; it does not certify arbitrary personal agents to use banking websites.

For agent developers, the distinction is practical: approved connectivity and unrestricted browser access are different integration models. Building around the former may offer clearer permissions, but the permitted actions still need to be checked individually.

Related coverage: Claude Duet and the approval boundaries for personal AI assistants.

The next test is bounded authority

For AgentsCalling readers, the useful evaluation question is how narrowly an agent’s authority can be defined and enforced.

A controlled demonstration could ask an agent to inspect synthetic account data while denying it permission to change anything. A second stage could permit one simulated payment to a specified recipient, within a fixed limit and time window.

The test would then check whether the system rejects a changed recipient, prevents duplicate execution, stops after permission is revoked and records the instruction behind each action. These are proposed evaluation criteria, not results from testing a bank or agent product.

That approach would measure something a successful login cannot: whether an assistant remains inside the authority the customer intended to grant.

The institutions’ restrictions make that boundary a product requirement. Personal finance agents will need access arrangements that banks recognize and customers can understand, limit and withdraw.

Prepared with AI-assisted research and drafting. AgentsCalling did not access customer accounts, test these controls or conduct interviews for this story.