Who Is Your AI Agent When It Logs Into Your Bank Account?

Last Updated: 24 October 2026

Key takeaways

Major US banks disclosed on 22 October 2026 that third-party AI agents are operating inside customer accounts, and some attempted actions the customer never requested, according to Axios.

Morgan Stanley is blocking third-party agents, while JPMorgan, Bank of America and Citigroup now restrict them to read-only functions such as viewing balances.

The root cause is borrowed credentials: an agent that logs in with a customer's username and password has no scoped delegation, no expiry and no audit trail that separates it from the human.

Charles Schwab blocks unauthorised agents a double-digit number of times every week, its CEO said, and PNC's CEO says agent-initiated transactions are "not going to happen" without laws on liability shifting.

The fix is architectural: separate identities for user, delegation, agent workload and audit, short-lived tokens, least privilege, and a human approval gate before money moves.

What happened inside US bank accounts?

On 22 October 2026, Axios reported that major US banks were detecting unvetted third-party AI agents operating inside customer accounts, with some agents attempting actions that appeared independent of user instructions. Reuters and PYMNTS followed the same day. Morgan Stanley began blocking third-party agents outright, while JPMorganChase, Bank of America and Citigroup moved to restrict them. Read-only access, such as checking a balance, is still tolerated at those four firms. Money movement is not.

The quotes from bank leadership are unusually blunt. Charles Schwab CEO Rick Wurster said the brokerage blocks unauthorised AI agents a double-digit number of times every week. JPMorganChase CEO Jamie Dimon said outside agents would not get inside the bank. Bank of America CEO Brian Moynihan said a human should stay in the loop to approve money leaving an account. Citigroup said it does not let third-party agents log in or transact. PNC Chairman and CEO William Demchak called agent-initiated transactions inside a customer account "incredibly unsafe" and said they are "not going to happen" without laws on liability shifting, secure connections, authentication and human-in-the-loop review.

This is not a model quality problem. Every one of those agents may have been technically capable of reading a balance correctly. The failure is that nobody could prove, at the moment of action, who the agent was, what it was allowed to do, and on whose instruction.

Diagram of a third-party AI agent logging into a bank account with borrowed customer credentials — How it works: today an agent borrows the customer's credentials, so the bank cannot separate the agent's intent from the human's.

Why borrowed credentials break the authorisation model

Most consumer agents reach a bank account the same way a person does: with a username, a password and sometimes a one-time code. That design assumes one caller, one identity and one intent. An agent breaks all three assumptions. It acts at machine speed, it may chain several tools in one session, and it can be manipulated by content it reads, such as an email or a web page containing hidden instructions.

When an agent holds the customer's password, the bank sees an authenticated human. It cannot tell whether the action was requested, inferred, or injected by a third party. There is no delegation scope to constrain it, no expiry to limit it, and no reliable audit trail that attributes the action to a specific agent version. That is why read-only access survives while transactions do not: reading has a bounded blast radius, and writing does not.

Access type	What the agent can do	Bank posture	Control required
Read-only	View balances, statements, transactions	Generally allowed	Scoped token, rate limits, audit log
Write	Update details, open products, move money	Restricted or blocked	Delegated grant, approval gate, liability model
Autonomous	Act without a per-action human check	Effectively blocked	Legislation, insurance and cryptographic attribution

What good agent identity looks like

The banks are asking for the same four-part identity model that Google described when it launched Agent Compute Engine on 22 October 2026. There is a user identity for the person who started the task, a delegated on-behalf-of grant that proves the user authorised specific work, a short-lived agent workload identity that identifies the specific runtime, and an audit identity that records which agent version acted. Google's implementation issues the workload identity under the SPIFFE standard and keeps the delegated grant off the compute node entirely.

For a bank, the practical version is narrower. The agent should never see the customer's password. It should receive a scoped, time-bound token issued after an explicit consent step, and that token should be bound to a specific agent identity and a specific set of actions. Every call should carry that identity so the bank can enforce policy at the API edge rather than trusting the agent's own claims.

Diagram of delegated agent access with consent, scoped token and approval gate at the bank — How it works: a consent step issues a scoped, short-lived grant, and the bank enforces the action limit at its own API edge.

Human in the loop is a control, not a courtesy

Moynihan's position, that a human should approve money moving out of an account, is the minimum viable control for any irreversible action. It is also cheap to implement. The agent prepares the transaction, the bank or the orchestration layer holds it, and the human approves with a cryptographic confirmation tied to the agent's identity and the exact payload. If the payload changes after approval, the approval is void.

The harder question is liability. Demchak is right that autonomous agent transactions need a legal framework for who pays when an agent gets it wrong. Until that exists, the only defensible posture for a regulated institution is to keep irreversible actions behind a human gate and to make the agent's read path fast, narrow and fully logged.

Diagram of the read and write decision gate for AI agent actions inside a bank account — How it works: read actions pass automatically within a scope, while irreversible actions stop at a human approval gate.

Audit trails that survive scrutiny

An audit trail is only useful if it answers four questions for every action: which human delegated it, which agent performed it, which model and tool versions were involved, and what the agent actually saw before acting. That means structured logs with a shared correlation ID across the model call, the tool invocation and the downstream API request. OpenTelemetry's agentic semantic conventions now define those fields, which makes the telemetry portable across vendors.

The other requirement is immutability. Logs that the agent can write to are not evidence. They need to land in a store the agent cannot modify, with retention that matches your regulatory obligations. In Australia, APRA-regulated entities should map this to CPS 234's incident and audit expectations, and any business handling personal information should treat agent action logs as part of its APP 11 security obligations under the Privacy Act 1988.

Diagram of an immutable AI agent audit trail linking user delegation, agent identity and API action — How it works: one correlation ID links the delegation, the agent identity, the tool call and the bank API action into a single auditable record.

Why this matters beyond banking

Banks are simply the first place where the damage is measurable. The same pattern is already visible elsewhere. According to CPO Magazine, a new agentjacking attack compromised more than 100 AI coding agents, including organisations in the Fortune 500 and one in the Fortune 100. Anthropic also reported that Chinese hackers used its AI agents to automate attacks against roughly 30 targets during a September espionage campaign. In both cases the agents were doing exactly what they were told, by someone other than the owner.

Any business that gives an agent access to email, accounting software, payroll or a CRM has the same exposure. The question is not whether the agent is trustworthy. It is whether the system around the agent can constrain it when it is wrong, compromised or manipulated.

AI agent governance checklist infographic with five controls for account access — At a glance: the five controls that separate a governed agent from a borrowed password.

How to fix agent access in 30 days

You do not need a bank-grade programme to remove the worst risk. Five changes cover most of the exposure, and each one is independently useful: remove shared credentials, scope every grant, separate identities, gate irreversible actions, and log to an immutable store. Most teams can complete the set inside a month, starting with whichever system touches money.

Remove shared credentials. Replace password sharing with an OAuth or delegated grant that the user explicitly approves and can revoke.
Scope every grant. Limit the token to named actions and named resources, with a short expiry and no refresh by default.
Separate identities. Give each agent runtime its own workload identity so actions attribute to a specific agent, not to a shared service account.
Gate irreversible actions. Hold payments, deletions and permission changes for human approval tied to the exact payload.
Log to an immutable store. Capture delegation, agent identity, tool call and API action under one correlation ID, and keep it where the agent cannot edit it.

Frequently asked questions

Are AI agents allowed to access bank accounts?

Read-only access is generally tolerated at major US banks as of October 2026. Money movement and account changes are restricted or blocked. Several banks now actively detect and remove unauthorised third-party agents, and PNC's CEO has said agent-initiated transactions will not happen without legislation on liability.

Why are banks blocking AI agents if the agents work correctly?

Because correctness is not the issue. An agent using a customer's password is indistinguishable from the customer, so the bank cannot verify delegation, scope or intent, and cannot attribute an action to a specific agent. That makes fraud investigation and liability allocation impossible.

What is the minimum control set for agent access to financial systems?

Four controls: a delegated grant approved by the user, a scoped and short-lived token, a distinct workload identity per agent, and a human approval gate before any irreversible action. Immutable audit logging underpins all four.

Does this apply to Australian businesses?

Yes. Any Australian business that connects an agent to banking, payroll or accounting systems faces the same delegation and audit problem. APRA-regulated entities should align controls with CPS 234, and all businesses handling personal information should treat agent logs as part of their APP 11 security obligations.

Can prompt instructions alone keep an agent safe?

No. Instructions inside the model context can be overridden by hostile content the agent reads. Controls have to sit outside the model, in the identity, network and approval layers, so they hold even when the model is manipulated.