Banks aren't wrong to block AI agents, but the password is the problem.

What happened this week

Major US banks have been blocking third party AI agents from operating inside customer accounts, according to a Reuters report on October 22, 2026. Morgan Stanley has blocked outside agents from its platforms, Schwab's CEO said his firm blocks unauthorized agents, and Jamie Dimon said earlier this month that JPMorgan won't let just any outside agent in, because it's too risky for clients and for the bank.

The same report cites an Axios story saying some agents tried to take actions that looked independent of what their users asked for. That claim rests on unnamed sources, so I'm not going to build on it. The detail that matters more is quieter, and it sits in the middle of the Reuters piece.

Why blocking is the right call today

Some customers give an agent their login and password. Reuters reports that banks usually flag and block those transactions, but they can't treat them as unauthorized, because the customer handed over the credentials.

For electronic fund transfers from consumer accounts in the US, that follows from Regulation E. A transfer made by someone the customer furnished their access device to, meaning a card, code or other means of access, isn't an unauthorized transfer unless the customer has told the bank that transfers by that person are no longer authorized (12 CFR 1005.2(m)). The rule assumes the bank can tell that person apart from the customer. A shared password removes exactly that.

Think about what that means from the bank's side. An agent holding your password is you, so the bank can't tell which agent is acting, can't limit what it does, and can't shut off one agent without locking you out too. When something goes wrong, there's no record of what you actually agreed to, only a login that looks like yours.

So I don't read this as banks being against AI. They're refusing to take on a liability they can't measure, and when shared passwords are the only door, that's the correct decision.

What a bank needs before it can say yes

For a bank to let agents in, four things have to be true at its own front door:

1. It knows which agent is acting. Not a session that looks like the customer, but a distinct identity the bank can recognize, rate limit, and refuse.
2. It knows what the customer allowed. A specific grant, like paying these three billers up to $500 a month until March, rather than everything a password unlocks.
3. It enforces the limits itself. The bank checks every action against the grant, so the agent behaving well isn't the control.
4. It keeps a record that holds up. Which agent, under which grant, did what, and whether it was in scope. That's what settles a dispute.

Underneath all four, the customer can revoke one agent without changing their password or touching any other agent they use.

What you can do today

You don't have to wait for standards to finish. Several of the pieces exist now, and most of them are open source.

If you run security at a bank or credit union

Start by writing down what an agent would have to satisfy to get in. OASB-1 is an open benchmark of 46 security controls for AI agents at three maturity levels, and it works as a checklist for an agent channel the same way you'd use a baseline for any new integration. Ask any agent vendor for their result; HackMyAgent produces it in one command, npx hackmyagent secure -b oasb-1. And ask every agent vendor at your door one question: does your agent ever hold our customer's password? If the answer isn't no, the conversation is over. Map your current blocking decision to the Agent Threat Matrix so your board hears technique names instead of "AI risk."

If you build agents

Stop asking customers for their bank passwords. Where a bank offers an API connection, use it; where it doesn't, that's a conversation to have with the bank, not a reason to collect credentials. Give each agent its own identity and declared capabilities with AIM, so you can tell your agents apart, see what each one did, and shut one off without touching the rest, and you have an identity ready to present when a bank asks for one. Before you ship, point HackMyAgent's attack mode at your agent to see how it handles prompt injection, and break things on DVAA, a set of deliberately vulnerable agents, before you learn the same lessons in production.

If you're an aggregator or fintech in the middle

You've been through one move from screen scraping to APIs already, so you know what this migration looks like. The agent version has the same shape: scoped, revocable grants instead of credentials, plus an identity for the agent on the other end. We want to test our delegation flow against a real connection model, and the mock bank demo we're building is the starting point.

Where the standards work stands

None of these ideas are new to banking. Open banking already pushed account access away from shared passwords toward scoped, revocable tokens, and OAuth rich authorization requests (RFC 9396) were designed to describe exactly this kind of fine grained consent. What's missing is the agent side: a way to say which agent holds the grant, and to keep evidence of what it did with it.

That's what our IETF Internet Drafts cover: agent identity (AIP) and agent authorization (AAP). An AAP grant can carry its limits as RFC 9396 authorization details, but the current draft doesn't yet define a payee list or per payment and monthly amount limits, and our reference implementation doesn't yet write authorization details into the grants it issues. ATX is the signed credential that says who an agent is and what was attested about its build; what the agent may do at a bank is a separate grant. Verification and limit checks run at the bank, against the bank's own policy, with nothing of ours required on the critical path.

They're drafts, not finished standards, and our own spec review found gaps, so we're still hardening parts of the spec. The biggest gap for this use case is proof of possession: AAP already requires what an agent presents to be bound to that agent, but our reference implementation doesn't check that binding yet and the ATX credential doesn't carry an agent key, so today an agent's credential works like a bearer token, and anyone who copies it could use it. That's one of the first things we're fixing, and banks should hold any proposal, ours included, to that bar.

What stays in the bank's hands

Better plumbing doesn't settle the commercial question. Schwab's CEO was candid that part of the reason is control over authentication and the customer experience, and an agent that can move deposits between banks is a business threat as much as a security one. Identity and scoped grants don't make that go away, but they do let a bank open an agent channel on its own terms instead of choosing between an open door and a locked one.

It also doesn't change how banks adopt standards. They'll move through the bodies they already work in, like the Financial Data Exchange and the OpenID Foundation's FAPI work, so that's where we'll bring this, rather than asking banks to come to us.

Next steps

• Bank, credit union, or aggregator security leaders: email info@opena2a.org with "agent channel" in the subject and I'll walk you through the delegated flow against your own requirements. No pitch deck.
• Agent builders: register your agents in AIM, run HackMyAgent's prompt injection tests against them, and tell us what broke. That feedback shapes the drafts.
• Everyone: the Behavioral Threat Report is our monthly read on what agents are actually doing on the wire, drawn from a fleet of decoys we run for this purpose. Subscribe to see the agent banking demo there first.

That's the work: standardizing, through the IETF, how AI agents prove who they are, what they're allowed to do, and what they did. We're also building a working demo of both paths side by side against a mock bank, a shared password agent and a delegated one, and it will land in the report and on this blog first.

Sources

• Reuters, "US banks are blocking third-party AI agents access to customer accounts, sources say," October 22, 2026, as carried by SRN News.
• IETF Internet Drafts draft-fane-opena2a-aap and draft-fane-opena2a-aip.
• RFC 9396, OAuth 2.0 Rich Authorization Requests.
• 12 CFR 1005.2, Regulation E definitions.
• OASB, Agent Threat Matrix, OpenA2A on GitHub.