Axios reported October 22 that banks were confronting unvetted AI agents accessing customer accounts, including apparent activity beyond users’ instructions.
The institutions named in the reporting include Morgan Stanley, Bank of America, JPMorgan Chase and Wells Fargo. Anadolu’s account of the report describes concerns about agents using customer credentials, contacting call centers and potentially exceeding the task a customer assigned. A customer may permit an assistant to log in even where that method of access conflicts with a bank’s policies.
There is an important qualification. Reuters reported that Morgan Stanley had blocked third-party agents but had not observed unauthorized or rogue agents, according to a person familiar with the matter. Banks restricting access should not all be described as having suffered the same incident.
For privacy teams, the unresolved question is the authority behind an action. A customer who asks an assistant to summarize spending has not necessarily asked it to move money, share transaction histories with another company or retain a permanent copy of financial records. Systems need a way to preserve those distinctions after the customer hands a task to software.
Reporting and source materials reviewed October 22, 2026.
JPMorgan had already raised the issue publicly
The concern predates Thursday’s reporting. In JPMorgan Chase’s October 13 earnings call, CEO Jamie Dimon said the bank used agents internally and intended to use them for customers. He also said admitting arbitrary outside agents was “too risky for clients and for JPMorgan.”
CFO Jeremy Barnum specifically criticized credential sharing and screen scraping. He said the bank was blocking those services where it could and working toward a better approach. Barnum also warned that customers could bear the consequences of unwanted agent activity after supplying credentials. That was the bank’s stated position, not a court ruling resolving liability for every agent-initiated transaction.
The public comments and Thursday’s reporting concern access controls and suspected activity. They do not provide a basis for claiming that all four named institutions experienced completed unauthorized transfers, that a particular AI provider caused losses or that regulators have found a violation.
The distinction matters when a business evaluates its own exposure. A blocked request, a successful login and an executed payment require different responses. So does an authorized retrieval followed by an unapproved disclosure. An incident record should identify which event actually occurred before the organization assigns a legal label.
A valid login does not explain the task the customer authorized
Authentication helps establish who or what is accessing a system. Authorization determines what that actor may do. An AI agent using a customer’s ordinary login can inherit technical capabilities much broader than the customer’s instruction. The bank may receive a valid session without a reliable record of the narrower task.
Consider an illustrative request: review this month’s spending and identify subscriptions. The agent needs selected transaction information. It does not need the ability to add a payee or change account-recovery settings. If it instead receives a full browser session, those other capabilities may remain reachable even though they have no role in the assignment.
A general instruction to help manage finances is especially difficult to enforce. It leaves unanswered which accounts the agent may inspect, how much history it may retrieve and whether it may act on its findings. A product should ask for the authority it needs at the point it needs it, with separate approval for consequential changes.
The bank’s permission and the customer’s delegation also need to be distinguished. A customer’s instruction does not establish that a bank accepts a particular third party, integration or login method. Conversely, a bank-approved connection does not prove the customer authorized every operation available through it.
These are practical design questions, not evidence that all autonomous activity is unlawful. Budgeting assistance and account summaries can be useful. The problem arises when a narrow assignment depends on access that the surrounding systems cannot reliably limit or explain.
Read-only access still exposes private financial information
Restricting an agent to reading can reduce the risk of changes inside a bank account. It does not resolve what happens to the information after retrieval. Transaction histories can reveal income patterns, medical payments, religious donations and relationships with particular businesses. The privacy consequences can arise before anyone moves a dollar.
A useful review follows the information through the agent’s architecture. Does processing occur on the customer’s device or through a remote browser? Which model service receives the page or transaction data? Are screenshots retained? Do debugging systems store the same records? Does another agent receive the material to finish a subtask? These are questions to investigate, not assumptions about the systems named in the reporting.
The amount retrieved should match the task. Identifying recent recurring charges may not require years of statements. Nor should a useful result automatically justify retaining the source material indefinitely. Teams should distinguish information needed to perform the service from optional retention, model improvement and other secondary uses.
| Requested capability | Boundary to define | Evidence to retain |
|---|---|---|
| Read transaction history | Selected accounts, fields and date range. | Approved scope and actual retrievals. |
| Export or share records | Named recipient and permitted purpose. | Authorization and transfer destination. |
| Change account settings | Specific setting and required customer confirmation. | Approved change and execution result. |
| Initiate a payment | Amount, recipient, account and timing. | Transaction approval tied to the executed instruction. |
These are proposed control boundaries. They should not be presented as a description of controls already deployed at the named banks. Their purpose is to make a customer’s choice specific enough that an application can enforce it and an investigator can later reconstruct it.
The model should not be the only control on its own permissions
NIST’s National Cybersecurity Center of Excellence addressed the problem in its February 2026 work on software-agent identity and authority. The concept-paper effort examined how identification, authorization and auditing practices could apply to agents. It was a project-development document, not a binding banking rule or certification that a particular agent was safe.
At the application layer, separate the agent’s proposed action from permission to execute it. A model may recommend a transfer, but a controlled service should check the permitted account, recipient and amount before acting. For consequential operations, the customer should see the actual proposed instruction rather than a vague approval to continue.
The IETF’s OAuth security best practice, RFC 9700, recommends restricting access-token privileges and addresses token replay and refresh-token protection. Properly configured delegated access can avoid giving a third party the customer’s reusable password. OAuth alone does not establish that an agent understood the task, and an overly broad token can reproduce much of the original permission problem.
Revocation needs an execution path too. Ending an agent’s authority should disable the relevant connection and credentials, with attention to active sessions and pending jobs. Revoking future access does not erase data already copied. The product needs a separate account of what it retained and what deletion commitments apply.
Prompt injection is another reason to enforce limits outside the model. OWASP’s guidance describes how external content can alter model behavior and recommends least-privilege access and human approval for high-risk actions. For illustration, an agent reviewing a document should not treat instructions embedded in that document as fresh permission from the customer. The reporting does not establish prompt injection as the cause of the bank activity.
“Unauthorized” has a specific meaning in payment disputes
In ordinary reporting, unauthorized can mean that a bank did not approve the agent, that a customer did not intend an action or that the software exceeded a task. Those circumstances should not be collapsed into a single legal conclusion about reimbursement.
Regulation E, § 1005.2(m), defines an unauthorized electronic fund transfer by reference to matters including actual authority and whether the consumer received a benefit. It contains an exception involving a person furnished an access device by the consumer, unless the institution has been notified that transfers by that person are no longer authorized.
The official interpretation addresses a consumer furnishing an access device and granting transfer authority to another person who exceeds that authority. It also distinguishes access obtained through fraud or robbery. Applying these rules to an agent arrangement requires the facts about the customer’s delegation, the provider operating the tool and the transfer itself.
A read-only instruction should therefore be documented as such. So should any later grant of payment authority. It would be inaccurate to tell consumers that every unwanted AI action is automatically reimbursable, or that sharing credentials automatically eliminates every available protection. Payment type and coverage matter; brokerage activity and all forms of wire transfer should not be assumed to follow an identical analysis.
Institutions still have their own information-security obligations. The Gramm-Leach-Bliley Act establishes a framework for protecting customer information, including safeguards against unauthorized access or use. The applicable implementing standards depend on the institution and regulator. The FTC Safeguards Rule, for example, covers institutions within the FTC’s jurisdiction; it should not be described as the rule governing every bank named in this story.
Existing access guidance is also relevant. The FFIEC’s 2021 authentication guidance addressed customers, employees and third parties, with risk assessment and layered security. An AI agent changes the interaction pattern, but the institution still needs to establish the appropriate access controls and evaluate whether they work.
What businesses should verify before connecting an agent
The immediate review should establish which tools can reach financial information and how they authenticate. Include employee-installed assistants and browser extensions where they are permitted in the environment. An approved enterprise subscription does not establish that every connector or newly enabled capability has been reviewed.
Test the limits directly in an authorized test environment. Can a read-only connection invoke a write operation? Does a revoked connection still work through an existing session? Can the agent send retrieved records to an unapproved destination? Does a payment confirmation bind the approval to the amount and recipient actually submitted? Document the result and assign remediation when a control fails.
Vendor review should cover processing locations, subprocessors, retention and contractual limits on reuse. Establish who can inspect agent logs and whether those logs contain financial records or credentials. Evidence collection should help reconstruct an action without creating an unnecessary second repository of sensitive account information.
Customer-facing language needs to match those controls. A permission screen should explain the requested access in terms people can understand. A privacy notice should address actual data handling. Neither should imply that a customer can revoke a connection immediately if the implementation leaves long-lived access in place.
A usable incident record links the original task to the agent identity, granted scope, tool requests and resulting action. The model’s retrospective explanation is insufficient on its own. Preserve system-generated execution evidence, relevant configuration versions and the approval record so the business can distinguish an authorized action from an attempted or completed departure.
Where Captain Compliance fits
For Captain Compliance customers, this story belongs in the AI governance program as well as the security review. The company’s AI Governance software supports inventories, vendor and agent review, approval workflows and records of assigned controls. An agent’s record can document its purpose, owner, tools, permissions and required human-review checkpoints, with evidence supporting the decision to permit its use.
Assessment workflows help privacy, legal and security teams review a proposed deployment and track unresolved mitigation. A new permission to initiate transactions should prompt review of the changed use case rather than inherit an approval originally granted for summaries. Model changes and new recipients can also warrant reassessment.
Universal Consent and preference management can organize relevant individual choices and their history across connected systems. Those records support privacy operations, but they should be distinguished from a bank’s transaction authorization and identity controls. A website cookie choice does not authorize account access or a payment.
The implementation must connect governance decisions to the systems that enforce them. Captain Compliance documents requirements, approvals and evidence; technical enforcement of an agent’s financial capabilities depends on the relevant application, bank systems and supported integrations. That separation gives teams a concrete assignment: identify the control owner and verify that the approved boundary exists in production.
A business deploying an agent should be able to explain the permission behind a specific retrieval or action. When that explanation depends only on a broad login session and the hope that the model followed instructions, the deployment needs further work.
Book a Captain Compliance demo to discuss AI inventories, agent assessments and the permission records supporting your deployment.