Why banks block AI agents that log in with a password

Banks block AI agents that log in with a password because an agent using a customer’s password acts as that customer, so the bank cannot limit it or say who is liable. Schwab blocks Meta’s Muse and JPMorgan blocks outside agents generally. Amazon blocked Muse over credential storage. A scoped key with its own identity keeps the audit trail intact.

When did Schwab, JPMorgan and Amazon start blocking outside AI agents?

Amazon began blocking Meta’s Muse on the night of 20 September 2026. JPMorgan Chase CEO Jamie Dimon said on 13 October that the bank will not let outside agents inside. Schwab CEO Rick Wurster said on 16 October that Schwab blocks them too, Muse included. That is 26 days from the first block to the third.

Amazon told GeekWire that Muse does not identify itself when it browses and appears to capture and store customer credentials. Dimon said, “We’re not going to allow just any outside agent to come inside the company,” as Fortune reported, though the quotes Fortune prints do not name Meta or Muse.

Wurster named Muse on Bloomberg Television, as The Verge reported: “We don’t want someone just giving their password to Muse, and letting Muse come in and take action on that client’s behalf.”

How often is unclear. The Next Web quotes Wurster saying the big agents are stopped “in the tens and twenties each week”, while American Banker quotes him calling the reports “few and far between”. Neither gives a total.

Why does an AI agent using a customer’s password create a liability problem?

A password carries every permission the customer has, and the log records each action under the customer’s name. An agent that signs in with it cannot be limited to one task, and nobody can later show whether a person or a program clicked. Wurster’s question was who is liable. The Next Web reports US lawmakers are still debating it.

Three things break at once:

• Control. The bank cannot grant the agent less than the customer’s own permissions.
• Evidence. The log shows the customer, so in a dispute it cannot separate the customer’s click from the agent’s.
• Consent. The agent arrives without announcing itself, which is Amazon’s objection; Amazon says the use breaks the Conditions of Use its customers agreed to.

Meta says Muse “has no visibility into people’s passwords or payment methods”, and that the user sees an audit trail. Take that as Meta’s own claim: a sealed password still gives the agent the full session, and the bank’s own log still reads as the customer.

What do Schwab and JPMorgan allow AI agents to do instead?

Schwab and JPMorgan allow access they can scope and identify. Schwab plans MCP servers with controlled authentication, where outside AI tools can check balances and do research but cannot move money. JPMorgan points to open banking providers for customer-authorized data sharing. Schwab also steers clients to Charley, its own assistant.

American Banker reports that Schwab blocks agents using client credentials or browser automation, while clients can still use their own LLMs, such as ChatGPT, for trades.

The MCP servers are announced intent, per The Next Web. What the banks are choosing is who sets the scope and who the log names, and a protocol alone settles neither.

How does a scoped agent key differ from a password login in an audit log?

A password login writes the customer’s name on every action, so the log cannot tell agent from person. A scoped key or per-agent identity writes the agent’s own ID, limits what it can call, and can also name the person it acts for. The log then answers who acted and under what limit.

The last three rows follow how AI agents log in to Salesforce and Workday. A dedicated identity gives the clearest trail but needs provisioning.

RFC 8693 defines an act (actor) claim for delegated calls, but few SaaS APIs read it yet. Log the agent ID and the person on every call, using the fields in what an AI agent’s audit record should contain.

What should a team check in its AI agent logs this quarter?

Pick one action an agent took last week and open its log entry in the target system. If the entry shows only an employee’s name, the log cannot prove which actions were the agent’s. Fix that before the next pilot grows, by giving each agent its own identity and recording the person it acts for.

For AI and IT leads, the check takes an afternoon:

1. List each agent that touches customer or employee accounts and its credential: a password, a shared integration user, a person’s OAuth grant or its own identity.
2. Pick one write action from last week and read who its log entry names: the agent, the person, or only the person.
3. Compare the agent’s permissions with its task, and remove anything it does not need, such as delete or payment rights.
4. Replace each password or shared login with a scoped credential, and log the agent ID next to the person on every call.

How can Tool Policies apply a bank-style rule to an AI agent?

Schwab’s planned rule is that outside tools may read balances but never move money, on terms the bank sets. The same rule maps to agent policy: block write tools by name, cap values such as payment limits, hide protected fields, and scope each rule to users or groups. StackOne Tool Policies evaluate each request against rules like these.

We built Tool Policies at StackOne for this case. A policy checks the input before the call reaches the business system and the response before the agent sees it, and every governed request is traced to its user, connector and policy decisions. The launch post explains how the five Tool Policies rule types work.

Two limits apply. Policies sit on top of each business system’s permissions and do not change roles there, and member policies do not apply to API key calls that carry no member identity.

See how Tool Policies scope what an agent can do.