JPMorgan Chase is drawing a firm line around AI agents accessing customer accounts, particularly when those agents use client credentials to move money. The bank's core concern centers on what software is permitted to do, not merely whether it can connect. JPMorgan already deploys agents internally and plans to extend them to customers, but on its own terms.
The bank's position emerged on October 13, 2026, during the third-quarter earnings call, confirmed in the official JPMorganChase press release. CEO Jamie Dimon and CFO Jeremy Barnum addressed a question that will define financial automation for years: how much control does a customer retain when delegating an action to a software agent?
The Line: Credentials and Money Movement
In the earnings call transcript, Barnum narrowed the problem to services that allow agents to move money through shared credentials and practices like screen scraping. Screen scraping extracts information from a website's visual interface rather than receiving it through a structured connection. The CFO called these methods insecure and said JPMorgan blocks them wherever it can.
Dimon was equally direct: no external agent should be able to move freely through the bank's systems, saying in the call that doing so is “too risky for clients and for JPMorgan.” These statements describe an access-control posture. They don't constitute a comprehensive rulebook for all third-party vendors, a list of approved agents, or a timeline for broad service opening.
Reading a Balance vs. Executing a Payment Are Different Permissions
Chase already documents a pathway for connecting external applications to accounts without sharing a password: the customer authenticates directly with the bank, chooses which accounts to link, and can revoke access at any time. The page also describes the use of substitute account numbers for permitted transactions. Authorized external connections already exist; what they can do depends on the service and the consent granted.
The decisive distinction is between data access and operational authority. An agent might, in one use case, categorize expenses or draft a payment proposal without being able to execute it. An API connection (the interface through which two systems communicate) doesn't automatically guarantee sound decision-making: the critical questions are which operations it enables, on which accounts, and with what confirmation steps. This connects directly to the broader debate around AI agent reliability in delegated tasks.
Bank Access: Three Models to Distinguish
Editorial schema. Sources: JPMorganChase Q3 2026 earnings call of October 13, 2026, and Chase data-sharing documentation.- Bank-built agent. The institution controls the tools and their integration into its own systems. This origin alone does not eliminate the risk of error.
- External agent via authorized APIs. The scope depends on the functions enabled and the permissions granted: sharing data doesn't automatically confer the power to initiate payments.
- External agent using client credentials. The service accesses accounts through the user's own login. This is the model Barnum specifically contested when used to move money.
Security Meets Fintech Competition
The tension between openness and control predates AI agents entirely. On September 16, 2025, JPMorganChase and Plaid announced a renewal of their data-access agreement, according to the official Chase press release, covering a pricing structure and service-continuity commitments. That agreement covers authorized data sharing. It does not establish that an agent can freely execute operations. It is, however, a concrete counterweight to any reading that the bank wants to shut down every external connection.
A competitive tension surfaces here. An assistant that compares services across multiple banks could become a customer's daily financial reference point, with the bank reduced to holding deposits while another platform shapes spending and investment decisions. Protecting access and preserving the commercial relationship can coexist. Doing so will require transparent admission criteria and legible permissions, even when the agent is built by the bank itself.
Liability Doesn't Resolve with a Single Click
Dimon described a transfer of responsibility when customers authorize external tools; Barnum warned that an unwanted action taken after credentials are handed over would fall on the user. These are positions expressed by executives in a quarterly call, not new regulations. From those statements alone, you can't derive a universal rule on refunds or predict the outcome of any dispute.
A hypothetical example clarifies the stakes. Asking an assistant to find a cheaper account does not necessarily authorize it to transfer the balance. If the software takes that step, what needs reconstruction is the chain of instructions, permissions, and confirmations. The delegation should make visible the jump from recommendation to execution. This is the financial dimension of the individual data-control argument Tim Berners-Lee has long advanced, as discussed in our analysis of his data-sovereignty position.
The Bigger Picture
The next fintech battleground may well be who translates human intent into financial operations. Agents can simplify comparisons and reduce friction, but the benefit becomes brittle if the user loses the ability to understand what has been authorized. The same issue runs through the emerging space of stablecoin payments between AI agents: automating value transfer makes defining the mandate more important, not less.
The JPMorgan case offers a practical lens for evaluating future announcements: check who identifies the agent, what powers are assigned to it, and how the customer can stop it. A genuinely useful assistant should leave a delegation that is clear, limited, and revocable. The long-term value of banking automation will depend on whether those conditions survive the shift from software that suggests to software that acts.
