On 22 October 2026, Axios reported that major US banks are detecting unauthorized third-party AI agents inside customer accounts, and that some of those agents attempted actions that appeared independent of what the user asked. Reuters carried the report the same day. This article sets out what the report says, what it does not say, and what a per-action checkpoint changes for a bank that wants to let some agents act while keeping control of money movement.
What Axios reported
The report rests mainly on people familiar with the matter. Its main points, paraphrased:
- Banks named. Morgan Stanley, Bank of America, JPMorgan, Wells Fargo, and others are racing to contain the risks of agents in customer accounts.
- How the agents get in. The agents typically use the customer’s permission and login credentials. Most banks’ rules require customers to log in to their own accounts.
- What the agents did. Some banks tracked agents contacting call centres or taking actions independent of user instructions.
- What banks are doing. Morgan Stanley has begun blocking third-party agents from its platforms, according to sources. JPMorgan, Bank of America, and Citi are restricting agents. Banks are rewriting their terms of service because they struggle to tell a human from an unauthorized bot.
- Read-only access. Most banks have authorized, or are moving toward, read-only access for agents, similar to the access already granted to budgeting apps.
- Preparation. Banks are investing in preventing worst-case scenarios and planning for the day after an incident, including how to secure or restore customer access.
What the report does not say
The report does not describe customer losses, a confirmed breach, or action by a regulator. A Chase spokesperson said customers should not share usernames and passwords with anyone. A Morgan Stanley spokesperson said the bank had not observed instances of rogue AI agents accessing its platforms. An unnamed bank executive said it is hard to tell whether a user authorised an agent or whether the agent acted on its own.
The report documents a control problem that banks are working on now.
Why a login check cannot answer the question
When a customer hands an agent their password, every request the agent makes carries the customer’s identity. The bank sees a valid session. It cannot see that software chose the action, which instruction the customer gave, or whether the action matches it. The bank has two blunt options at that point: allow the session or block anything that looks automated. Blocking protects the account and also stops the agents customers want to use.
Read-only access narrows the risk because a balance check moves no money. It also leaves the hard question open for the moment agents are allowed to act.
What a per-action checkpoint changes
A runtime checkpoint evaluates each action an agent proposes before it runs. It needs the agent to use its own identity, separate from the customer’s password, and to send each proposed action through a channel the bank governs. The checkpoint then returns one of four outcomes: allow, warn, require_approval, or block. The strongest matching rule wins.
The policy below is a synthetic example for a retail account. It shows how a bank could allow useful agent work and still keep a person in front of money leaving the account.
| Proposed action | Outcome | Why |
|---|---|---|
| Read balances and transactions | allow | Within the delegated scope; no money moves |
| Move money between the customer’s own accounts at the same bank | warn | Reversible; recorded and sampled for review |
| Pay an existing payee below the customer’s chosen limit | allow | Inside the limit the customer set for the agent |
| Pay a new payee, or any payment above the limit | require_approval | Money leaves the account to a new or larger destination; the customer confirms the exact payment |
| Change contact details, passwords, or security settings | block | Outside any agent delegation |
| Any action after the customer withdraws the delegation | block | The authority no longer exists |
require_approval puts a person in front of money leaving the account
With require_approval, the checkpoint holds the exact action, with its amount, payee, and date, and asks an authorised person to decide. For a retail customer, that person is the customer. For a corporate account, it is the treasury checker the client named. The approval should cover only the action the person saw. If the agent changes the amount or the payee afterwards, the approval no longer applies and the action is evaluated again.
We built a held-payment release Process in October 2026 for an analyst briefing, with draft agents, synthetic data, and no payment rail. Three agents verify the instruction, refresh screening, and prepare a release recommendation, and a person in Payments Operations authorises the release. The policy blocks confirmed sanctions matches, duplicate payments, and holds with no documented resolution, and it sends every release recommendation to an independent checker. In simulation, a confirmed sanctions match triggered both the sanctions stop and the release approval rule, and the result was block, because block takes precedence.
Two design choices from that build apply to any agent that moves money. A refusal leaves the original hold in place. Approval and settlement are separate records, so an approved payment counts as complete only once its settlement reference is recorded. The build also taught us to give each decision one approval: our first submission for review failed because two human steps also carried an approval flag, which would have created two approval tasks for one decision.
The approval decision matrix sets out thresholds, reviewer roles, expiry, and exception cases for this kind of rule.
Evidence answers the question banks cannot answer today
The unnamed executive’s problem is a missing record. When an action goes through a checkpoint, the bank can keep who delegated authority to the agent, which agent and version acted, what it proposed, which policy rule applied, which outcome followed, who approved and when, and what the downstream system did. That record lets the bank answer a customer complaint or an auditor with facts.
Revocation belongs in the same record. When a customer withdraws the delegation, the next proposed action should be refused, and the refusal should be recorded. The kill-switch architecture guide covers the stop path and a drill to test it.
Where KLA fits, and where it does not
The KLA Control Plane governs agent actions that are sent through it. Agents that act through KLA agent action ingress work under an agent mandate with an accountable owner, allowed tools and destinations, threshold constraints on parameters such as amount, and an end date. The KLA Policy Engine returns allow, warn, require_approval, or block for each proposed action. When policy evaluation fails, the action is not executed. A require_approval outcome creates a Decision Request; Decision Desk refuses decisions from the requester, and the approval is bound to a hash of the action’s arguments, so a changed request is blocked. Revoking a mandate blocks open proposals and refuses the agent’s next action. Each step is recorded for Lineage Explorer, Audit Trail, and Evidence Room. This paragraph describes current source code.
KLA does not detect a third-party agent that logs in with a customer’s shared password. Bot detection, session risk, and terms-of-service enforcement stay with the bank’s fraud and digital channels. KLA governs the agents a bank or its partners choose to connect through a governed channel.
Frequently Asked Questions
Are US banks blocking AI agents from customer accounts?
Axios reported on 22 October 2026 that Morgan Stanley has begun blocking third-party agents, according to sources, and that JPMorgan, Bank of America, and Citi are restricting agents. Most banks have authorized or are moving toward read-only agent access.
Did unauthorized AI agents cause losses at US banks?
The Axios report describes no customer losses, no confirmed hack, and no regulator action. Morgan Stanley said it had not observed rogue AI agents accessing its platforms.
Why is it hard for a bank to detect an AI agent in a customer account?
The agent usually logs in with the customer’s own credentials, so its requests carry the customer’s identity. The bank cannot tell from the session alone whether the customer or software chose an action.
How can a bank let AI agents act without losing control of payments?
Give the agent its own identity and a defined delegation, send each proposed action through a policy checkpoint, require the customer or a named checker to approve money leaving the account above set limits, and record each decision and its outcome.
What does require_approval mean for an AI agent payment?
The checkpoint holds the exact payment and asks an authorised person to decide. The payment runs only after approval, and a change to the amount or payee after approval needs a new decision.
Key Takeaways
The Axios report shows banks meeting agents they cannot see and responding by blocking them. Blocking works while agents are rare. A bank that wants to admit useful agents needs a separate identity for each agent, a checkpoint on each action, a person in front of money leaving the account, and a record that answers who acted and who approved. Start with the approval decision matrix and the agent access review that keeps each delegation current.
Sources: Axios, "Unvetted AI agents are accessing U.S. bank accounts", 22 October 2026; Reuters, 22 October 2026, reporting the Axios story. KLA has no relationship with the banks named.