Update — October 22, 2026, 2:27 PM Pacific: Added Reuters’ anonymously sourced account distinguishing Morgan Stanley’s access restrictions from observed rogue-agent incidents. The article continues to distinguish reporting from independently verified incident evidence.
Update — October 22, 2026, 1:42 PM Pacific: Added Schwab’s account of blocked agent logins and Anthropic’s description of limits on its approved Schwab connection. The evidence confirms a reported access distinction, but does not establish unequal treatment of applicants offering equivalent safeguards.
Update — October 22, 2026, 1:38 PM Pacific: Added documented comparisons involving Smart Cash, Fargo and external AI connections through Plaid, including the developer trial route. These establish differences in access arrangements, but do not prove unfair treatment of an equally safe independent agent or regulatory capture.
Update — October 22, 2026, 1:30 PM Pacific: Added federal model-risk guidance context following new event coverage, plus Wells Fargo’s forthcoming AI-agent terms. The April guidance and November effective date are distinguished from today’s reporting; incident-level claims remain unverified.
Banks have legitimate reasons to control software that can act on a customer’s money. Those controls also create an opportunity to decide which AI companies get access to a valuable market. Both deserve scrutiny. Our finding: the access restrictions are documented, but the public evidence does not establish a coordinated regulatory-capture effort by frontier AI companies.
On October 22, Axios reported that U.S. banks had detected unapproved agents in customer accounts, with some apparently attempting actions beyond users’ instructions. Those incident claims rely on unnamed sources. Kingy.ai has not independently verified them. Original Axios report.
Additional Reuters reporting on October 22 adds an important qualification. Citing a person familiar with the matter, Reuters reported that Morgan Stanley had blocked third-party agents but had not seen unauthorized or rogue-agent incidents. Another industry source described cases in which customers shared credentials and banks flagged and blocked transactions. These remain anonymously sourced accounts, not incident logs or an on-record Morgan Stanley statement. They reinforce the need to separate restrictions from evidence of misconduct: inclusion in a list of banks responding to agent risks does not establish that each experienced a rogue-agent incident. Credential sharing also does not prove that every subsequent action matched the customer’s instructions. The report adds context but does not resolve the overall incident mix or establish preferential treatment for approved AI providers.
There is firmer evidence for the restrictions. Chase’s public terms explicitly address AI agents, require them to identify themselves and label their traffic, and reserve the bank’s ability to restrict access. The terms also assign responsibility to users for agents that misinterpret instructions or exceed delegated authority. That is the bank’s stated contractual position; it does not settle every question about legal responsibility or consumer protection. Chase terms of use.
Wells Fargo’s published upcoming Online Access Agreement, effective November 24, 2026, provides another concrete example. Section 15 says that, subject to applicable law or regulation, instructions from an agent given account access or authority may be treated as the customer’s own. It assigns customers responsibility for agent errors and overreach, requires them to retain evidence of revocation and notify the bank, and reserves the bank’s ability to require registration or restrict agent access. These are forthcoming contractual provisions, not evidence that an incident occurred. Their legal qualifications also matter: the text does not establish that using an agent erases every statutory consumer protection. Nor does describing how agent access would be treated promise that Wells Fargo will permit any particular agent.
An agent can be authorized by its user and prohibited by the bank. It can also have permission to perform one task and exceed that permission. A criminal might operate an agent using stolen access. These situations involve different failures, different victims and different remedies. A headline that treats them all as autonomous AI breaking into accounts hides the information readers need.
David Sacks challenged the framing directly in an October 22 response to Mills. He argued that most of the activity described appeared to involve customers delegating access to agents such as Muse, Instinct and Grokbot. In his view, conflating that activity with cyberattacks needlessly alarms the public. He urged banks to support user-directed agents, proposed read-only access as an interim step, and distinguished it from the greater risks of credential-based write access. Sacks’s original post.
The distinction is important: a breach of a bank’s access terms does not, by itself, establish a cyberattack. But his assessment of what accounts for most incidents remains an interpretation. The public evidence reviewed here does not establish the proportions. Nor does a customer’s initial permission rule out subsequent overreach, misuse or compromise. Each event needs to be assessed against the permission actually granted and the action actually taken. A product name alone cannot establish that every action by that product was authorized.
Sacks also cited American Express as an authorized Muse connection through which customers can grant, limit and revoke access. We have not independently confirmed that specific integration or its permission scope. Meta’s own Muse announcement describes user-selectable access and the ability to disconnect services, but that general description does not verify the Amex example. Meta’s Muse announcement.
Read-only access is a useful starting point when the task is to summarize spending or compare accounts. It still exposes sensitive financial information, so access limits, retention rules and revocation matter. Permission to move money calls for additional checks tied to recipients, amounts and timing. These permissions should be enforced by the connected system; telling an agent to behave as read-only is insufficient if its credentials still allow transfers.
Imagine a customer who asks an assistant to summarize monthly spending. That instruction authorizes analysis. It does not inherently authorize moving savings, opening a new account or contacting a bank while pretending to be the customer. Yet an assistant controlling a fully authenticated browser session might encounter buttons for all those actions. The system needs to enforce the narrower permission even when the interface exposes broader capabilities. This is an illustrative scenario, not a reconstruction of an incident in the Axios story.
Authentication establishes who or what has presented acceptable credentials. Authorization determines what that party may do. Neither necessarily proves that a particular action matches the customer’s intention at that moment. The practical problem is how to preserve that intention as a request moves from a person, through an agent and its tools, into a financial institution’s systems.
NIST has been examining this issue independently of today’s news. Its February 2026 concept paper sought input on agent identity, authorization, auditing and related controls. A September update reported feedback from more than 600 commenters and identified software development as the first implementation use case. This is evidence of an active standards project, not a completed banking certification regime. NIST’s February announcement, September project update.
An October 22 Axios event recap reports FDIC chair Travis Hill discussing agentic AI’s exclusion from model-risk guidance. The underlying April 17 interagency guidance, footnote 3, confirms that generative and agentic AI are outside its scope. The same footnote says banks’ risk-management and governance practices should guide appropriate controls for tools outside that scope. This is an existing guidance boundary, not a new exemption announced today or proof that agents operate free of all oversight. Our analysis is that the next policy proposals need scrutiny at the application and access level as well as the model level; the exclusion alone establishes neither regulatory capture nor safe deployment.
JPMorganChase supplies the clearest documented comparison between an in-house service and restricted outside access. On October 13, CFO Jeremy Barnum said Smart Cash had entered a targeted live pilot. In the same earnings call, he said the bank was blocking some outside money-movement services using shared credentials. He also argued that deposit stability should not depend on making money difficult to move and described using both proprietary and open models to limit vendor dependence. JPMorganChase earnings transcript, printed pages 2, 9–10 and 12.
The bank’s 2025 shareholder letter describes Smart Cash as simplifying movement between checking and higher-yielding brokerage products, with AI-based cash-flow prediction presented as an eventual capability. The documents establish that the bank is developing its own route while restricting some external routes. They do not establish that the pilot is a general-purpose autonomous agent, that every advertised capability is deployed, or that a technically equivalent independent service was rejected. We have not tested Smart Cash.
Wells Fargo offers a second example of integrated access. Its Fargo product page says the bank’s virtual assistant helps customers transfer between accounts, send money with Zelle and change account or card settings. Its October 2022 announcement identifies Google Cloud’s Dialogflow as the platform behind the assistant. This documents a bank-integrated product built with a technology partner. It does not establish that Google’s independent consumer agents receive the same access. Nor does assistance within the bank’s app establish unsupervised authority to transact. Read alongside the forthcoming outside-agent terms above, the comparison shows the bank choosing the access arrangements; it does not reveal matched security tests or a rejected independent applicant.
Schwab provides a more direct account of access being denied. In the published transcript of its October 15 Fall Business Update, CEO Rick Wurster said the firm was already blocking agents trying to log in on clients’ behalf and that he received daily reports of those blocks. He gave control over authentication and the customer experience as reasons. He also described supported LLM connections, restrictions on moving money because of risk to clients and the firm, and clients trading through LLMs and APIs. Those are different permissions: trading through a supported interface does not establish permission to transfer funds elsewhere. His account establishes that Schwab says blocks are happening; it does not identify a rejected developer, disclose session logs or demonstrate what a particular customer authorized.
Schwab’s approved Anthropic relationship also has limits. In Anthropic’s “Inside Claude for Financial Advisors” webinar, executive Peter Nolan says the Schwab connection starts with read-only access. He says Claude inherits each user’s existing permissions, cannot see accounts that user cannot access, and uses connectors selected by the firm’s administrator. These are the provider’s descriptions of its controls, not our independent security tests. They supply concrete evidence that this approved partner does not receive unrestricted account access.
The comparison narrows our hypothesis. Schwab’s stated distinction is between unsupported logins and controlled connections with limited permissions. That is a plausible security distinction. We have not found a public denial notice or documented application showing that an independent agent offered equivalent authentication, permissions and safeguards and was rejected while a partner was accepted. Nor have we established that partners and independent applicants face identical fees, reviews or approval times. The read-only partner connection weakens the claim that partners simply bypass safety requirements; the undisclosed terms of admission leave the competition question open. Proving regulatory capture would additionally require evidence about how public rules or oversight favor incumbents.
Our interpretation is that banks have overlapping incentives. They need to prevent fraud and mistakes. They also benefit when customers keep their deposits and continue using their services. An assistant that makes comparison and switching easier could increase competitive pressure. That possibility does not make a security objection dishonest. It does mean a bank should explain why its restrictions are proportionate and how a competing provider can qualify for access.
Controlled third-party access already has a commercial structure. JPMorganChase and Plaid announced a renewed consumer-permissioned data agreement in September 2025 that explicitly included a pricing structure. The announcement supports the existence of a negotiated route to financial data. It does not establish that arbitrary AI agents may initiate transfers through that route. JPMorganChase–Plaid announcement.
External AI products also have documented routes to financial data. In a Plaid interview, Perplexity product executive Jeff Grimes describes Personal CFO’s account connection as read-only. OpenAI’s Finances documentation likewise describes account connections through Plaid while explicitly excluding money movement, bill payments, trades and account-setting changes. These are provider descriptions, not our transaction tests. They demonstrate supported external integrations, but not unrestricted access, exclusive bank deals or exemptions from safety requirements. A data connection should not be compared with a blocked transfer attempt as though they carry the same permissions.
There is concrete counterevidence to the claim that only large AI companies can get through the door. Plaid’s current Trial documentation offers eligible developers in the United States and Canada up to ten production Items, each an end-user connection to an institution. It lists immediate OAuth access to institutions including Chase, Bank of America and Wells Fargo, without business registration or a security questionnaire. Applicants still face identity verification, contractual terms and security attestations. The trial excludes Transfer and Payment Initiation, and developers need a paid production plan to expand beyond its limits. This is a documented entry route, not proof that every applicant or account connects successfully.
The requirements change beyond that trial. Plaid’s OAuth guide says non-Trial customers must complete a security questionnaire before gaining Chase production access. That is a specific approval requirement we can inspect. We found no evidence in these documents that frontier-lab partners are exempt from it, or that an independent applicant meeting equivalent requirements was denied because of its ownership. The useful next comparison would hold the requested permissions, security controls and operating scale constant, then examine approval time, price, restrictions and reasons for rejection.
Our assessment is narrower than a finding of regulatory capture: bank-integrated services and approved external connections have access advantages over unsupported access methods. The examples make bank control over distribution concrete. They also show why a blanket “banks allow their own AI and prohibit everyone else’s” claim would overstate the evidence. Whether that control becomes exclusionary depends on who can qualify, on what terms, and whether public rules entrench unjustified differences.
For an independent developer, the route to approval matters. An open technical specification may be straightforward to implement, while obtaining acceptance from a bank or payment network may require separate agreements, assessments and ongoing operating costs. The competitive question is whether those conditions track measurable risk or mainly reward companies with established relationships and large compliance budgets.
Regulatory capture describes public oversight being diverted toward the interests of the industry it is supposed to oversee. A bank restricting software on its own website is not, by itself, proof of that. Private control over access can nevertheless become an obstacle to competition. If lawmakers later adopt the same private approval arrangements as mandatory conditions for market entry, the distinction becomes much more important.
Sacks’s objection sharpens the competition question. If legitimate customer delegation is routinely described as hostile activity, that framing could make broad exclusions easier to defend and tilt access toward approved incumbents. The same scrutiny should apply to a bank protecting its own services and an AI platform promoting privileged connections. Supporting user-directed agents should include a fair route for independent providers to qualify. It should also preserve the bank’s ability to stop demonstrable abuse. This is our analysis of the potential consequences, not evidence that the reporting was designed to secure such an outcome.
There is a plausible route by which frontier model makers could benefit. A government could respond to incidents by requiring expensive evaluations for broad categories of software. Large labs could absorb those costs, help define the tests and sell the approved services. Smaller providers might face delays, duplicate assessments or requirements poorly suited to their products. Those are risks in how rules could be designed; this reporting does not establish that such a coordinated strategy caused the banking story.
A concrete proposal deserves attention. In July, Demis Hassabis proposed a federally overseen AI standards body with substantial industry funding, initially voluntary model review and eventual mandatory assessments for frontier models entering the U.S. market. His proposal also includes independent experts, open-source representation and an exemption for non-frontier models. Those safeguards matter when assessing it fairly. Hassabis’s original proposal.
Our concern would be who controls appointments, assessment costs, appeals and changes to the qualifying thresholds. An industry-funded institution can acquire expertise that government lacks. It can also become dependent on its largest funders. Independent representation needs actual decision-making power, and applicants need a credible way to challenge inconsistent treatment. The proposal’s merits depend on those arrangements, not merely on the presence of industry money.
Model approval and permission to transact also need separate treatment. A capable model with limited access may create less financial exposure than a weaker model connected to unrestricted tools. Passing a general model evaluation cannot establish that every application built with it handles consent correctly. Conversely, a small developer should be able to demonstrate safe operation of a tightly limited service without reproducing a frontier lab’s entire compliance organization. This is our policy judgment about matching oversight to the deployed system.
Existing payment initiatives show that the industry is already working on narrower controls. Google’s Agent Payments Protocol, or AP2, uses signed mandates to record instructions and purchase authorization. Its launch documentation distinguishes purchases approved while a person is present from tasks authorized in advance with conditions such as price and timing. Google describes the protocol as open and payment-agnostic. These are design features and vendor claims, not proof that every implementation is secure. Google’s AP2 announcement.
Visa’s Trusted Agent Protocol addresses how merchants recognize agents and verify signed information about their interactions. Its specification also describes agent providers as certified platforms onboarded and approved by payment schemes. That makes the approval process worth examining alongside the cryptography. Visa’s protocol specification.
Neither initiative, on its own, grants an agent unrestricted access to a consumer bank account. Merchant checkout, financial-data retrieval and bank transfers are distinct activities. Progress in one does not establish permission or safety in the others.
Open documentation can help independent developers build compatible products. Fair access additionally requires published eligibility rules, reasonable fees, predictable decisions and the ability to change providers. A technically open system can still become commercially difficult to enter. Equally, certification can make entry easier if it replaces dozens of inconsistent private negotiations with one credible, affordable assessment. The relevant evidence is the experience of applicants and the conditions they face.
Cryptographic signatures have limits too. Researchers Avital Aviv, Parth A. Gandh, Ron Bitton and Asaf Shabtai analyzed AP2 v0.2 in an August 2026 preprint. Their work identifies risks in inputs that shape a transaction before authorization and argues that valid signatures alone cannot establish fidelity to user intent. The demonstrations used a testbed because a complete public deployment was unavailable. They do not document losses in the U.S. bank accounts discussed in today’s report. Research abstract and paper.
For a reader, the distinction is straightforward: preserving a signed instruction accurately does not prove that the instruction was produced from an honest page, a trustworthy tool response or a correctly understood request. A safe design needs checks on the information used to obtain approval as well as checks when a transaction executes.
There is also an established competition concern around the infrastructure supporting large AI companies. In January 2025, FTC staff identified potential problems involving access to key resources, switching costs and sensitive information in major cloud–AI partnerships. That report supplies relevant background about concentration. It is not a finding that banks and model makers coordinated this episode, and its underlying information predates it. FTC staff-report announcement.
Consumer data rights add another layer. The CFPB’s implementation page records an October 2025 court order staying the compliance dates of its Personal Financial Data Rights Rule. Readers should therefore avoid relying on the original implementation timetable as evidence that every bank must already provide a particular connection. Data access and permission to move money also remain separate questions. CFPB implementation resource.
Kingy.ai’s position is that financial-agent oversight should protect a customer’s ability to delegate safely and choose among competing providers. That suggests a practical set of requirements:
- Give an agent a separate, revocable identity with permissions limited to its task.
- Keep information retrieval separate from actions that change balances, recipients or account settings.
- Offer a genuinely read-only route where it meets the customer’s needs, with clear consent and revocation controls.
- Enforce amount, recipient and time limits in the transaction system, outside the model’s own reasoning.
- Make significant approvals understandable and specific enough that customers can see what will happen.
- Preserve an audit trail connecting the request, delegated authority, tool calls and executed action.
- Publish qualification criteria and provide an independent appeal route for rejected providers.
- Apply comparable controls to a bank’s own agents and outside agents performing comparable actions.
These are recommendations, not a claim that every bank or protocol already implements them. Some requirements will need to vary by activity and risk. Reading a balance, paying a known bill and changing a payment destination should not automatically receive the same permissions or scrutiny.
The strongest evidence of capture would be a rule that privileges named vendors without a defensible technical basis, an approval board dominated by direct competitors, unexplained differences in enforcement, or fees and requirements that exclude capable entrants without improving safety. Published incident evidence, independent testing and equal treatment would point in a healthier direction. Mere participation by a large lab in a standards process establishes neither outcome.
The next reporting step is to obtain enough detail to distinguish the underlying events: what each customer authorized, what the agent attempted, what the bank blocked, whether any transaction completed, and which part of the system failed. Separately, banks and standards bodies should disclose how an independent provider can earn access and contest a denial. Those facts would let customers judge both the security response and its effect on their choices.
Reporting and disclosure: Prepared with AI assistance and source review. This is analysis, not a hands-on security investigation. This analysis uses public documents, original research and attributed reporting reviewed on October 22, 2026. We directly inspected Mills’s post, Sacks’s response and the accessible Axios introduction; the browser requested newsletter registration for the remainder of the Axios article, while web search supplied indexed reporting. We did not access private bank logs, interview incident participants or test agents against live accounts. Sacks’s assessment of the incident mix and his specific Amex–Muse example remain attributed claims. The interpretation of competitive incentives and the policy recommendations are Kingy.ai analysis.
The Kingy Brief
Get The Kingy Brief.
AI changes, original tests and one practical thing to try. Fridays at 09:00 Vancouver time.
Free · Double opt-in · Unsubscribe anytime
Sign up for The Kingy Brief on Beehiiv.
Signup help and newsletter schedule
Signup form provided by Beehiiv. After submitting, check your inbox for "Confirm your subscription to The Kingy Brief" and open its confirmation link. Check Spam or Promotions if you cannot find it.
Fridays at 09:00 Vancouver time: source-checked AI changes, original tests and one practical thing to try. We skip a week when there is not enough verified material. Free. Unsubscribe anytime.