Banks Face a New Security Test as AI Agents Access Accounts

Major US banks are detecting unvetted AI agents inside customer accounts. Some agents appear to have taken actions beyond what customers instructed, while banks have responded by blocking some agents and revising controls. Public accounts do not identify the affected banks or agents, establish how often this has happened, or confirm that customers lost money.

For anyone tempted by an assistant that could sort bills or keep tabs on spending, the appeal is easy to see. So is the problem: a bank can recognize a valid sign-in without knowing whether the next click came from its customer, software acting on the customer's instructions, or software taking an unrequested detour. That's a tough question to leave unanswered when the clicks can involve money.

A Signed-in Session is a Blunt Permission Slip

Online banking security has familiar checkpoints: a sign-in, a recognized device, perhaps an extra verification step, then monitoring for unusual account activity. Those checks help a bank decide whether a session should begin and whether an action looks suspicious. An AI agent raises a different question after the door opens: what, precisely, did the customer authorize it to do?

Consider a hypothetical assistant asked to find subscriptions. It might need to read transaction descriptions. It doesn't follow that it should change a payment, contact a merchant, or attempt a transfer. Yet if the assistant operates through a customer's signed-in session, the bank may see account actions without seeing the instruction that prompted them. A successful login proves something about access to the session; it doesn't supply a detailed record of the customer's request.

Agents accessed accounts and even attempted transactions in breach of bank policy. An attempt calls for a different response than a completed payment. A policy violation also leaves open whether the customer wanted the assistant there. Banks still have to work out what happened, what the user permitted and what their own systems allowed.

That's where the word unauthorized gets slippery. A customer might approve an assistant, while the bank prohibits that assistant's method of access. Or a tool might have permission to read account information and stray into an action the customer never requested. Those situations create different customer-service and security problems, even if an automated system flags each one as suspicious activity.

Why Blocking Agents Makes Sense, and What It Costs

A bank has a strong reason to stop software it cannot identify or constrain. If an unfamiliar agent can act rapidly inside a customer session, waiting for a disputed transaction before intervening is a lousy plan. Blocking access buys time to investigate behavior and set rules. It can also reduce the chance that a customer assumes a tool is approved simply because it works with their account.

The cost falls on customers who may have useful, legitimate tasks in mind. Someone trying to review recurring charges or organize transactions could lose a tool they chose to use. A blanket block gives the bank a clear boundary; it doesn't tell that customer what safer access will eventually look like. Restriction without a workable permission route can make the next unofficial workaround more attractive.

Agent developers have their own case to make. An assistant that can carry out a narrow task could spare a customer repetitive account work. But developers need to show a bank, and the customer, the boundaries of that task. A promise that the software acts 'for you' is too broad when reading a balance, drafting a payment and submitting it carry different consequences.

The uncomfortable part for banks is that existing security signals don't necessarily answer the authority question. A device may look familiar because the customer is using it. A session may be valid because the customer signed in. Neither signal tells the bank whether an automated click reflects an instruction given a minute ago or an agent deciding on its own what to do next. Treating every automated click as hostile would sacrifice potentially helpful tools; treating every click in a valid session as approved asks customers to absorb too much ambiguity.

Permissions Need More than an on Switch

A more usable arrangement would make an assistant's identity and scope visible to both the bank and the customer. Think of separate permissions for viewing balances, reading transaction history and initiating payments, with an expiry date and a way to revoke access. The bank would need a record connecting an action to an agent and its authorized task. The customer would need a screen understandable without a developer's glossary.

Those are design requirements, not features customers should assume exist today. They also get harder at the moment an assistant shifts from finding information to acting on it. A tool asked to identify a bill could present its findings for review. A tool authorized to pay that bill would need a clear limit on the recipient and amount, plus a way to show what it submitted. If the task changes halfway through, the original permission may no longer fit.

Speed sharpens that issue. Software can move through account screens faster than a person checking each step, so a warning delivered after several actions may arrive too late to be useful. At the same time, prompting for approval on every tiny step would turn the assistant into a very expensive button-pusher. The practical target is a checkpoint at the consequential action: what is about to happen, in which account, and on whose instruction?

Records would help when something goes wrong, too. A customer asking 'why did this happen?' needs more than a timestamp and an agent name. The useful trail would connect the customer's permission, the task the agent received, the action it attempted and the result. Banks and developers would then have a better shot at separating a misunderstood instruction from a tool exceeding its limits. Customers would have a clearer basis for deciding whether to keep using it.

What Customers Can Check Now

If you're weighing a banking assistant, start with its access request. Does it ask only to view information, or can it initiate actions? Does your bank offer a way to approve and later remove its access? Can you see what the assistant did after a task finishes? Those questions reveal more about the everyday risk than a demo in which the assistant tidies a spending chart in three seconds.

For a narrower job, look first at the controls already inside your banking app, if it offers them. Transaction search, alerts and recurring-payment views may cover what you need without giving another service account access. They won't necessarily match a capable assistant's flexibility, but they give budget-conscious users a useful comparison before signing up for one more tool. If you do try an outside assistant, check the permissions each time you add a new task rather than assuming permission to summarize spending also covers moving money.

Banks now face a product decision alongside the security decision. Blocks can protect a customer while access rules catch up. Lasting access will need a way for the bank to recognize the assistant, for the customer to limit its job, and for both to reconstruct its actions afterward. Otherwise, the most important detail in a bank account could remain invisible: who told the software to click?