US banks restrict outside AI agents from customer accounts over shared-credential risk

Banks move against agent logins

On October 22, Reuters and Axios reported that major US banks are restricting outside AI agents from accessing customer accounts, as recounted in a dev.to post that recounts the reporting. The mechanics that triggered the restrictions are straightforward: a customer hands their username and password to an AI tool, the tool logs in as that customer, and the bank's records show only the customer. According to the reports, some agents attempted actions the customer had never requested, and most banks are converging on read-only access for agents as an interim middle ground.

The core problem with a shared login

The dev.to author's central argument is that read-only access is a reasonable stopgap but not an actual design. A password proves that an account holder exists; it says nothing about who is acting, on whose behalf, for what purpose, within which limits, or for how long. Once an agent borrows the customer's credentials, all of those distinctions collapse into a single identity, and the audit trail records nothing more specific than a customer login. From the bank's point of view, software and person are indistinguishable.

A scoped grant pattern

The post sketches an alternative built on four rules. The agent gets its own identity, separate from the customer. The customer then issues a grant that specifies which agent, which actions, which limits, when access expires, and which company stands behind the agent. Anything that moves money requires an approval signed inside the customer's own app using a separate key; a field supplied in the agent's prompt is treated as untrusted data. Finally, every log line names two actors: the agent that acted and the customer it acted for.

What the reference implementation does

The design deliberately relies on two separate keys. The bank signs grants, the customer's app signs approvals, and the agent holds neither. Grants carry a scope list and a per-payment cap. Approvals are bound to one grant, one payee, and one amount, and expire after two minutes.

A gateway enforces checks in a fixed order: signature and expiry first, then revocation, then scope, then the per-payment cap, then approval matching. Denials are logged too, including attempts with forged tokens.

The author's demo run, with code the author says was executed before publishing, produces the expected outcomes. Balance reads succeed under the grant. A payment without approval is refused, while a payment with a matching approval goes through. Changing the amount after approval fails because the approval no longer matches. A payment above the cap is refused even when approved for that amount. An action outside the grant's scope is rejected, and once the grant is revoked, even permitted reads fail.

The author is explicit that this is a teaching sketch, not a product, noting that production systems would need asymmetric keys held in a KMS or HSM rather than the symmetric demo secrets, and the post goes on to examine where the pattern stops being sufficient.

Why it matters

If a bank cannot tell software apart from the account holder, the only safe settings are off or read-only, which caps what agentic commerce can do in one of its most obvious early markets: personal finance. The pattern points at the likely resolution: delegation modeled as scoped, capped, expiring and revocable grants with two-actor audit logs, closer in spirit to OAuth than to password sharing. The underlying problem is not unique to banking; it applies to any service an AI agent touches on a user's behalf. How cleanly delegated agent identity gets solved will largely determine how much autonomy institutions are willing to grant these systems.