AI Agents Need Authorization, Not Your Banking Password

Four of the largest US financial institutions, JPMorgan Chase, Bank of America, Citi and Charles Schwab, have moved to restrict outside AI agents from accessing customer accounts.

It's easy to read this as banks versus AI. But look at what they're trying to prevent: agents logging in with a customer's own credentials and operating as if they were the account holder. The bank can't reliably distinguish the agent from the customer, limit its actions independently or revoke its access without interfering with the customer's own access.

JPMorgan CEO Jamie Dimon raised concerns about the potential for thousands of rogue agents. Meanwhile, banks are exploring ways to support controlled access. Charles Schwab has discussed using MCP servers to let customers' AI models retrieve information under the bank's rules, while Bank of America has emphasized human approval for transactions that move money.

The issue isn't whether agents should access financial services. It's how that access is authorized and controlled.

Give agents authority, not customer credentials

Consider an agent tasked with reviewing account balances and recommending how a customer could manage their savings.

It needs access to financial information. It doesn't need permission to transfer money.

When an agent operates through the customer's login session, those boundaries become difficult to enforce. The agent may inherit permissions that have nothing to do with its task.

OAuth-based delegated authorization was designed to solve exactly this problem. Instead of sharing credentials, the customer authorizes an application to access specific resources. Access tokens can be restricted by scope, audience and lifetime, with the receiving APIs enforcing the permissions granted.

The Curity Identity Server provides the OAuth and OpenID Connect capabilities to support this model. OAuth 2.0 Token Exchange also allows organizations to issue new, more restricted tokens as requests move between services. In a delegation scenario, the exchanged token can carry an act claim identifying the agent acting on behalf of the customer, alongside the customer represented as the token subject. This gives APIs the information needed to distinguish the two actors.

An agent can therefore receive access appropriate to a particular task without carrying the customer's full privileges through the system.

Moving money is a different matter

Reading an account balance and transferring $5,000 are not equivalent operations. They shouldn't be treated as such by the authorization system. An agent might be allowed to retrieve balances, analyze transactions and prepare a payment. Actually moving money should require a separate authorization decision and, where appropriate, explicit customer approval.

We already have standards that help address this.

Rich Authorization Requests (RAR) can describe specific operations and their parameters, rather than relying only on broad permissions. Client-Initiated Backchannel Authentication (CIBA) provides a way to authenticate a customer through a separate channel, such as their banking application.

The Curity Identity Server supports CIBA and standards-based delegated access, providing building blocks for these authorization flows. Transaction-specific controls must still be enforced by the financial institution.

The agent can prepare the transaction. The customer approves it. The bank enforces the decision.

The authorization gap is real, but so are the solutions

The banks' concerns are legitimate. Giving autonomous agents unrestricted access to financial accounts creates security, fraud and liability risks. Protecting deposits is likely part of the motivation too, since agents could sweep idle cash into higher-yielding accounts. But the security and liability questions would exist either way, and blocking agents that use customer credentials doesn't mean blocking agent-based financial services altogether.

Open banking has already established a model for third-party access without credential sharing. AI agents introduce more complex interactions, but the underlying authorization requirements are familiar.

An agent needs its own identity, separate from the customer's, and that identity should exist only for the task at hand. Its permissions need to be delegated, limited, short-lived and revocable. Sensitive operations need additional controls. And the authorization context needs to establish which actor performed an action and on whose behalf.

When an agent acts on behalf of a customer, the bank needs more than evidence of a successful login. It needs to know who is acting, under whose authority, and what they were permitted to do.

That doesn't settle every question of liability. But it gives financial institutions a much better place to start.