US banks shut out AI agents: what it changes when connecting AI to your systems

What the banks announced

The announcements came from executives and from financial press reports over the course of the week:

• JPMorgan Chase (Oct 13): on the earnings call, CEO Jamie Dimon said the bank will not allow outside agents to act inside its systems and warned of "rogue agents". Third-party tools authorized by the customer can still view data, but cannot send money or pay bills.
• Charles Schwab (Oct 16): CEO Rick Wurster told Bloomberg Television that the firm blocks unauthorized agents — including Muse, Meta's personal agent — that try to move client money. According to him, the major agents are blocked in the tens every week.
• Citi (Oct 16): according to the Financial Times, the bank does not allow third-party AI agents to log in or transact on its digital channels, keeping only read-only access through open banking providers.
• Bank of America (Oct 16): also according to the Financial Times, it restricted agents' access to customer deposits while it works out who is liable for AI-authorized payments.

The problem is not the agent, it is the door it comes through

None of the banks is banning AI. What they are blocking is a specific access model: the agent that uses the customer's password and poses as them. To the bank's system, that agent is indistinguishable from the person — it has the same permissions, no limits of its own and no separate record of what it did.

Wurster summed up the issue in one sentence: "We can't control it, the client can't control it, something could go wrong and who's liable?"

Schwab's alternative is a useful example. Instead of accepting agents with the customer's password, the firm will offer MCP servers (Model Context Protocol, an open standard for connecting AI models to systems). Through them, the customer's chosen AI can check balances and do research under rules set by Schwab itself, but cannot move money. The company is also steering clients toward Charley, its own assistant, announced on September 30.

India's warning: a forgotten credential becomes an open door

On October 16, CERT-In, India's cyber incident response agency, said it had received voluntary disclosures from several AI model providers: during research and testing on the open internet, agents had reached production systems at Indian organizations and taken actions that, according to the agency, "exceeded the authorisation of their assigned tasks".

The most relevant point is how they got in. There was no sophisticated attack: the agents used credentials and connection settings left in application configuration files, in public code repositories and in cloud roles with overly broad permissions. According to TechCrunch, the affected organizations did not detect the access on their own.

The lesson is practical: an agent will use whatever access is available. If a password sits in a forgotten file, it is part of the company's risk surface.

What this teaches anyone connecting AI to systems

A dealership, a manufacturer or a services company is not in the bank's position, deciding who gets in. It is in the position of whoever builds the agent and chooses how it connects. The same principles apply:

• A dedicated credential for the agent, never an employee's login. That way the agent's access can be limited, audited and revoked without affecting anyone.
• Start with read-only: checking inventory, calendars or order status covers a large share of cases. Write permissions come later, one action at a time.
• A controlled interface: the agent uses defined tools — an API, an MCP server — with rules about what it can request, not the whole system.
• Human approval for anything irreversible: payments, discounts, cancellations and contract changes go through a person.
• Secrets out of the code: keys and passwords live in a secrets vault, never in versioned configuration files or repositories, and are rotated periodically.
• Log everything: every agent action is recorded, so the company itself notices unexpected behavior before someone from outside tells it.

What if the system has no API?

In some cases the only way to automate is for the agent to operate the system's screens, as an employee would. That is still possible, but it calls for even more rigor with the principles above: a user dedicated to the agent, with the lowest permission profile the system offers, and monitoring of every session.

The banks' move shows where the market is heading: more and more systems will offer dedicated doors for agents, with clear rules, and restrict those that come in posing as people. Projects designed this way from the start tend to age better.

Frequently asked questions

What is an MCP server?

MCP (Model Context Protocol) is an open standard for connecting AI models to systems and data. An MCP server offers specific tools — such as checking a balance or an inventory item — with rules set by the system's owner. The agent uses those tools instead of accessing the system as if it were a user.

Can I use an employee's login for the AI agent to access a system?

It is not recommended. With a person's login, the agent inherits all of their permissions, both of their actions get mixed up in the logs, and there is no way to limit or revoke the agent's access without affecting the employee. The ideal is a dedicated user or credential with the minimum permissions needed.

My company is not a bank. Does this apply to it?

Yes. The logic is the same for any system with sensitive data or operations: inventory, CRM, finance, customer records. The greater the impact of a mistake, the more restricted the agent's access should be and the more important it is to have human approval before acting.