Delegated Access for AI Agents: What the Bank Crackdown Teaches

Over the past two weeks, some of the biggest US banks have started blocking AI agents that log into customer accounts. CBS News reported on October 23, citing Axios, that dozens of institutions have spotted third-party agents operating inside online banking without approval. They got in because customers handed over their usernames and passwords.

The banks aren't really fighting AI. They're fighting the lack of delegated access: a way for a person to let software act for them with limited, revocable permissions instead of a full copy of their login. If your business runs a customer portal, a supplier dashboard or a SaaS product, the same agents are coming to you next.

TL;DR#

• JPMorgan, Schwab, Citi and Bank of America are restricting outside AI agents, mostly because shared passwords give agents unlimited power and nobody can tell who's accountable.
• The fix the industry keeps landing on is delegated access: scoped, read-first permissions issued to the agent itself, with money movement or other risky writes kept behind extra checks.
• Any business with a login page should decide its agent policy now, before customers decide it for them with a password and a browser bot.

What happened at the banks#

A customer signs up for a personal AI agent (The Next Web named Meta's Muse), gives it their bank login, and the agent drives the website like a person would. Per the Axios reporting, these agents mostly followed instructions and weren't draining accounts. But some took actions the account holder never approved, like calling the bank to file a complaint.

The responses came quickly:

• JPMorgan. On the October 13 earnings call, Jamie Dimon said letting outside agents act inside the bank's systems is "just too risky for clients and for JPMorgan". Third-party tools can view some account data, but they can't send money or pay bills.
• Schwab. CEO Rick Wurster said the firm blocks agents that log in on a client's behalf, and asked the question every risk team is asking: "We can't control it, the client can't control it, something could go wrong and who's liable?" Schwab is steering clients toward its own assistant, Charley, and money movement stays off the table for outside models.
• Citi and Bank of America announced their own limits on October 16, per reports from the FT and GuruFocus.

White House AI adviser David Sacks pushed back on calling this an attack and suggested read-only access as a middle ground.

Why shared passwords are the real problem#

When an agent logs in with your password, the system sees you. It can't tell a human clicking around from a model making decisions for you. That breaks three things.

No limits#

A password grants everything the account can do. There's no way to say "check my balance but never wire money," so the agent, and anyone who compromises it, gets full power.

No accountability#

Every action in the audit log looks like the customer did it. When something goes wrong, the bank, the agent vendor and the customer each have a reasonable argument that it's someone else's fault. That's the liability gap Wurster was pointing at.

No clean off switch#

Stopping the agent means changing the password, which also logs out every legitimate session.

Delegated access vs credential sharing: the technical options#

Delegated access means the user approves specific software to act for them, and the system issues it its own limited credential. OAuth has done this for apps for years; agents make it urgent. The OAuth token exchange spec, RFC 8693, even includes an "actor" claim, so a token can record both the user and the software acting on their behalf.

Here's how the realistic options compare:

A sensible flow looks something like this:

Customer -> consent screen -> "Allow Agent X to: read orders, draft returns"
Agent X  -> token (user=Jane, actor=AgentX, scopes=orders:read returns:draft)
Agent X  -> API: GET /orders          (allowed, logged)
Agent X  -> API: POST /refunds        (blocked: needs human approval)
Jane     -> approves refund in app    -> action runs, logged with both identities

The trade-off: you're building an extra front door. But you control where it leads, unlike the side window agents use today.

What it means for businesses that aren't banks#

Banks noticed first because they watch login behavior closely. Most businesses don't, so agent traffic may already be hitting your portal unnoticed.

Think about where your customers log in: a B2B ordering portal, a distributor dashboard, a booking system, a SaaS admin panel. If an agent can reorder stock, change a delivery address or cancel a subscription by driving the UI, you have the banks' exposure with far less monitoring.

There's an upside too. Customers want agents to handle routine work, and a business with a safe, documented way in is easier to work with than one that blocks everything. Schwab shows the split: block the password route, provide a controlled one. Read access is an easy yes. Write access gets decided action by action.

Doing nothing is also a decision: your real policy becomes whatever a customer's agent tries.

How to set up delegated access: a practical checklist#

1. Check your logs for agent traffic. Look for headless browser signatures, very regular timing and sessions that move faster than a person could.
2. Sort your actions by risk. List what a logged-in user can do and label each action read, low-risk write or high-risk write. Moving money, changing payout details and deleting data belong in the last group.
3. Ship read access first. A read-only API or scoped token covers most of what agents actually need (status checks, order history, reports) at low risk.
4. Issue credentials to the agent, not the user's password. Use OAuth scopes so each agent gets its own token tied to the user who approved it.
5. Put approval gates on risky writes. Let the agent draft the action, then require the customer to confirm in your app. Log who requested it and who approved it.
6. Add limits. Rate limits, spending caps and short token lifetimes make mistakes smaller and easier to undo.
7. Write the policy down. Update your terms and help docs so customers know the safe route exists and the password route will be blocked.

How MagicMakers Lab approaches this#

Our work sits right where this problem lives: connecting AI to existing systems without handing it every key. Through our AI Integration & Automation and MCP development work, we build agent-facing APIs and MCP servers with scoped tools, approval steps for risky actions and a log of every decision. When we automated fulfilment for Framico, the goal was the same: let software handle the routine work while people keep control of the decisions that matter.

Key takeaways#

• Major US banks are blocking AI agents that log in with customers' passwords, mainly over control and liability.
• The core issue is the lack of delegated access, not AI itself.
• Scoped, revocable credentials issued to the agent are the practical fix, with read access first and risky writes behind approval.
• Any business with a customer login should measure agent traffic and set a policy now.

FAQ#

What is delegated access?#

Delegated access lets a person give another user or a piece of software permission to act on their behalf without sharing a password. The delegate gets its own credential with limited permissions, such as read-only access to orders. The owner can revoke it at any time, and every action is logged as the delegate acting for the owner, which keeps accountability clear.

Why are banks blocking AI agents?#

Banks are blocking agents that log in with customers' usernames and passwords. With a shared password, the agent has full account power, the bank can't tell it apart from the customer, and liability is unclear if something goes wrong. Banks like JPMorgan and Schwab still allow some controlled, mostly read-only access through approved routes.

How should AI agents authenticate to my app?#

The safest pattern is OAuth: the customer approves the agent on a consent screen, and your system issues the agent its own token with specific scopes. That token should be short-lived, revocable per agent and tied to both the user and the agent. Avoid letting agents use customer passwords or drive your UI with browser automation.

Should I give AI agents read or write access?#

Start with read access. It covers most agent use cases, like status checks and reports, and carries little risk. Add write access one action at a time, beginning with low-risk changes. For anything involving money, payout details or deleting data, have the agent draft the request and require the customer to approve it in your app.

If customers are pointing AI agents at your portal, we can help you map the risky actions and design the right access. Book a free audit.

Sources#

• AI agents are roaming around consumers' bank accounts, and banks aren't happy about it (CBS News)
• JPMorgan blocks outside AI agents from customer accounts (Cybernews)
• Schwab and JPMorgan are blocking AI agents from moving customer money (The Next Web)
• Schwab blocks unauthorized AI agents, points clients to Charley (American Banker)
• Citi and Bank of America restrict AI agent access (Let's Data Science)
• RFC 8693: OAuth 2.0 Token Exchange (IETF)