US banks push back on AI agents using shared passwords as per-agent identity launches

US banks are detecting unverified agentic activity on customer accounts, and at least one major bank is telling customers to stop handing over their logins. According to Axios reporting cited in a dev.to analysis, Chase has warned customers against sharing credentials with third-party agents, because the bank has no way to verify who, or what, is on the other end of the session.

A legitimate agent looks like an account takeover

From a bank's perspective, an approved agent using your password and a criminal using a stolen copy generate almost identical signals: correct credentials, an unfamiliar device or location, unusual hours, rapid navigation and no human typing rhythm. That is precisely the behaviour fraud-detection systems are designed to catch, so agent traffic reads as an account takeover in progress rather than as automation.

The liability lands on the account holder. Because the agent borrows your identity, everything it does is recorded under your name with your permissions. A bad transaction or a leaked export appears in the audit trail as something you did.

This is happening at scale. In 1Password's Developer Pulse survey, cited by the dev.to piece, 65% of developers said they are expected or encouraged to use AI agents, while only 33% said they have a secure way for agents to sign in. Credentials end up in prompts and config files not mainly through carelessness, the analysis argues, but because infrastructure for safe agent access has not existed until now.

The spectrum of agent login, worst to best

The dev.to analysis ranks the patterns in use today from worst to best.

Shared passwords remain the most common and worst option. They work everywhere immediately, but carry your full permissions with no scoping, no expiry and no way to tell agent actions from your own. A leaked prompt means a leaked password, and rotating it breaks every agent that depends on it.

Long-lived API keys are a step up: separate from your human login and individually revocable. But they rarely expire, are rarely tightly scoped, and get copied into repositories, CI logs and chat transcripts. A broad, non-expiring key offers little real improvement over a password.

Scoped, short-lived tokens are the shape security teams want: OAuth-style credentials limited to specific permissions for minutes or hours, so a stolen token expires quickly and can do limited damage. The catch is uneven support. Many services agents need still do not offer fine-grained, short-lived tokens, and wiring up issuance and refresh for every agent and service is genuine engineering work.

Per-agent identity arrives

The next pattern, per-agent keys with human approval, is what 1Password for Agents shipped on October 22, 2026. As 1Password describes it, a vendor claim based on its launch materials, each agent signs in with its own unique digital key, you approve every sign-in attempt from your own device, and the underlying password never reaches the agent. The company lists the feature as included in its Individual and Family plans.

1Password names Meta's Muse and Grok Bot as launch partners rolling out, with Claude Duet, ChatGPT Work/dots and Townie listed as coming soon, plus integrations in progress from Browserbase, Browser Use, Perplexity and Ramp. The dev.to piece advises treating that roster as a roadmap until each integration is live, though the mix is notable: browser agents and finance tooling are exactly where credential-sharing risk concentrates. The trade-off is that human approval does not scale to agents authenticating constantly in the background.

A second launch in the same week, IDENTOS PolicyArc, is described by the same analysis as another early, concrete attempt at per-agent identity.

Why it matters

Banks are the first institutions to push back, but the same pattern spans cloud consoles, payment dashboards, ad accounts and production SaaS tools. Shared credentials turn every agent into an actor that wears your name, your permissions and your liability, and fraud systems cannot distinguish it from an attacker. The practical fix, in the order the dev.to analysis recommends: inventory what your agents can already reach, eliminate shared passwords, then layer on scoping, expiry and readable audit logs. With 65% of developers under pressure to deploy agents and only a third holding a secure sign-in method, per-agent identity is shifting from best practice to a prerequisite, and vendors have only just started shipping it.