JPMorgan Blocked Outside AI Agents: What It Means for Agent Builders

JPMorgan Chase blocks outside AI agents, such as Meta's Muse, that log in to retail accounts using a customer's banking credentials. Jamie Dimon spoke about it on the October 13, 2026 earnings call, and a spokesperson set out the policy itself. Read-only data sharing through open banking connectors continues, but agents cannot send money or pay bills. For builders, the message is: delegated, scoped, identifiable access, never shared passwords.

What JPMorgan actually blocked

On JPMorgan Chase's third-quarter earnings call on October 13, 2026, CEO Jamie Dimon said the bank would not let outside AI agents operate inside customer accounts. Fortune quoted him: "We're not going to allow just any outside agent to come inside the company," and "You don't want rogue agents." A bank spokesperson then made the mechanism specific: when the bank detects a third-party agent attempting to access accounts by obtaining customers' banking credentials, it does not allow it.

The trigger was the new wave of consumer agents. Meta's Muse, launched in September, can connect to financial accounts, and coverage in Fortune and The Paypers ties the policy to agents like it. The Paypers reported that agents can still read some data, such as balances, when Plaid or another connector holds access, but cannot send money or pay bills. The bank gave no timeline for safeguards that would allow direct account interaction.

The line is credentials, not AI

Read the policy closely and it is not anti-agent. WinBuzzer, summarising the earnings call, reported that CFO Jeremy Barnum tied the blocks to credential sharing and screen scraping. JPMorgan runs agents internally and says it is building customer-facing ones, without giving a timeline.

The objection is to a specific integration pattern: an agent holds the customer's username and password, logs in as the customer, and drives the website. From the bank's side that pattern has four problems.

  • No identity. The session looks like the customer, or like an attacker who stole the password. The bank cannot tell which.
  • No scope. A password grants everything the customer can do, including transfers. There is no way to grant "read balances only".
  • No per-agent revocation. Cutting off one agent means the customer changes the password and breaks everything else that used it.
  • Unclear liability. Dimon said customers who authorise outside agents should understand the risks, including a potential shift of liability to them, per The Paypers.

At agent scale those problems multiply. Dimon's worry, as reported, was thousands of rogue agents, not one.

It is not just one bank

WinBuzzer collected a pattern. Amazon cut off Muse in September, saying it did not identify itself and that Amazon had not agreed to participate, per GeekWire's reporting. Amazon cut off Meta's Muse in September, saying the agent did not identify itself and appeared to capture customer credentials, which Meta disputes. Other sites block agents incidentally through anti-bot defences that were never designed with them in mind.

The common thread: businesses accept agents that arrive through a channel they control, and reject agents that impersonate the customer.

What agent builders should change

If an agent needs to act on a user's accounts, design for the sanctioned path from day one. Credential replay may work in a demo; it will not survive contact with a bank's fraud team.

Use delegated authorisation, not stored passwords

Prefer OAuth-style consent and aggregator or open banking APIs, which JPMorgan explicitly said it supports. The user approves a scoped grant on the institution's own page, the agent receives a token, and the institution can revoke that token without touching the password. If no API exists, that is a signal the action is not yet open to agents, not an invitation to scrape.

Declare who the agent is

Amazon's stated complaint was that Muse did not identify itself. Send an honest user agent, identify the operator, and say whom the agent represents. The Sierra and Meta draft Personal Agent Protocol (nicknamed Poppy, published October 9 as a draft) points the same way: businesses publish a file at /.well-known/poppy.json, agents identify themselves, and customers sign in with OAuth 2.0 on the company's own page. It is a draft that may change, and coverage notes payments are not yet covered, but the shape is instructive.

Split read from write

JPMorgan's line falls exactly between reading a balance and moving money. Build the same split into your agent: read scopes by default, write scopes requested separately, and a human approval step for anything irreversible such as a payment or transfer. An agent that never needs write access should never hold it.

Keep an audit trail you can hand over

When liability is contested, the party with the log wins the argument. Record every action, the grant it relied on, and the user approval behind it. That record is also what an institution will ask for before it offers a sanctioned integration.

What to expect next

Expect more institutions to publish an agent policy and a sanctioned channel at the same time: block the impersonating path, open a scoped one. Expect agent identity standards to compete before one wins. And expect consumer agents to lose features where no API exists, at least for a while.

The trade-off for builders is speed versus durability. Scraping ships today and breaks the next time a fraud rule changes. Delegated, identifiable, scoped access ships slower and keeps working. For anything touching money, only the second is a product.

The same principle applies inside a company. An agent that needs reference knowledge should retrieve it from a store with its own access boundary rather than holding broad credentials to every system. That keeps the blast radius small when something goes wrong.

Frequently asked questions

Did JPMorgan ban AI agents completely?
No. Per a spokesperson quoted by Fortune, the bank blocks third-party agents that obtain customers' banking credentials to access accounts. It says it supports customer-authorised data sharing through open banking providers. The Paypers reported that read-only data such as balances remains available through connectors like Plaid, while sending money and paying bills are blocked. JPMorgan also uses agents internally.
Why does credential sharing worry banks more than APIs?
A shared password gives an agent the customer's full powers with no scope, no separate identity, and no way to revoke that one agent. The bank cannot distinguish the agent from the customer or from an attacker. A delegated API grant is scoped, attributable to a named client, and revocable without resetting the password, which is why banks steer agents toward it.
Can Meta's Muse still access Chase accounts?
According to reporting by The Paypers and WinBuzzer, agents such as Muse can still read some account data in a read-only way through connectors, but cannot send money or pay bills at JPMorgan. Meta declined to tell Fortune whether Muse could keep offering financial help if more banks block agents. Check current terms before building on that access.
What should an agent builder use instead of stored credentials?
Use the institution's own authorisation flow: OAuth-style consent, open banking or aggregator APIs, or a published agent protocol where one exists. Request read scopes by default and write scopes separately. Identify the agent and its operator honestly, require human approval for irreversible actions, and keep an auditable log of every action and the grant it relied on.
Are other companies blocking outside agents?
Yes. WinBuzzer reported that Amazon cut off Meta's Muse in September, saying it did not identify itself, and that Schwab CEO Rick Wurster said Schwab blocks unauthorised agents trying to move client money. Some other sites block agents unintentionally through anti-bot defences. Policies are changing quickly, so verify each target's current rules.