AI Agent Bank Access: A Password Is a Liability Transfer

Somewhere in your onboarding flow is a field that asks the user for a username and password to a system you do not own. It works. It demos beautifully, and it is why your agent can do things instead of talking about them.

Bank of America spent this week emailing retail customers to ask them not to fill it in. The notice is headed "Protecting your finances in the AI World," and the line that matters is not the warning but the one after it: "If you do share your credentials, keep in mind that you're responsible for activity resulting from that access."

That is not a bank being stern. It is a bank describing a definitional exclusion in federal law. Under Regulation E a password is an "access device," and a transfer initiated by someone the consumer furnished that device to is not an "unauthorized electronic fund transfer" at all. The $50 liability cap does not get weaker. The category it lives in disappears.

The email was posted publicly on 27 October and a Bank of America spokesperson confirmed it to TechCrunch. So the field in your signup flow is not an integration. It is a liability transfer, and it transfers to your own customer.

What this costs you, in four places

Who absorbs a loss. With a delegated token, a disputed transfer stays a dispute — the bank's process, the bank's reimbursement rules. With a furnished password, the regulation hands the bill to the person who typed it, and your support queue inherits the conversation. Explaining your architecture will not win it.

Whether your access survives the quarter. Bank of America's Online Banking Service Agreement already bars sharing credentials with a third party, carving out only legal guardianship and power of attorney, and reserves suspension or termination "in our sole discretion." A credential-based integration is a terms breach on day one, not after an incident. Jamie Dimon told analysts on JPMorgan's 13 October earnings call that the bank will not let outside agents in; a Chase spokesperson told CBS News that customers should not give their username and password to anyone.

Whether offboarding is a button or a phone call. Revoking a token is a click. Revoking a password means your user calls their bank, waits, and rotates a credential that breaks every other integration they own. That is your churn flow, and you control none of it.

Whether you can sell to a regulated buyer at all. Any vendor security review worth the name asks how you authenticate to third-party systems. "We hold the customer's bank password" ends the review — we have watched that answer kill a late-stage deal.

Rebuilding auth after launch is not a refactor. It is re-onboarding every user you have.

What is on the record, and what is not

Two kinds of claim are circulating this week and they deserve different weight.

Documented, in primary sources: the Bank of America email, the Regulation E definitions, and the terms of use quoted here. Texts with URLs, which you can check yourself.

Self-reported, and thinner: the claim that major U.S. banks are right now detecting unauthorized AI agent activity inside customer accounts comes from an Axios scoop resting largely on unnamed bank sources. No bank has published data, there is no incident count, and no loss has been attributed to it; CBS News relayed the finding through an interview with the Axios reporter rather than confirming it. Reports that Bank of America restricted agents to read-only and that Morgan Stanley blocked them outright share that sourcing, and Morgan Stanley's claim to have seen no unauthorized agent activity is the firm's assertion about itself. White House AI czar David Sacks' position that most of this traffic is user-authorized rather than an attack is his own public claim, contradicted by the banks' reading of their contracts.

The architecture argument does not depend on the scoop. It rests on the regulation and the contracts, and those do not move.

The clause that deletes the cap

12 CFR 1005.6(b) caps a consumer's loss on an unauthorized electronic fund transfer at $50, or $500 without prompt notice. That is the protection everybody assumes is simply there. Then 12 CFR 1005.2(m)(1) says the term "unauthorized electronic fund transfer" "does not include an electronic fund transfer initiated ... by a person who was furnished the access device to the consumer's account by the consumer." And 1005.2(a)(1) defines an access device as "a card, code, or other means of access to a consumer's account."

A password is a code. That is the entire argument. Hand the credential over and a transfer your agent makes — or that anyone who compromises your agent makes — is not unauthorized. It is authorized, by the customer, through you.

You cannot fire the agent

U.S. Bank's live Digital Services Terms of Use is blunter than any of the coverage. Activity performed with your Login Credentials "will be presumed to be authorized by you unless you tell us otherwise," the bank is "not responsible for managing the authority of your third-party relationships," and to stop that access "you must contact us to block access to Digital Services until new Login Credentials are established."

Read that as an engineer. There is no revocation endpoint because there is no grant to revoke: the agent is not a delegate, it is the customer. Revocation is a credential rotation done by a human on a phone call, and it is indiscriminate — it also kills the budgeting app, the bookkeeper's read-only access, and every competitor's integration. An agent you cannot switch off is the same control-plane failure as an agent that mutes its own alerts: the off switch is somewhere you cannot reach.

The sanctioned path, in the bank's own words

The same agreement names the architecture it will accept: "you login directly with us and provide sharing instructions ... You can manage your data sharing instructions, and revoke your authorization, using Digital Services." It describes the other path just as plainly — providing login credentials authorizes a service to access the account "which may include the ability to initiate transfers."

Delegated, scoped, revocable by the customer: the OAuth shape, described by a bank that will not let you have it any other way.

The uncomfortable part is that no federal mandate currently forces a bank to open it. Part 1033 is still in the CFR, but a Federal Register check this week turned up no reissued Personal Financial Data Rights rule. The tokenized route is the bank's to grant — which makes being easy to grant it to a commercial position, not a compliance checkbox.

The decision, in week one

If you have not shipped yet, this is cheap. Three rules:

1. Never take a third-party credential into your system. Not encrypted at rest, not "only in memory," not through a headless browser. Possession is the liability event, whatever your hygiene.
2. Use the provider's delegated path where one exists — OAuth, a bank-sanctioned aggregator, open-banking APIs. Scoped read where you only read; explicit, separately granted write where you move money.
3. Make revocation a feature you own. A user should be able to kill your access from inside your product, and you should be able to prove when it was killed.

If you already shipped credential capture, the migration is a product problem rather than an auth problem: every existing user has to re-consent through a flow that does not exist yet, while the old path keeps working. Budget it as a feature, name an owner, put a date on switching the old path off. Its cost grows with your signup curve — the one curve you were hoping would grow.

This is most of the work we get called in for: an auth decision made in week one, surfacing in month nine as the blocker on an enterprise deal.

Key takeaways

• A password is an "access device" under 12 CFR 1005.2(a)(1), so furnishing it pushes the transfer outside the definition of "unauthorized" in 1005.2(m)(1), and outside the caps in 1005.6(b).
• The email restates an existing contract term: Bank of America's service agreement already banned credential sharing outside guardianship and power of attorney, and reserves termination at its sole discretion.
• Revocation does not run through your product. U.S. Bank requires a phone call and a credential rotation that breaks every other integration the user has.
• The claim that banks are detecting rogue agents right now is single-sourced to unnamed officials. The contract and regulation problems need no scoop.
• Credential capture versus delegated authorization is a week-one decision setting four outcomes: loss absorption, access continuity, offboarding cost, and whether a regulated buyer can say yes.