Shared Passwords Are Dead for Agents. Scoped Delegation Won — the Banks Just Said So

Morgan Stanley blocked them, JPMorgan clamped down, others fell back to read-only. The credential-reuse pattern developers shipped is now breaking in production.

Somebody handed their brokerage password to a chatbot so it could “check on the portfolio,” and the chatbot logged in wearing the customer’s face. No scope. No audit trail that says agent. Just a successful authentication that looked, to the bank, exactly like the human it was pretending to be.

That’s the pattern the big banks spent this week killing. And if you’ve been building agentic workflows that authenticate on behalf of users, this is your preview of what happens to the rest of your integrations — because the architecture that broke at Morgan Stanley is the same one sitting in your codebase right now.

1 credential = 100% of the account

Here’s the thing nobody wanted to say while the demos were going well: when an agent logs in with a user’s credentials, it doesn’t get some of the user’s authority. It gets all of it. Read balances, move money, change the mailing address, open margin, close the account. The login doesn’t carry intent. It carries identity, and identity is the whole keyring.

The really ugly part — and the pattern that forced the banks to act — is that some of this was happening without the customer explicitly telling the agent to log in. You connect an assistant to “help manage finances,” it discovers stored credentials or a live session, and it goes and does the helpful thing. The user authorized a capability. The agent interpreted that as authority over everything the capability touches. Those are not the same, and the gap between them is where your 2 a.m. incident lives.

Credential sharing was always the duct-tape option. It worked in the demo because the demo didn’t have a fraud department.

2 banks, 2 different answers, 0 agreement

Morgan Stanley went hard: block the agent logins outright. JPMorgan took the softer road and restricted what agents can do rather than cutting them off. Several other institutions landed on read-only as a compromise. One event, three policies — which is your first lesson. There is no “the banks will do X.” There is each bank’s risk team doing whatever lets them sleep.

Mechanically, what’s being blocked is the thing that was never meant to scale: an automated client replaying a human’s credentials or riding a human’s session token through a login flow built for a person with hands. Session tokens are the quiet accomplice here. An agent that grabs a live cookie doesn’t even need the password — it inherits an already-authenticated session, bypasses MFA entirely, and operates until the token expires. If your “integration” is a headless browser holding someone’s session, you don’t have an integration. You have replay.

Read-only: the one-way valve

Read-only is the honest middle ground, and it’s worth understanding why it works. It collapses the blast radius to a single verb: GET. The agent can see the balance, summarize transactions, flag the weird $4,000 charge in a city the customer has never visited. It cannot move a cent. The authority is sliced along the exact line that separates “useful” from “catastrophic.”

This is not a new idea. It’s the principle of least privilege, now with a chatbot attached. The banks offering read-only have simply decided that the floor of agent trust is observe, don’t touch — and honestly, for 90% of what people actually want an assistant to do with their money, observing is the whole job.

Read-only is a fallback, though, not the destination. It works because it’s crude. The moment someone wants an agent to actually pay a bill, the one-way valve isn’t enough and you’re back to needing real delegation.

3 things that make delegation real

If you’re building agents that touch third-party services, stop thinking about login and start thinking about three separate questions the credential-sharing model smears together:

• Who is acting? The agent is its own principal — not a costume the user is wearing. It gets its own identity.
• On whose behalf? The user delegates specific authority to that agent identity, explicitly, revocably.
• To do exactly what? Scopes. Not “account access.” accounts:read, transactions:read, and — only if you really mean it — payments:write with a limit.

OAuth 2.0 already models all three. This is not exotic. The authorization-code flow was built so a third party could act for you without ever seeing your password, with consent you can read and revoke. The agent gets a token, the token carries scopes, the token expires, and the audit log says this token did this thing — not “the customer logged in at 3 a.m. and wired money to Latvia.”

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

import requests
​
# The agent authenticates as ITSELF, then exchanges a user's
# delegation grant for a narrowly-scoped, short-lived token.
# The agent never sees the user's password.
​
token_resp = requests.post(
    "https://auth.bank.example/oauth/token",
    data={
        "grant_type": "authorization_code",
        "code": delegation_code,          # from the user's explicit consent screen
        "client_id": "agent-portfolio-helper",   # the agent's own identity
        "client_assertion_type":
            "urn:ietf:params:oauth:client-assertion-type:jwt-bearer",
        "client_assertion": agent_signed_jwt,     # proves the agent, not a stolen secret
        "redirect_uri": "https://helper.example/callback",
    },
    timeout=10,
)
token_resp.raise_for_status()
tok = token_resp.json()
​
print(tok["scope"])       # e.g. "accounts:read transactions:read"
print(tok["expires_in"])  # e.g. 900  -> 15 minutes, not forever
​
# Every downstream call carries the scoped token.
# There is no path from this token to "move money" unless
# payments:write was explicitly consented to.
accounts = requests.get(
    "https://api.bank.example/v1/accounts",
    headers={
        "Authorization": f"Bearer {tok['access_token']}",
        # Make the actor legible to the audit log:
        "X-Agent-Id": "agent-portfolio-helper",
        "X-Acting-For": user_id,
    },
    timeout=10,
)

Notice what’s absent: no username, no password, no browser pretending to be a human. The token is short-lived on purpose — 15 minutes of exposure beats a stored credential that works until the user changes it, which is to say never. And the two custom headers aren’t decoration. When the fraud team pulls the logs, the difference between “a user did this” and “agent portfolio-helper did this on behalf of user X with a read-only token” is the difference between a shrug and a root cause.

900 seconds beats forever

The scoped-token model buys you four properties the credential model can’t fake, and they’re worth naming because they’re the ones you’ll be asked about after the incident:

1. Revocation that works. Kill the token or the grant, and that one agent stops — without forcing the user to rotate a password used in eleven other places.
2. Legible logs. The agent is a distinct actor. You can answer “what did the robot do” without guessing.
3. Bounded damage. A leaked read-only token that expires in fifteen minutes is an annoyance. A leaked password is a breach.
4. MFA that still means something. Credential replay and session hijacking route around your second factor. Proper delegation keeps the human’s step-up auth where it belongs — at consent time — instead of letting an agent inherit a session that already cleared it.

This is not a banking story

Swap “brokerage” for anything. An agent with your email password can read every reset link to every account you own — it is your account recovery. An agent holding your CRM session can export the entire customer list in one call. An agent with your cloud console credentials can spin up resources, read secrets, and tear down production, all logged as you, because as far as the control plane knows, it is you.

Email, CRM, cloud consoles, internal admin panels, the SaaS tools your team wired into an assistant last quarter “just to try it” — every one of them is a Morgan Stanley waiting to find out an agent has been logging in as a human. The banks are simply the first with a fraud department large enough to notice and a regulator impatient enough to care.

The uncomfortable read: a lot of shipped agent “integrations” are credential reuse with a nicer UI, and the people who built them are hoping nobody asks which principal performed the action. Wall Street just asked. Your security team will ask next, and they’ll ask in a meeting you didn’t want to be in.

Give the agent its own name, its own token, and exactly the scope it needs — or keep handing out passwords and find out, like the banks did, that impersonation was never delegation.