AI agents in bank accounts: What customers should do?

The banks aren’t being hacked, at least not in the way the headlines imply. They’re being out-authenticated.

No breach of JPMorgan’s, Morgan Stanley’s, Bank of America’s, Citi’s, or Wells Fargo’s core systems has been publicly reported. Instead, Axios reported on October 22—and Reuters corroborated—that AI agents in bank accounts (major U.S. banks) are being detected and blocked. These agents operate in customer accounts, often after customers hand over their banking credentials.

That creates a new security problem in Black October: a valid login no longer proves that a person chose the action. It may only prove that an agent holding the customer’s credentials did.wideopencountry

AI Agents in Bank Accounts: What happened

Axios reported on Oct 22, citing people familiar with the matter, that banks are finding third-party AI agents inside customer accounts. Some agents tried actions the customer hadn’t asked for. Some called bank support lines.

Most agents get in with credentials the customer shared, which breaks the rule at most banks that customers must log in themselves. One executive told Axios the bank can’t easily tell agents apart, or know whether one was authorized or had gone rogue.

The motives are mixed. Banks cite security and liability. The FT also reported a fear that agents will push idle cash toward higher-yielding products, and JPMorgan’s CFO linked agents to deposit competition. Both can be true.

Timeline (2026)

• Oct 13: On JPMorgan’s third-quarter call, Jamie Dimon says the bank won’t let just any outside agent in. He warns of thousands of “rogue agents” and a “liability transfer” for customers who authorize one. (Forbes)
• Oct 14: Bank of America talks on its earnings call about limiting agent access to consumer deposits (secondary reports).
• Oct 16: The FT reports Citi bars third-party agents from logging in or transacting. Schwab’s CEO says it is blocking agents from moving funds (secondary reports).
• Oct 22: Axios publishes. Morgan Stanley says it hasn’t seen rogue agents. JPMorgan Chase has publicly warned customers not to share credentials. Wells Fargo confirms it has taken steps to block unauthorized agents, while its forthcoming agreement says it reserves the right to restrict or block certain third-party AI tools.
• Nov 24: Wells Fargo’s updated Online Access Agreement takes effect. Secondary reports say it treats requests sent through AI tools as the customer’s own. (Wells Fargo)

Our lens: from “who logged in” to “who decided”

Banks have spent twenty years on one question: is this the customer? Passwords, device binding and one-time codes all answer it. An agent acting with the customer’s blessing passes every one of those checks, and then makes its own choices.

That breaks “authorized” into three gaps, and each has a precedent.

We’ve seen this movie before. Credential sharing outruns controls; a breach or a lawsuit forces scoped tokens, and then the fight moves to liability. Agents compress that cycle from years to months, because they act instead of only reading.

Regulation E ties all three together. Liability turns on whether the customer told the bank the delegate’s authority had ended. As we read 12 CFR 1005.2(m), time is the legal variable. This is not legal advice.

What the three gaps imply for design

• Classify, but don’t lean on it. An agent driving the customer’s own browser looks like the customer. Score sessions, then gate risky actions on something the agent can’t fake.
• Bind approval to the action. The confirmation has to show payee and amount, and arrive on a channel the agent doesn’t control.
• Treat revocation as a first-class event. One customer action should end the agent’s access and record when it happened.
• Plan for the vendor breach. When an integrator is compromised, revoke every token at once, as Salesloft and Salesforce did on Aug 20, 2025, as part of the August 2025 Drift response

Two days before the Axios report, a different platform disclosed that stored customer secrets may have leaked: the Railway incident. No link has been reported between the two. The shared risk is structural. Anyone who stores delegated access is a target.

Who is affected?

Nothing public points to a compromise of bank core systems or large-scale credential theft.

What to do next?

Customers: seven steps today

1. Don’t give any AI tool your bank password, PIN, one-time codes or recovery codes. Most bank terms require you to log in yourself.
2. If you already did, change your password now. Then revoke the tool’s access in the tool itself, in your browser extensions and in any connected-app pages.
3. Tell your bank in writing that transfers by that tool are no longer authorized. Send it by secure message and keep a dated copy. Under Regulation E, that notice shifts most risk to the bank (but not absolutely). Do not treat this as legal advice, but confirm with a lawyer.
4. Review the last 30 to 60 days of transactions, payees, recurring payments, linked devices and contact details.
5. Turn on alerts for every transfer and profile change. An agent that changes your contact details can silence them too.
6. Prefer read-only, token-based connections that your bank approves. Ask which providers it supports.
7. If you must test an agent with money, fence it off. Use a separate low-balance account or a virtual card with a spending limit.
8. Do not rely on browser-extension or AI-tool deletion alone; change the bank password and review active sessions.

Before connecting any agent, ask five things. Can it move money? Where are my credentials stored? Can I cap spending? How do I revoke it? Has the vendor disclosed security incidents, and how did it respond?

Bank executives: eight decisions for the next 90 days

Keep the security rationale separate from the deposit-retention rationale in public statements. Customers hear both on the same earnings call, and a block that looks like protectionism weakens the security message.

Don’t announce a ban you can’t enforce. The credible end state is permissioned, auditable access, and most banks are reportedly moving toward read-only.

Security teams: controls that hold when detection fails

Score signals; don’t issue verdicts. Useful ones include driven-browser artifacts, TLS fingerprints that contradict the claimed browser, cloud-hosted ASNs, pasted input at machine cadence, deep-link session starts and missing device binding. Expect evasion.

A policy tiered by risk rather than by label (illustrative):

rule: automation-risk-tiering
when:
  any:
    - session.automation_score >= 0.7
    - session.device_binding == "none"
then:
  allow: [accounts.read, transactions.read, support.chat.open]
  step_up:
    - actions: [payee.add, transfer.create]
      method: passkey_assertion
      bind_to: [payee, amount, currency]
      channel: out_of_band
    - actions: [profile.change]
      method: passkey_assertion
      bind_to: [field, new_value]
      channel: out_of_band
  flag_to_agent: [support.chat.open]
  log: [session_id, automation_score, signals, decision]

Issue delegated tokens, not passwords. OAuth token exchange (RFC 8693) names the acting party, rich authorization requests (RFC 9396) express transaction limits, and DPoP (RFC 9449) binds the token to a key. Illustrative claims:

{
   "iss": "https://auth.examplebank.com",
   "sub": "customer-8f3a",
   "act": { "sub": "agent:acme-assistant/2.3" },
   "scope": "accounts:read",
   "authorization_details": [{
 	"type": "payment_initiation",
 	"actions": ["initiate"],
 	"instructedAmount": { "currency": "USD", "amount": "250.00" },
 	"creditorAccount": { "id": "payee-4412" }
   }],
   "cnf": { "jkt": "" },
   "exp": 1792717200
 }

Every action then carries an agent identity, a consent record, a limit and an expiry. Revoking the token ends access without touching the customer’s password.

Self-serve checks

Customers: a five-minute audit

• Bank site or app: open the list of devices, active sessions and connected third parties, and remove anything unfamiliar.
• Browser: list extensions that can read your bank’s pages. Remove AI and automation add-ons you don’t use.
• AI tools: open each tool’s connected accounts and saved logins. Delete stored bank credentials.
• Contact details: confirm the phone number and email on file are still yours.
• Payees and recurring payments: look for any you didn’t create.

Banks: detection queries (illustrative)

Adapt these to your own session, payee and transfer tables. Thresholds are starting points, not benchmarks.

-- 1. New payee, fast transfer, automated-looking session
 SELECT s.session_id, s.customer_id, p.payee_id, t.amount, s.automation_score
 FROM sessions s
 JOIN payee_adds p ON p.session_id = s.session_id
 JOIN transfers t  ON t.session_id = s.session_id
 WHERE t.created_at BETWEEN p.created_at AND p.created_at + INTERVAL '15 minutes'
   AND s.automation_score >= 0.7;

 -- 2. Contact details changed, then a large transfer within 24 hours
 SELECT c.customer_id, c.changed_at, t.amount, t.created_at
 FROM contact_changes c
 JOIN transfers t ON t.customer_id = c.customer_id
 WHERE t.created_at BETWEEN c.changed_at AND c.changed_at + INTERVAL '24 hours'
   AND t.amount >= 1000;

 -- 3. Support contact shortly after an automated login
 SELECT s.customer_id, s.session_id, k.channel, k.opened_at
 FROM sessions s
 JOIN support_contacts k ON k.customer_id = s.customer_id
 WHERE k.opened_at BETWEEN s.started_at AND s.started_at + INTERVAL '30 minutes'
   AND s.automation_score >= 0.7;

Banks: test before someone else does

• Can an agent finish login with a shared password and a forwarded one-time code?
• Does step-up bind to payee and amount, or only to “is this the user”?
• Can an agent add a payee, then move money inside the cooling-off window?
• Can an agent change contact details, then receive the alerts that would have warned the customer?
• Can an agent get through the contact center by voice or chat?
• Can your audit trail tell a customer, a delegated agent and a criminal bot apart afterward?

Bank positions and sanctioned lanes

Positions differ in tone and detail, and several come from secondary reports. Check each bank’s own channels before relying on them.

The regulatory gap matters. The CFPB’s 2024 open banking rule under Section 1033 is enjoined while the Bureau rewrites it, and no federal rule defines delegated agent access. (Cozen O’Connor)

After the fire: build the lane, shrink the blast radius

Blocking buys time. It doesn’t fix the problem, because customers will keep using agents. The durable answer is a lane where agents are identified, scoped and revocable.

• Give agents an identity. Every action should name the agent, the customer and the consent behind it.
• Default to read-only. Grant payment scopes per payee, per amount and per expiry.
• Add cooling-off windows for new payees and contact changes, so an agent can’t chain them within minutes.
• Make revocation obvious. One screen, one tap, one timestamp, visible to the contact center.
• Hold vendors to a standard. Ask how they store credentials, how fast they can revoke tokens and what they disclose after an incident.
• Rehearse the vendor breach. Drift ended in mass revocation. Have your own version ready.

Where Astra can help

Most of what this piece describes can be tested before an attacker does it for you, or before a customer’s overeager AI assistant does it by accident.

If you’re exposing agent-facing features such as APIs, assistants, MCP servers or open banking integrations, our pentesters attack them the way a hostile agent would. That means goal hijacking, excessive agency, plugin abuse, indirect prompt injection and leaky APIs. Findings map to the OWASP LLM Top 10 and MITRE ATLAS.

Three places we’d start:

• Money-movement and step-up flows. Can an agent chain actions the customer never approved?
• API and integration surface. Find the shadow and undocumented endpoints an agent or aggregator could reach.
• Every release that touches auth, tokens or approvals. Continuous pentesting means these get retested as they ship, not at the next annual review.

Every finding is human-verified and comes with fix guidance. Talk to an Astra security expert.

Live updates

Times are UTC. We add dated entries as banks and regulators publish.

Oct 23: Initial post. Includes Wells Fargo’s confirmation of blocking steps, the Nov 24 agreement change, Citi’s public statement, and Bank of America and Schwab positions from secondary reports.

What we still don’t know

• Have customers lost money to agent-initiated transfers? That decides whether this is a fraud-loss problem or a policy problem.
• Which banks saw agents exceed instructions, and which restricted them as a precaution? That tells us how much of the risk is observed and how much is anticipated.
• How will Regulation E apply to software that exceeds its instructions? That decides who absorbs the first losses.
• Will the CFPB’s revised proposal address delegated agents? That decides whether banks build the rails voluntarily or under a rule.
• What will Wells Fargo’s Nov 24 terms actually say? We confirmed the upcoming agreement exists but couldn’t verify the AI wording.
• Will an agent vendor disclose a credential-store incident? That would turn the first row of our lens into a live event.

Sources