DEV Community

Cover image for Schwab, JPMorgan and Citi Block AI Agents That Log In With Your Password
Gabriel Anhaia
Gabriel Anhaia

Posted on AI-assisted

Schwab, JPMorgan and Citi Block AI Agents That Log In With Your Password

#ai #agents #security #api

Every week, Charles Schwab's CEO gets a report on AI agents his firm turned away. According to Forkast, that report shows Schwab blocking "tens and twenties" of attempts by major AI agents to get at client funds. On October 16, CEO Rick Wurster named one of those agents on Bloomberg Television: Meta's Muse (The Next Web).

Muse is the personal agent Meta launched in September. It runs in its own secure VM with its own browser, and it can fill out forms and negotiate for the person who set it up (Meta). Wurster's objection was short: "We don't want someone just giving their password to Muse" (Oninvest).

Schwab wasn't alone. Between October 13 and October 17, JPMorgan said much the same thing on its earnings call, and reports described similar limits at Citigroup and Bank of America. If you build agents that act for users, the banks have now told you which door is shut and which ones are still open.

Who blocked what

  • JPMorgan, October 13. On the third-quarter earnings call, Jamie Dimon said "we're not going to allow just any outside agent to come inside the company" because "it's just too risky for clients" (automated call transcript). CFO Jeremy Barnum added: "to the extent that we're able to block those, we are blocking them to protect customers and protect ourselves" (transcript).
  • Schwab, October 16. Wurster said Schwab blocks unauthorized agents from moving client money. Schwab plans MCP servers that give outside models read-only access to balances and research, with no money movement (The Next Web). It is steering clients to Charley, its own assistant, announced on September 30 (Schwab).
  • Citigroup, reported October 17. Citi has reportedly barred third-party AI agents from logging into client accounts and making transactions, and allows limited read-only access through certain open-banking providers (Oninvest).
  • Bank of America, reported October 17. BofA restricts agent access while it works out who is liable for AI-initiated payments, the Financial Times reported. CEO Brian Moynihan, in a CNBC interview the FT cited: "We strongly believe there should be a human in the loop to authorise money moving out of your account" (Oninvest, citing the FT).

The line is credentials, not AI

Read those statements side by side and a pattern shows up. None of the banks shut off customer-authorized data sharing through open banking. JPMorgan told Fortune: "We support secure, customer-authorized data sharing through open banking providers" (Fortune). Citi still allows read-only access through open banking. Schwab is building a read-only MCP route.

What's shut is an agent that holds the customer's password and drives the bank's website, and anything that moves money. Barnum was specific about the first part: "some of the services that offer that do it through credential sharing," and "we have a long record of being against that way of doing things—screen scraping, et cetera" (transcript).

The second part is liability. Barnum said that if customers "give up their credentials to the agent and the agent does something that they don't want," then "that's going to be on them" (transcript). Dimon put it this way: "There's a liability transfer. They should understand the liability transfer" (Banking Dive). That is the sentence to show your product and legal people before you ship a feature that logs into a bank.

Be fair to Muse here. Meta built it with guardrails: shared credentials sit in secure storage that Muse can use without seeing, a separate Sentinel agent must approve anything Muse sends to the internet, and Muse asks for approval before a purchase (Meta). Wurster's point was control: "We can't control it, the client can't control it, something could go wrong and who's liable?" (The Next Web).

The doors that are still open

There are three routes that none of these banks closed.

  1. Aggregator read access. Muse itself connects financial accounts through Plaid, sharing "balances, transactions, investment holdings, mortgage information and more" (Plaid). That is the same kind of open-banking path JPMorgan and Citi say they support for read-only data. Neither bank has commented publicly on Muse's Plaid link.
  2. Bank-run read-only connectors. Schwab's planned MCP servers are this route (The Next Web). As of October 18, Schwab hasn't published endpoints or a spec, so there's nothing to wire up yet.
  3. A human authorizes the money. Moynihan's "human in the loop" line is a design spec. Your agent can research, compare and prepare a transfer. The person approves it in the bank's own app.

Poppy: an agent that says who it is

Part of the control problem Wurster describes is that a bank can't tell an agent from the customer whose password it holds. On October 9, Sierra published a draft protocol, announced with Meta, aimed at exactly that: the Personal Agent Protocol, or Poppy (Sierra). In Sierra's words: "The personal agent identifies itself, so the company always knows when an agent is acting for a customer" (Sierra).

The mechanics are familiar web plumbing. A company publishes a discovery file at /.well-known/poppy.json, the customer signs in with OAuth, and the agent gets a short-lived session token that carries only the access the customer approved (Sierra, spec site). The draft's example discovery file has this shape. The field names come from the draft; the values here are placeholders:

{
  "protocol_version": "0.1",
  "organization": {
    "name": "Example Bank",
    "domain": "bank.example.com"
  },
  "auth": {
    "issuer": "https://auth.bank.example.com",
    "direct": { "scopes": ["poppy:read"] }
  },
  "agent": {
    "protocols": [
      {
        "type": "poppy",
        "endpoint": "https://bank.example.com/poppy"
      }
    ]
  }
}
Enter fullscreen mode Exit fullscreen mode

The draft's example uses two scopes, poppy:read and poppy:write. The company decides which scopes a sign-in allows, and the customer picks on the company's own sign-in page whether the agent can view, make changes, or both (spec site). Your agent can check whether a site supports Poppy with one request:

curl -fsS https://bank.example.com/.well-known/poppy.json
Enter fullscreen mode Exit fullscreen mode

Keep expectations in check. The spec is a 0.1 draft heading toward 1.0 (spec site), and Sierra says it will publish a reference implementation within a month of its October 9 announcement (Sierra). Bank of America, Wells Fargo, Visa, Mastercard, PayPal and OpenAI are among the design partners (Sierra). So one of the banks restricting agents this week is also helping design the identity layer. Being a design partner isn't a commitment to adopt, and as of this writing none of the four banks has said it will turn Poppy on.

What to change in your agent this week

If your agent touches anyone's money, five changes follow from what the banks said. This is engineering guidance, not legal advice: talk to counsel before you write liability terms for anything that moves money.

  • Don't ask users for bank passwords. JPMorgan says it blocks credential-sharing agents where it can, and that misuse after a customer hands over credentials is "on them" (transcript).
  • Treat a block as a normal result. When a bank refuses the agent, stop, tell the user, and point them to the bank's own app. In my view, an agent retrying a refused login looks a lot like what a bank's fraud controls are built to stop.
  • Read through aggregators, write through people. Pull balances and transactions over open banking. Keep transfers behind a human approval in the bank's interface.
  • Write down who is liable. Dimon's "liability transfer" belongs in your terms and your onboarding copy, in plain words.
  • Watch Poppy's reference implementation. If banks adopt agent identity, an agent that already speaks it may get the first open door.

Would you let an agent move money from your account if the bank could see it was an agent? Or does a human tap on every transfer stay non-negotiable for you? Tell me in the comments.

If this was useful

The banks drew their line around three things agent builders deal with every day: what an agent is allowed to touch, when a human has to approve, and what happens when a call gets refused. The AI Agents Pocket Guide is about those patterns: agent loops and the guardrails you put around them.

I also build Hermes IDE, a free, source-available IDE for running Claude Code, Codex and other coding agents on macOS, Windows and Linux. It's on GitHub, and it isn't affiliated with any agent vendor.

AI Agents Pocket Guide: Patterns for Building Autonomous Systems with LLMs

Top comments (1)

Collapse
 
autenai profile image
Auten •

Useful roundup, and "the line is credentials, not AI" is the right reading. One case none of the quotes seem to cover is the agent that never holds the password: it runs on the customer's own computer, in the browser they are already signed into, while they sit there. To the bank that session looks exactly like the customer, which is the "we can't tell an agent from the customer" problem Wurster describes, just without credential sharing.

For that shape the honest design I'd suggest is your third door taken literally: the agent researches and prepares, then hands back at the login and at anything that moves money, and the human does those steps in the bank's own flow. Any password gets typed locally from the user's own store, never pasted into the model's context.

Does the Poppy draft say anything about agents acting through the customer's own UI rather than through an API session, for example whether they should identify themselves at all? It reads as built for the hosted-agent case, and the local one may end up being where the liability question lands next.