← Back to Blog

JPMorgan Blocked AI Agents From Your Bank Account. They're Not Wrong.

This week JPMorgan, Citi, and Morgan Stanley moved to block third-party AI agents from customer accounts. It reads like a war on AI adoption. It's actually a rational response to a specific infrastructure gap — and the fix isn't better blocking.

JPMorgan Chase has blocked third-party AI agents from accessing customer accounts. Citi followed with similar restrictions. Morgan Stanley moved to block agent logins outright. Bank of America and Wells Fargo are each drawing their own lines. The official language is measured — Chase says it supports customer-authorized data sharing through approved open banking providers while barring agents that "obtain customers' banking credentials." The practical effect is a wall.

The headlines have framed this as banks going to war with AI. That's the wrong read.

The banks aren't wrong to be cautious here. They're doing the one thing a responsible institution can do when asked to grant access to a class of software whose behavior it cannot evaluate before granting that access. They're saying no.

The Problem Is Structural, Not Adversarial

Think about what a bank is actually being asked to do when a customer wants to connect a third-party AI agent to their account.

A personal finance agent shows up with an OAuth token and a list of permissions it claims to need. It says it will monitor your account, flag unusual charges, and move money between accounts when optimal. The bank has no way to test whether that description is accurate. No independent performance record. No behavioral verification against edge cases. No way to know whether "move money when optimal" will stay within the scope the agent described when conditions deviate from the demo scenario.

The bank's choices are: grant the access and hope, or block and explain. Unauthorized money movement — an agent transacting beyond what the customer intended, or beyond what they understood they were authorizing — is not a theoretical risk. It's the exact category of failure that banks are regulated against, for which they're liable, and for which there is no "the agent misunderstood" defense that the CFPB or a plaintiff's attorney will accept.

The blocking decision is conservative and blunt. It's also, given the available information, correct.

The Regulatory Vacuum Makes It Worse

None of this is playing out in a stable regulatory environment. The CFPB's Section 1033 rule — the framework that would have established how consumers can share their financial data with third-party apps and agents — has been enjoined and sent back for substantial revision. Compliance deadlines are suspended. The rule's eventual form is unclear.

That matters because 1033 was supposed to create a standardized framework for authorized data access: clear consent requirements, liability allocation, technical standards, and a certification path for third-party providers. With that framework in limbo, each bank is improvising its own policy. Some are blocking agents entirely. Some are allowing read-only access through approved aggregators. Some are drawing distinctions between agents that "log in" versus agents that access via token. None of these policies are compatible with each other, and none of them are stable.

The result is that AI agent developers are navigating a patchwork of individual bank policies in an environment where the regulatory answer is "we'll let you know." In that environment, the aggressive blocking decisions aren't surprising. They're the conservative default in the absence of any other framework.

What the Banks Are Really Asking For

Buried in the bank restrictions is an implicit request the industry hasn't answered yet: give us a way to evaluate an agent before we grant it access.

Chase's policy distinguishes between agents that "obtain customers' banking credentials" and agents that access through "approved open banking providers." That's not a ban on agents — it's a requirement for a credentialing layer, a third party that has already evaluated the agent and vouched for its behavior. The bank will trust the voucher if it trusts the vouching entity.

Citi similarly allows read-only access through "approved providers" while blocking direct logins. Wells Fargo's updated agreement imposes use restrictions rather than outright blocks. These aren't institutions that have concluded AI agents are inherently dangerous. They're institutions that have concluded AI agents are currently unverifiable and they'd rather not be the ones running the first verification at scale on live customer accounts.

The thing they're asking for — an independent evaluation of agent behavior before it gets access to consequential systems — is the same thing enterprise procurement teams need before deploying agents internally. It's the same gap that produced the 78% revocation rate in last week's Frontegg survey. Agents get access, behavior turns out not to match the description, access gets pulled after the fact. The banks are simply pulling access before the fact, which is more rational but produces the same result: agents don't get in.

The Verification Layer Is the Missing Piece

The infrastructure the financial sector is stumbling toward has a name. It's pre-deployment behavioral verification: a standardized process for evaluating what an agent actually does — not what the vendor claims, not what the demo showed — under conditions that represent real operational scenarios, including edge cases and adversarial inputs.

For a financial agent, that evaluation would need to cover: Does it stay within the permission scope it declared? What does it do with ambiguous instructions? How does it handle conflicting signals between the customer's stated preferences and a market condition that technically triggers an authorized action? Does its behavior change when account balances are low, when markets are volatile, when the input data doesn't match its training distribution?

None of this requires the bank to run the test itself. It requires a credentialing process where independent evaluators run the agent against controlled scenarios and produce a verified behavioral record. The bank can then make access decisions based on the record rather than the sales deck.

This is, to be clear, not a solved problem. The infrastructure for standardized agent behavioral verification at the task level is early. But the demand signal from the banking sector is now explicit: if you want access to customer financial accounts, you need a verified record the bank can rely on. "Trust us, it worked in the demo" isn't going to move the needle.

The Wall Isn't Permanent — But It Requires Something

The banks blocking AI agents this week are not enemies of the technology. They're describing the conditions under which they'd accept it. The conditions are: give us something to evaluate. Give us a record that wasn't produced by the vendor. Give us a credentialing layer between "agent developer says it works" and "agent operates on live customer accounts."

That's a buildable thing. The regulatory framework will eventually catch up — 1033 will be revised, liability allocation will get clearer, certification standards for third-party data access will emerge. In the meantime, the agent developers who will eventually get inside the wall are the ones building verified behavioral records now, before the framework requires it.

The wall isn't saying agents don't belong in financial services. It's saying unverified agents don't. That's a distinction worth building toward.


Choose your path