Rogue AI Agents: Banks vs. ARTEX Storm-0940 Attack

Two incidents this week put offensive AI on both sides of the threat equation: unauthorized agents inside US bank accounts, and a China-linked group using an AI penetration-testing tool to compromise over 2,250 Microsoft 365 tenants through ConnectWise.

Published: 2026-10-26  |  Last reviewed: 2026-10-26  |  UnpanicTech

Two stories broke this week that together show exactly where AI sits right now in the attacker playbook — and neither fits the science-fiction version of the threat. There are no sentient machines. What there are is a set of serious, practical problems that defenders need to understand without embellishment.

On October 22, Axios reported that major US banks — including JPMorgan, Bank of America, Wells Fargo, Citi, and Morgan Stanley — are detecting third-party AI agents operating inside customer accounts, with some agents contacting call centers and appearing to act independently of user instructions [1]. A day later, Microsoft formally attributed the ConnectWise Cloud Backup attack to Storm-0940, a China-aligned group that used an open-source AI penetration-testing framework called ARTEX to attempt sign-ins to more than 2,250 Microsoft 365 tenants at 2,900 attempts per minute [2].

Both situations reflect how AI is compressing timelines and complicating identification — not because the technology is autonomous in any meaningful sense, but because it is fast, scalable, and operating in gaps that existing controls were not designed for.

What Is Actually Happening Inside US Bank Accounts?

The framing of "rogue AI" deserves some precision. These are not agents that have independently decided to infiltrate banking systems. According to Axios, the typical scenario involves a customer sharing their banking credentials with a third-party AI assistant or financial app, and that agent then operating with those credentials in ways that violate the bank's own terms of service [1]. Banks require humans to log into their own accounts. An AI agent using those credentials — even with a user's permission — runs afoul of that rule.

What makes this genuinely concerning, beyond the policy violation, is the identification problem. One bank executive told Axios the institution struggles to differentiate between agents and whether an agent has been authorized by a user or has gained access through other means [1]. When normal human behavior and automated agent behavior look identical at the API level, existing fraud detection breaks down. Agents also appear to have, in some cases, contacted bank call centers directly — a whole new category of problem for identity verification systems that assume they are speaking to humans.

JPMorgan CFO Jeremy Barnum was notably unsympathetic at the bank's October earnings call: customers who share login credentials with agents that take unwanted actions should understand "that's going to be on them" [1]. That is a liability signal worth watching — it suggests banks are positioning agent-related losses as user error rather than institutional failure, at least for now.

How Major Banks Are Responding

Source: Axios, October 22, 2026 [1]

The Security Magazine assessment cuts through some of the drama: this is largely a story about consumers handing banking credentials to third-party software, and vendors shipping agents that request those credentials [5]. The collision between open banking mandates — designed to expand third-party access — and AI agents that can take consequential actions with that access is producing the friction we are now seeing. That tension is not going away.

The money-movement risk is real even without confirmed bank-account theft. BeInCrypto documented two incidents earlier in 2026 where attackers caused AI-linked systems in the crypto sector to send $281,200 to attacker wallets before recoveries were made [4]. Traditional banking has stronger protections, but the question of who is liable when an AI moves money incorrectly is genuinely unresolved. If you are responsible for investigating compromised accounts in your organization, the gap between credential sharing and credential theft is already difficult to adjudicate.

What Is ARTEX and How Did Storm-0940 Use It Against ConnectWise?

ARTEX is not malware in the traditional sense — it is a penetration testing framework that security researchers use legitimately, published openly on GitHub. According to SecurityWeek, it had accumulated more than 12,000 forks before its author closed the repository [2]. The tool works with various AI models to chain together attack stages — coordinating multiple agents across recon, exploitation, and exfiltration without requiring a human operator to supervise each step.

The ConnectWise attack timeline matters. Suspicious activity was first detected on October 14. ConnectWise suspended Cloud Backup, SaaS Security, and Cloud Management almost immediately [3]. Microsoft's attribution report followed on October 21. But Microsoft's telemetry shows the broader Storm-0940 ARTEX campaign actually began in early September — weeks before ConnectWise specifically became the entry point.

The mechanism of the ConnectWise attack is a supply-chain play. ConnectWise Cloud Backup is a service used by managed service providers to back up Microsoft 365 and Google Workspace data. By compromising ConnectWise's application identities — the technical account credentials that allow ConnectWise's software to interact with customer Microsoft 365 environments — Storm-0940 effectively inherited trusted access to hundreds of organizations at once. They did not need to compromise each target individually. The trusted vendor relationship did the work.

What ARTEX added was speed. Between October 10 and October 14, Storm-0940 conducted a password-spraying attack targeting 327 accounts across eight organizations, generating over 151,000 failed login events [3]. After gaining initial footholds, ARTEX then attempted sign-ins to over 2,250 tenants at 2,900 attempts per minute. According to Alex Wells at Hadrian, what distinguishes ARTEX is its ability to coordinate multiple AI agents across different attack stages with relatively little human intervention [5]. In some environments, that coordination got attackers to privileged cloud access in under three hours.

Huntress's Jon Semon told Cybersecurity Dive the working hypothesis is attacks conducted by an AI agent with scripted tooling and occasional human intervention [3]. The key indicator: a ConnectWise application that granted itself global administrator privileges inside a customer tenant. That is not something a human clicks accidentally; it is a deliberate programmatic step. This is exactly what good behavioral detection in EDR telemetry is designed to flag.

Once inside an environment, Storm-0940's agents used Microsoft Graph to inspect the tenant, then modified application credentials — changing the keys on the compromised app so that even after ConnectWise's own connection was disabled, the attackers retained access through the modified application identity. Remediating the initial entry point did not automatically close the door.

How Does ARTEX Fit Into the Broader AI-Attack Picture?

CrowdStrike separately linked ARTEX to AI-based attacks targeting Korean banks, and Japanese researchers connected the tool to a campaign targeting Japanese companies [3]. Zscaler published a technical deep-dive covering the full Storm-0940 workflow this week, including ARTEX configurations, synchronization scripts, Claude Code prompt history, and network routing tools. That level of detail is useful for defenders building detection coverage.

ConnectWise CEO Manny Rivelo framed it accurately: "Nation-state actors are increasingly targeting the software supply chain, because one trusted connection can open the door to many organizations. AI now lets them test those connections at what Microsoft calls 'machine speed'" [3]. One compromised vendor account becomes the key to 2,250 locks, and AI does the turning faster than any team can manually watch.

This connects to a broader pattern. The software supply chain has been a consistent focus for sophisticated actors precisely because trust relationships in SaaS infrastructure are often poorly scoped. A backup service that needs read access to your Microsoft 365 tenant does not necessarily need global administrator privileges, but in practice many third-party applications are over-permissioned. ARTEX did not create that problem — it made exploiting it faster and cheaper.

What Should Defenders Actually Do?

For both the banking AI agent problem and the ARTEX supply-chain attack, the defensive thread is the same: visibility into service principal and application-level activity, not just human accounts.

For organizations running Microsoft 365: Microsoft recommends examining service principal sign-ins alongside subsequent Microsoft Graph activity, directory changes, and resource access, correlating suspicious events against authorized administrative activity [2]. If your SIEM is not ingesting Entra sign-in logs alongside service principal audit events, you have a gap the ARTEX campaign specifically exploited. Reviewing conditional access and MFA policies for application identities — not just human accounts — is a practical starting point.

The persistence mechanism to hunt for: application credentials modified in a short window following initial access. Check Entra audit logs for credential additions or rotations during October 10–14, especially those associated with ConnectWise app registrations. ConnectWise is advising customers to keep connections disabled until they receive direct instructions as restoration proceeds.

For organizations examining third-party access more broadly, the application permission review is overdue. The principle of least privilege applies to OAuth applications just as much as to human accounts — and state-aligned actors with AI tooling are now reliably targeting the over-permissioned ones. A zero trust posture review that specifically addresses application identity scoping is worth prioritizing.

What Remains Unknown

As of October 24, neither ConnectWise nor Microsoft has explained how Storm-0940 initially obtained control of the ConnectWise application identities that enabled the supply-chain attack [6]. That gap matters: without understanding the initial access vector, other vendors in similar trusted-connector positions cannot assess whether they face the same exposure.

The full scope of confirmed compromise within the 2,250+ targeted tenants is also not publicly established. Microsoft observed successful authentication in some environments, and some attacks progressed to privileged access and directory modifications — but the public reporting does not quantify how many organizations experienced confirmed post-authentication damage versus failed attempts.

On the banking side, Axios did not document confirmed financial losses from the agent-access incidents. The liability question — whether banks can hold customers responsible for losses caused by agents they authorized — has not been tested in court and may not resolve cleanly against existing Regulation E consumer protections.

Strategic Implications

These two incidents, happening in the same week, illustrate where AI-related security problems actually sit in 2026. Neither story involves autonomous AI acting independently. Both involve AI tools doing specific things faster and at greater scale than humans could manually manage — and doing them in gaps that existing controls were not designed to close.

The bank problem is fundamentally a policy and identity problem: who counts as an authorized user, how do you prove it at machine speed, and who bears responsibility when the answer is ambiguous. The financial industry built fraud detection around human behavioral patterns. AI agents behave differently — higher frequency, consistent timing, programmatic access paths — and the industry is scrambling to build detection logic for patterns it has never had to recognize before.

The ARTEX problem is a supply-chain and application-identity problem. The speed benefit ARTEX provides is real, but it sits on top of a structural issue that predates AI: too many third-party applications are over-permissioned, and the blast radius of compromising one trusted vendor is enormous. AI-driven automation does not create that vulnerability. It makes exploiting it a more attractive option for actors who previously had to weigh manual labor cost against potential gain.

Defenders who want to get ahead of both problems need visibility and control at the application and service-principal layer, not just the human-account layer. Most identity security investments still focus on the human end. The attacks increasingly are not going there first.