Two big US institutions said the same thing in the same week: an outside AI agent that logs in with a client's password and moves the client's money is not allowed. Both left a door open, though: read-only views, and lookup/research through an MCP interface.

If you build agents, the takeaway is simple. Don't count on "pretend to be the user and log in" for financial systems. Build for the narrower interfaces banks are willing to open, and design "read" and "move money" as two separate things.

Schwab. CEO Rick Wurster told Bloomberg Television that Schwab blocks unauthorized outside agents, Meta's Muse included, from moving client money. His main worry is clients handing their login credentials to an agent. Roughly: we can't control it, the client can't control it, so who is liable if something goes wrong? According to The Next Web, Schwab gets a weekly report on blocks and sees large agents stopped "in the tens and twenties" a week. American Banker says such blocks are rare because most clients don't use AI that way. The two reports differ in tone, and I won't smooth that over.

Schwab offers two alternatives. One is its own assistant, Charley (announced September 30, built on outside LLMs and Schwab's own data). The other, per The Next Web, is MCP servers that let a client's chosen model check balances and do research, but not move money. American Banker adds that clients can use their own LLM, such as ChatGPT, to connect to Schwab and complete some transactions, and that more models will be able to trade later, but money movement will not be opened up.

JPMorgan. Jamie Dimon said on the earnings call that the bank won't let "just any outside agent" operate inside its systems, because it is "too risky for clients and for JPMorgan." He added, "You don't want rogue agents, and it could be thousands of them." A spokeswoman told CNBC the bank does not allow third parties to log in with customers' banking credentials. Cybernews reports that third-party agents such as Muse can view some account data read-only, but cannot move money or pay bills.

The banks are blocking the left path and leaving the right one open. The difference isn't "AI or no AI." It's whether the bank can know about, limit, and revoke the agent's power.

Credential login has three problems. The bank can't tell a human from an agent (Schwab's phrase was an agent "coming to our site and trying to log in on behalf of a client"). Once the agent has the password, its power is the client's full power, so you can't give "look" without "move." And nobody can say who is liable when it goes wrong, which is exactly Wurster's question.

The banks haven't published their interface details. What follows is the general standards and the MCP spec, not Schwab's or JPMorgan's implementation (I couldn't find that).

The MCP authorization spec (draft) requires MCP servers to implement OAuth 2.0 Protected Resource Metadata (RFC 9728). Clients must send a resource parameter (RFC 8707) so a token is valid for one service only. Tokens go in the Authorization: Bearer header, never in the URL. When scope is not enough, the server returns 403 with insufficient_scope, and the client runs a step-up flow.

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope",
                  scope="files:write",
                  resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

On top of that, industry guides commonly add a few hardening steps. Use RFC 8693 token exchange to trade the user's broad token for a narrow, minutes-long task token. Use DPoP (RFC 9449) to bind a token to the client's private key, so a stolen token is useless. Require human approval for high-risk actions (payments, permission changes). Evaluate every tool call against policy at runtime, not only when the token is issued. These come from the WorkOS and Zylos guides; they are community practice, not something the banks disclosed.

Put the two statements side by side and you get a three-step ladder. The higher the step, the costlier a mistake, and the slower the banks open it.

The same layering works for your own agent product. Split read-only tools from side-effect tools into different scopes, or even different servers. Hand out read scopes freely; make write scopes a separate request, short-lived, and gated by a human.

• Don't store user passwords, and don't have the agent drive a browser to log in to someone else's account. That's the blocked path, and Schwab named browser automation explicitly.
• Look for the other side's official interface or MCP server first. If none exists, write "this system doesn't support agents" into your docs as a product limit rather than working around it.
• Give each agent its own identity (its own OAuth client), so your logs can answer "which agent made this call, on behalf of which user."
• Split read and write scopes. Use short-lived tokens and human approval for writes. On an authorization failure (401/403), stop; don't retry with other credentials or fall back to a service account.
• Make revocation one click: revoke one agent (across all users) or one user (across all agents).

Items 3, 4 and 5 come from the WorkOS agent-auth checklist. Items 1 and 2 are my inference from what the banks said, so treat them as my judgment.

A few things I couldn't find: how Schwab and JPMorgan actually detect agents (the American Banker piece doesn't say); whether the "MCP servers" Schwab mentioned are live or planned; and how liability works legally (The Next Web says Congress is still debating it).

Keep motive in view too. Analyst Tim Welsh told American Banker: "An outside agent works for the client. Charley works for Schwab." Schwab reported about $3.48 billion in Q3 net interest revenue, much of it on roughly $493 billion in cash-sweep accounts. The security reasons are real, and so is the business interest. Both can be true.

Finally, the block counts and statements in these reports are secondhand accounts of what executives told the media. I didn't see any primary documents from the banks.

scope

What a token is allowed to do, for example accounts:read. The narrower it is, the less you lose when an agent errs or is hijacked.

token exchange (RFC 8693)

Trade a broad token for a narrow, short-lived one.

DPoP (RFC 9449)

Binds a token to the client's private key, so a stolen token can't be used by someone else.

step-up

When current permission isn't enough, run authorization again to get a higher level.

MCP

Model Context Protocol, an open protocol for letting models call external tools and data.

• The Next Web: Schwab and JPMorgan block AI agents (2026-10-16)
• American Banker: Schwab blocks unauthorized AI agents, points clients to Charley
• Cybernews: JPMorgan blocks outside AI agents (2026-10-14, updated 10-16)
• MCP Authorization spec (draft)
• WorkOS: the 2026 AI agent auth checklist (community guide)
• Zylos: Agent authentication and delegated access (community guide)

I did not read any primary documents from the banks; every quote here is relayed by the press. Defer to the originals.