The Agent Logged In as the User, and the Bank Can't Tell: Consent Is Not Authorization

On October 22, 2026, two things landed on the same day. Axios reported that major U.S. banks — Morgan Stanley, Bank of America, JPMorgan, Wells Fargo and others — are detecting unauthorized third-party AI agents operating inside customer accounts, and that many banks "are broadly not able to parse whether agent account activity is user-directed" (Axios, Oct 22 2026). The same day, 1Password shipped "1Password for Agents," which lets an agent sign in on a user's behalf without ever seeing the password (1Password, Oct 22 2026; TechCrunch, Oct 22 2026).

The collision is the whole story. In the Axios cases, the agent is not breaking in — it logs in with the customer's own username and password, which the customer handed over on purpose. And Axios states the rule plainly: "Even if permitted by the user, this goes against the guidelines of most banks requiring that humans log in to their own accounts." So the user said yes, and it is still a breach — because the service that has to grant the access never saw the user say yes. It only saw a login.

That gap decides who carries the loss, and it is not specific to banks. The first time your agent touches any account you do not control — email, calendar, SaaS, payments — you will hit the same wall. This piece is about the wall, and about the smaller fix that actually holds: a delegation boundary instead of a shared secret. You leave with a six-question checklist to run before any agent touches someone else's account.

---

1. The operator, the context, and the mistake

You build or buy agents that act on a user's behalf against services you do not control. Maybe your product's agent needs to read a user's inbox, file a ticket, pay an invoice, or check a balance. The service on the far side is not yours, and you cannot change its rules.

The default way to make the agent "logged in" is the shortest path that works in a demo: hand it the user's credentials, or log in as the user. It works instantly. It works for every site. There is no integration to build and no API key to request. That is exactly why operators reach for it.

The mistake, named specifically: when an agent needs to act for a user against a third-party service, operators treat "the user gave us their credentials" as authorization. It is not. It is consent. Consent is the user saying yes. Authorization is the service granting a bounded, verifiable, revocable right to act. Handing over a password produces the first without the second, and the service on the far side is left with two bad options: accept a login it cannot attribute to anyone but the human, or refuse all agents.

The banks chose "refuse." Morgan Stanley began blocking third-party agents; JPMorgan, Bank of America and Citi are restricting them; and most banks are moving toward read-only access through aggregators like Plaid — the same arrangement they already give budgeting apps (Axios). JPMorgan CEO Jamie Dimon had already set the line on the bank's Q3 earnings call two weeks earlier: "You don't want rogue agents, and there could be thousands of them" (PYMNTS, Oct 2026).

2. Why the obvious fix does not hold

The obvious fix is to stop exposing the password. That is what 1Password for Agents does, and it is a real improvement. The agent presents a unique digital key to prove its identity to 1Password, the person reviews the requested credential and approves it on their own device, and 1Password "fills it directly into the sign-in form instead of sending it to the agent" (1Password press release, Oct 22 2026). 1Password names the problem it is solving: "Handing over a password, secret, or credential is a common shortcut to an agent, but can leave people with sensitive information in places they can no longer control as a copy gets saved for the next time" (1Password).

That removes the credential exposure. It does not remove the thing the bank is objecting to. The agent still signs in as the human — 1Password signs it in with the human's own credential, on the human's own login. The service on the far side still sees what looks like the human logging in. So the authorization gap — the inability to tell a user-sent agent from a rogue one, to scope the action, to revoke just the agent — stays open. Better hidden is not the same as authorized.

That last step is our reading of the mechanism, not a claim 1Password makes. It is worth stating plainly, because it is the part most writeups skip: the market's first fix lowers the blast radius without closing the attribution gap.

Here is the mechanism, in one line: credential-sharing collapses the agent into the human, and that destroys per-action authorization.

A login is an identity assertion. When an agent logs in with the user's username and password, the service sees the human. It cannot attribute the action to an agent, cannot scope it, cannot rate-limit it, cannot revoke the agent's access without cutting off the human, and cannot tell an agent the user sent from one that went rogue. That single fact explains the entire news cycle: banks "cannot parse whether agent account activity is user-directed," the delegation itself — not the intent — is the terms violation, and read-only-through-an-aggregator is the only channel that keeps a verifiable boundary.

The industry is not confused about this; it is already building the boundary. The standards track that formed around the same time points one direction: agent identity plus attenuated, consented, revocable delegation.

  • The IETF's draft-hamr-oauth-agent-delegation defines a chain of delegation links in which "each link can only narrow the scope, floors, and expiry of the link before it," with per-call classes (read/write/execute, as in chmod) and an optional count per class, built on signed HTTP messages (IETF draft). It is explicit that a probabilistic model is not a limit: an instruction to "only search" is a request to the model, not a constraint on it.
  • The IETF's draft-mishra-oauth-agent-grants profiles OAuth to identify the agent client instance, capture authenticated user consent at the authorization server, and issue resource-bound, sender-constrained tokens that can be attenuated via token exchange (IETF draft).
  • Microsoft's Entra Agent ID models agents as distinct identities, with an "attended" on-behalf-of delegated flow scoped to what the user consented to, versus an "unattended" client-credentials flow (Microsoft Learn).

All three are drafts or vendor designs with no adopted standing — cite them as the shape of the forming solution, not the solution. But the shape is consistent, and it is not "hide the password." It is "give the agent its own identity and a grant the service can verify."

4. The delegation boundary: six questions before an agent touches an account

This is the reusable object. Run it before your agent touches any third-party account, and run it again on any agent you are about to let into your own.

  • Identity.** Does the agent have its own verifiable identity, or is it wearing the user's? If the service cannot name the agent as an agent, it can only see the human.
  • Scope.** Is the grant the narrowest capability that works — read vs. write vs. execute, with limits — and is it bound to a specific resource? "Search" and "book" are different calls; the fare example in the IETF draft is a search that became a non-refundable booking.
  • Consent.** Was consent captured at the authorization server and bound to the principal and the specific request — or was it just typed into a prompt? A prompt is a request to a probabilistic model. It is not a limit on it.
  • Revocation.** Can the user revoke one agent's grant? Does deleting the app actually cut it off, or does a saved credential keep working? The user needs an off switch that turns off the agent, not their whole account.
  • Audit.** Does the grant record the delegation path (user → agent → client) and every action, so you can reconstruct yesterday in minutes? Most operators cannot: only 12.5% of organizations can consistently trace an agent's full path from instruction through tools and APIs to outcome (Salt Security, State of Agentic AI and API Security 2H 2026).
  • Liability.** Who owns the loss when the agent misbehaves — and does the service's rulebook assign it to the user? (See section 6.)

If you cannot answer all six, you do not have a boundary. You have a shared secret and a hope.

5. Two worked examples

Example one: the personal agent that shops. Meta launched Muse as a personal agent that "can open a browser, fill out forms, and negotiate on their behalf" and can connect to services including bank accounts; Meta says people choose which apps it connects to and how much access it gets, and can disconnect at any time (Meta, Sept 8 2026). Run the checklist from Amazon's side. Amazon blocked Muse from shopping on Amazon.com with the popup "Continued access by an unauthorized AI agent violates Amazon's Conditions of Use," saying it never agreed to the access and that Muse does not identify itself as AI (GeekWire, Sept 20 2026). The lesson is not that Muse is malicious. It is that an agent that does not identify itself as an agent cannot be authorized by the service it acts on — even when the user is happy, even when it never sees the password. "Unannounced" reads to the service as "unauthorized."

Example two: the bank account. A user hands your agent their banking login so it can pay a bill. Run the checklist. Identity: the agent has none; the bank sees the user. Scope: none — the login grants everything the user can do. Consent: typed into your app, not captured at the bank. Revocation: the user would have to change their password, which also cuts off every other device. Audit: the bank's logs show a human, and so do yours. Liability: see the next section. Every answer fails. That is why Morgan Stanley blocked it and the others restricted it — not because the agent was evil, but because the bank could not see who authorized what.

6. Liability follows the credential, not the intent

This is the part that moves risk onto the user, and it is the part to handle carefully, because it is genuinely unsettled law.

Regulation E's definition of an "unauthorized electronic fund transfer" excludes a transfer "initiated by a person who was furnished the access device to the consumer's account by the consumer, unless the consumer has notified the financial institution that transfers by that person are no longer authorized" (12 CFR 1005.2(m)). And "person" is defined to include an organization, "including a corporation" (12 CFR 1005.2(j)). The CFPB's official interpretation adds that if a consumer furnishes access and grants authority to a person "who exceeds the authority given, the consumer is fully liable for the transfers unless the consumer has notified the financial institution" (CFPB, interpretation of 2(m)).

Read that against an AI agent. The rule tends to place the loss on whoever held the credential, not on the agent's maker — and the user cannot prove what they actually authorized. Neither, increasingly, can the operator: only 17.5% of organizations can automatically stop a misbehaving agent in production, and 95.8% of attack attempts Salt Labs analyzed originate from authenticated sources — "rogue agents operating with legitimate credentials but no human oversight, no rate limiting, and no behavioral guardrails" (Salt Security).

To be precise about what we do and do not know: no regulator or court has decided whether handing a password to an AI tool triggers this exclusion. This is an open question with the rule text as its anchor — not a settled outcome. Do not tell your users they are covered, and do not assume the agent's vendor is on the hook. Until the delegation boundary exists, "the user consented" is the fact that moves risk onto the user rather than off the operator.

7. What to do first

Before your agent touches anyone's account, pick one flow — the highest-risk one, the one that moves money or sends mail — and run the six questions on it in writing. For each, write the answer, not the intention. Where the answer is "the agent logs in as the user," you have found the gap. The smallest first step is to stop shipping credential-sharing as the default for that flow: request a scoped, revocable grant instead, and if the service cannot grant one yet, use read-only access through an aggregator rather than a full login. Read-only is not a defeat; it is the only channel the banks themselves sanction today.

Then do the two things that cost nothing and close the audit gap: log the delegation path (user → agent → client) for every action, and give the user a revoke button that turns off the agent without turning off their account. If you can reconstruct yesterday in minutes and cut off one agent on demand, you are already ahead of most organizations surveyed.

---

Consent is what the user gives. Authorization is what the service can verify. Handing over a password produces the first without the second — and because the rule that follows the credential puts the loss on whoever held it, the user absorbs the risk while the operator cannot even prove what the agent did. Hiding the password lowers the exposure; it does not close the gap. The fix that holds is a delegation boundary: a distinct, verifiable agent identity, a narrow resource-bound and revocable grant consented at the authorization server, an audit trail of the delegation path, and a named owner of the loss. That is the direction the IETF's agent-delegation drafts and Microsoft's agent-identity model are already pointing. Build the boundary, not the shared secret.

---

Sources

Honest-scope note: The Axios report is sourced to unnamed people and Reuters could not independently verify the specific incidents; Morgan Stanley's spokesperson said the bank "has not observed instances of rogue AI agents accessing our platforms" even as it began blocking third-party agents as a precaution. So the defensible, corroborated claim is narrower than the headline "rogue agents": banks cannot attribute agent activity, and the delegation itself breaches their terms. The claim that 1Password's approach leaves the service-side authorization gap open is our inference from the mechanism — the agent is still signed in as the human — not 1Password's stated position; 1Password's stated gain (the agent never sees the credential) is real and we do not dispute it. The Regulation E point is an open legal question: no regulator or court has decided whether handing a password to an AI agent triggers the credential-holder exclusion, so we present the rule text as the anchor, not a liability outcome. Salt Security is an API-security vendor surveying its own concern area with 380+ self-reported respondents; "confirmed or suspected" is a wide bucket and the figures are directional. The IETF drafts are individual Internet-Drafts with no IETF standing and may change or expire; Microsoft Entra Agent ID is a vendor design — all three are cited as the shape of a forming solution, not as an adopted standard. The bank restrictions are current as of the October 2026 clampdown and may move.

---

X entryway list (distribution entryways named in the approved angle)

Hook type, the one claim each post carries, and whether it links to the article:

  • Hook: surprising proof point.** Both sides of the market said the same thing in one 48-hour window: on Oct 22 2026 Axios reported U.S. banks detecting AI agents inside customer accounts they never authorized — and admitting they cannot tell user-directed activity from a rogue agent — while 1Password shipped a way to let agents log in "without seeing your password." Better hidden is not the same as authorized. → Links to the article (the same-day collision is the entry; the article is the mechanism behind it).
  • Hook: mechanism.** Credential-sharing collapses the agent into the human. The service sees the user's login, so it can't attribute the action, scope it, rate-limit it, or revoke just the agent — which is exactly why banks "cannot parse whether agent activity is user-directed," and why the delegation itself, not the intent, is the breach. Consent is what the user gives; authorization is what the service can verify. Password-sharing produces the first without the second. → Links to the article (the mechanism stands alone; the article delivers the fix).
  • Hook: workflow.** The delegation-boundary checklist — six questions before any agent touches someone's account: does the agent have its own verifiable identity; is the scope the narrowest that works and resource-bound; was consent captured at the authorization server; can the user revoke it and does deleting the app cut it off; does the grant log the delegation path and every action; and who owns the loss when it goes wrong. → Links to the article (the checklist is the reusable unit; the article is the full worked version).
  • Hook: risk.** Liability follows the credential, not the intent. Regulation E excludes transfers made by a "person" — including companies — the consumer furnished their credentials to (12 CFR 1005.2(m)). So the loss tends to land on whoever held the credential, not the agent's maker — and the operator often can't prove what was authorized either: only 12.5% of organizations can trace a full agent path, only 17.5% can auto-stop a misbehaving agent. → Links to the article (the liability consequence is the emotional entry; the article names it as an open legal question with the rule text as anchor).
  • Hook: result.** The agent you can actually trust with an account is the one the service can verify: its own identity, a narrow revocable grant consented at the authorization server, and an audit trail of what it did. Do that and "the agent did it" becomes a checkable fact instead of a hope — the same direction the IETF's agent-delegation drafts and Microsoft's agent-identity model are already pointing. → Links to the article (the result + the forming-standards pointer stand alone; the article is the framework that gets you there).

Note: actual X posts are not written here — that is the distribution stage, after this draft is approved.