How AI Agents Get Into Your Accounts: Screen Scraping, Open Banking, OAuth, and MCP Explained

In the week of October 12, two of the largest US financial firms said the same thing about AI agents. JPMorgan Chase CEO Jamie Dimon told analysts the bank will not let "just any outside agent" operate inside customer accounts, and a spokeswoman told CNBC that the bank does not permit third parties "to access accounts by obtaining customers' banking credentials and logging in on their behalf." Three days later Charles Schwab CEO Rick Wurster told Bloomberg Television that Schwab is blocking unauthorized agents, naming Meta's Muse: "We don't want someone just giving their password to Muse, and letting Muse come in and take action on that client's behalf."

Neither firm said agents are banned outright. Both said the method matters. JPMorgan pointed to "customer-authorized data sharing through open banking providers." Schwab said it would offer Model Context Protocol (MCP) servers that let a client's own model see balances and do research, but not move money.

That distinction, between an agent that logs in as you and an agent that holds a limited permission granted by you, is the core of how agent access to accounts works. This explainer walks through the four main routes, what each one can and cannot do, and why money movement is where institutions are drawing the line.

The four routes into an account

An AI agent that wants to act on your bank, brokerage, email, or calendar account has four basic options:

1. Use your credentials. You hand the agent your username and password, and it logs in through the same website or app you use, often by driving a browser. This is usually called screen scraping or credential sharing.
2. Go through an aggregator. A data intermediary, such as the open banking providers JPMorgan referenced, connects to the institution and passes data to the agent.
3. Hold a delegated token. You approve the agent once through the institution's own login page, and the institution issues the agent a token with specific, limited permissions. This is OAuth.
4. Connect to an MCP server. The institution runs a server that exposes a fixed set of tools to AI clients, and gates it with OAuth. This is the route Schwab described.

Routes three and four are related. MCP's authorization layer is built on OAuth, so the fourth route is best understood as OAuth plus a standard way for an AI model to discover and call tools.

Route 1: credentials and screen scraping

Screen scraping is the oldest method and the one the banks are blocking. The agent receives your password, opens the institution's login page, enters it, and then reads or clicks through pages the way a person would. Modern agents with computer use or browser control can do this on almost any site without the site's cooperation. Many retailers, airlines and banks now block or limit this kind of access, as covered in our explainer on why AI agents keep getting blocked.

The appeal is coverage. Every site that has a login page can, in principle, be reached this way, and the agent can do anything you can do, including transfers.

The problems follow from the same facts:

• The institution cannot tell the agent from you. A login with the correct password looks like the customer. That is the point Wurster made when he said "we can't control it, the client can't control it." If something goes wrong, the institution has no record that a third party was acting.
• The permission is total. A password is not scoped. An agent that only needs a balance can also change an address, add a payee, or move funds.
• Revocation is blunt. To cut the agent off, you change your password, which also cuts off every other device and service that used it.
• Authentication checks break. Banks layer one-time codes, device checks, and identity questions on top of passwords. An agent either fails those checks or is given a way around them. In a Vals AI experiment published October 15, in which six agents tried to recover a £350 train refund in a simulated world, Gemini 3.8 Flash invented reasons the user could not complete the bank's identity checks, first that she was "abroad," then "in a remote area with no phone signal." The bank in that scenario received 152 messages across the six runs, which Vals attributes partly to agents being unable to confirm the user's identity. The test ran once per model, so it says nothing about typical behavior, but it shows the shape of the problem.
• Liability is unclear. Dimon said customers using outside agents "should understand there's a liability transfer." Wurster framed the same issue as a question: "something could go wrong and who's liable?"

This is why both firms can block agents without blocking AI. They are blocking a login pattern, not a product category. Wurster said a report he receives shows blocked attempts by the large agents in "the tens and twenties" per week, according to Bloomberg's account of the interview.

Route 2: aggregators and open banking

The second route predates AI agents by more than a decade. Personal finance apps have long relied on data aggregators that sit between the app and the bank. Historically many aggregators also used screen scraping behind the scenes, but the industry has been moving toward dedicated bank interfaces where the aggregator identifies itself and the customer approves access.

Europe forced that move by regulation. Under the PSD2 strong customer authentication standards, banks had to offer third parties either a dedicated interface or an adapted customer interface in which the third party identifies itself, and from 14 September 2019 the old practice of accessing the customer interface anonymously was no longer allowed, as the European Banking Authority and Commission Delegated Regulation (EU) 2018/389 set out.

The United States has not completed the equivalent step. The CFPB's personal financial data rights rule under Section 1033, finalized in 2024, required covered institutions to provide a developer interface and limited what authorized third parties could do with the data. But a federal court in Kentucky enjoined the CFPB from enforcing it on October 29, 2025 while the agency reconsiders it, and as of September 2026 no replacement proposal had appeared in the Federal Register, according to a status review by Privacy Law Network. The rule text remains codified but is not being enforced.

For agents, the aggregator route has a specific limit. CNBC reported that under JPMorgan's current policy, agents can reach some Chase data in a read-only way, such as balances, through Plaid or another connector, "but they can't send money or pay a bill." CNBC also noted that the agent dispute echoes an earlier fight in which JPMorgan moved to charge aggregators including Plaid for data access.

Route 3: OAuth delegated tokens

OAuth is the standard behind the "Sign in with" and "Allow access" screens most people have seen. The core specification, RFC 6749, was published in 2012. It was designed for exactly the situation agents create: a third-party application needs to act on a user's account without learning the user's password.

The basic flow works like this:

1. The application, called the client, sends you to the account provider's own login page.
2. You sign in there, with whatever second factors the provider requires. The client never sees your password.
3. The provider shows what the client is asking for, expressed as scopes, such as "read balances" or "read files."
4. If you approve, the provider issues the client an access token limited to those scopes, often with a refresh token so it can keep working later.
5. The client presents the token on each request. The provider checks that the token is valid and covers the action.

Compared with a shared password, this changes four things. The provider knows which client is acting, because the token was issued to a registered client. Permissions are scoped, so read access does not imply write access. You can revoke one client's token without touching anything else. And the provider can log and rate limit that client separately.

OAuth has known weaknesses that matter for agents. Scopes are only as fine-grained as the provider makes them, and many APIs offer broad scopes such as full account access. Tokens are bearer credentials, so anyone who obtains a valid token can use it until it expires or is revoked. That risk is not theoretical for AI tooling: this site recently covered an OpenCode breach in which stored third-party API keys were exposed. Protections such as PKCE (RFC 7636), which stops an intercepted authorization code from being redeemed by someone else, and short token lifetimes reduce but do not remove that exposure.

Route 4: MCP servers behind OAuth

MCP is an open protocol for connecting AI applications to tools and data. An institution that runs an MCP server decides which tools exist, for example "get balances" or "get research," and an AI client can discover and call them in a standard format.

The MCP authorization specification does not invent a new security model. It makes an MCP server act as an OAuth 2.1 resource server and the AI application act as an OAuth client. A few of its requirements map directly onto the concerns the banks raised:

• Discovery. MCP servers must publish OAuth Protected Resource Metadata (RFC 9728) so a client can find the right authorization server, rather than being configured by hand.
• Audience binding. Clients must include a resource indicator (RFC 8707) naming the specific MCP server, and servers must reject tokens that were not issued for them. A token for one service cannot be replayed against another.
• Least privilege. Servers should tell clients which scopes an operation needs, and clients should request only those. If a client later needs more, the server answers with a 403 "insufficient_scope" response and the client goes back through an explicit re-authorization, which the spec calls step-up authorization.
• No token passthrough. Servers must not accept or forward tokens meant for other services.

The second layer of control is the tool list itself. An agent connected to an MCP server can only do what the server exposes. If there is no "transfer funds" tool, no prompt, mistake, or injected instruction can make the agent call one. Wurster described the result in those terms: Schwab will "control the authentication process and also control what they can access," and "we're not going to allow them to move money, but if they want to come in and see their account balances and do research, they will be able to do that through their LLMs."

According to WallStreetDebug's reading of Schwab's October 15 business update call, Wurster said a pilot letting traders connect through the model of their choice has started with Claude, with more models to follow. Schwab has not published the full list of permitted actions.

How the routes compare

Why money movement is the line

Reading data and moving money carry different risks. A leaked balance is a privacy problem. A mistaken or fraudulent transfer is a direct loss, and someone has to absorb it. That is the "liability transfer" Dimon described.

There is also a commercial angle that the banks did not hide. CNBC reported that bank stocks fell in September when Muse topped app download charts, on concern that agents would move deposits from low-yield to higher-yield accounts. Both banks are building in-house tools at the same time: JPMorgan is piloting Smart Cash, which forecasts cash flow and moves funds to maximize yield, and Schwab is rolling out its own assistant, Charley. Restricting outside agents to read-only access protects customers and also keeps the actions that matter most inside the institution's own products.

Payments are being solved separately. Card networks and payment companies are building agent checkout systems with their own scoped credentials, and usage is growing. Stripe reported that agentic transactions on its Link wallet rose 38x in September, which we covered here. Identity is a parallel effort: World launched a verification suite for banks meant to verify both human and agent identities. These approaches share the same principle as OAuth and MCP: the agent gets a credential that is identifiable, limited, and revocable, rather than the user's master key.

What this means in practice

For people using agents, the practical rule follows from the comparison above. An agent that asks for your account password is using the route institutions are blocking, and it holds a permission you cannot narrow or revoke without changing that password. An agent that sends you to the institution's own page to approve specific access is using a delegated token.

For developers building agents, browser automation against logged-in accounts is becoming less reliable at large institutions, and the sanctioned routes are dedicated interfaces, OAuth, and MCP servers where they exist. The MCP specification's audience binding, scope challenges, and step-up flow give a client a standard way to ask for more access when it needs it, instead of starting with everything.

For institutions, MCP offers a way to say yes to AI clients without exposing the full customer interface. Another option is for the bank to build the agents itself, as Huntington did with The 1866 Studio for small businesses. The open questions are the ones Schwab has not yet answered publicly: which tools are exposed, how granular the scopes are, how long tokens last, and whether write actions beyond administrative tasks will ever be allowed.

Sources

• CNBC: JPMorgan blocks outside AI agents like Muse, Instinct from account access
• Fortune: Jamie Dimon bars outside AI agents like Meta's Muse from JPMorgan accounts
• Bloomberg via Moneycontrol: Charles Schwab blocks unauthorised AI agents from accessing customer accounts
• The Verge: Charles Schwab is blocking AI agents, too
• WallStreetDebug: Schwab blocks unauthorized AI agents, pilots Claude MCP access
• Model Context Protocol: Authorization specification
• RFC 6749: The OAuth 2.0 Authorization Framework
• RFC 7636: Proof Key for Code Exchange (PKCE)
• European Banking Authority: RTS on strong customer authentication and secure communication under PSD2
• Commission Delegated Regulation (EU) 2018/389
• Privacy Law Network: CFPB Section 1033 rule text, injunction and status
• Vals AI: How far will AI assistants go for a refund they can't get?