An Open Source AI Agent Breached Four Companies

A tool built to help security teams find their own weaknesses just became the weapon several attackers used to find everyone else's.

On November 3, 2026, blockchain infrastructure provider Chainstack disclosed that an external attacker had reached part of its production environment, exposing customer account data, password hashes, and systems holding node credentials for blockchain deployments the company hosts on behalf of its customers. Security researchers tied the intrusion to a wider pattern of break ins at other companies over the same two week stretch, all connected to an open source autonomous penetration testing framework called ARTEX. The framework was not built by a nation state or a ransomware crew. It was published by an independent developer for learning and research, then picked up by attackers who turned it against live production systems.

That origin story matters more than the breach total. Every enterprise that has ever approved an AI coding assistant, an automated red team tool, or an agentic workflow for internal use is now looking at proof that the same category of software, repurposed by someone else, can move from a side door into a production database in three days. For a CISO or a chief compliance officer, the Chainstack disclosure is not primarily a story about blockchain infrastructure. It is a story about what a company can prove once an autonomous tool has been inside its systems, and how thin "we found no evidence" sounds once a regulator, a customer, or opposing counsel asks for something stronger.

This post works through what Chainstack has confirmed, what ARTEX is and where it came from, and the governance gap the incident exposes for any organization that must answer for what an AI agent touched, whether that agent was theirs or an attacker's.

Key Takeaways

  • An AI pentesting tool became an attacker's weapon. ARTEX was built for security research and was repurposed within weeks to help breach a blockchain infrastructure vendor and at least two other companies.
  • "No evidence" is not the same claim as "no access." Chainstack says it found no evidence that node credentials were read, a true statement that still leaves customers unable to confirm what happened.
  • The attacker reached production three days after the first foothold. That timeline is faster than most vendor security reviews and most enterprise incident response plans assume.
  • A single compromised component can expose unrelated customers. Chainstack's intrusion began through a third party component, the same entry pattern researchers have linked to a cluster of break ins across unrelated companies this fall.
  • Closing the source code did not close the threat. The developer behind ARTEX converted the project to closed source after it was tied to bank breaches in South Korea, but copies already downloaded kept circulating and kept getting used.

What Chainstack Disclosed, and When

Chainstack's own incident notice lays out a timeline that is unusually precise for a vendor breach disclosure. An external attacker gained access to a development environment on October 26, 2026, through what the company describes only as a third party component, without naming the product or the vulnerability involved. By October 29, the attacker had escalated that foothold into parts of Chainstack's production environment. Chainstack detected the intrusion on October 31 and cut off the attacker's access the same day, then spent two more days finalizing its investigation before publishing the disclosure on November 3.

The exposure itself breaks into two categories. The first is a customer account database containing organization names, account holder names, member email addresses, and password hashes. The second is systems holding node credentials, the keys customers use to authenticate to the blockchain nodes Chainstack runs for them. Chainstack says it found no evidence the node credential systems were read, but it is treating them as exposed anyway and asking every customer to rotate credentials, regenerate platform API keys, and change any reused passwords. The company also states that customer nodes, its console, and its API were not modified, that service was not disrupted, and that payment details were never at risk because it does not store full card numbers.

The Hacker News reported the disclosure the same day and placed it inside a broader pattern researchers were already tracking. Its coverage describes the Chainstack incident as assessed to be part of a larger, AI powered attack campaign that had come to light the week before, with reported overlap between the tools and techniques used against Chainstack and a separate, China linked threat cluster. That is an assessment, not a confirmed attribution, and neither Chainstack's own notice nor The Hacker News claims Chainstack has independently confirmed who was behind the intrusion or exactly how the third party component was abused.

A Research Tool Built to Find Flaws, Not Exploit Them

The name attached to this pattern, ARTEX, did not start as an attacker's project. It began as an open source, agentic penetration testing framework published by a developer known on GitHub as Autumn-27, designed to automate the reconnaissance and exploitation steps a human pentester normally runs by hand. The tool ran DeepSeek's v4.1-flash model as its primary reasoning engine, with Z.ai's GLM-5.3 and SpaceXAI's Grok 4.6 available as supplementary models, and it was built, in the developer's own words, for learning and research.

That framing held up for a while. Then, in late September 2026, CrowdStrike linked a wave of intrusions at Shinhan Bank, Yegaram Savings Bank, and several other South Korean financial institutions to an operator running ARTEX. The attribution did not come from bank network monitoring. It came from the attacker's own exposed working directories, which contained Claude Code session histories and Chinese language prompt files, along with a record of the attacker asking an AI assistant where to sell the stolen Korean banking data. On October 8, 2026, Autumn-27 converted the project to closed source and stopped new releases, writing that ARTEX was designed for learning and research and that the bank attacks had nothing to do with its creator.

Closing the repository did not close the gap. Copies of the tool were already in circulation, and the skills needed to run an agentic penetration testing framework do not disappear when the original source goes private. Three weeks after the South Korean bank disclosures, researchers were describing the same framework, or close variants of it, as the common thread in a new round of intrusions against companies with no connection to banking at all. itnews.com.au reported on November 2, 2026 that the ARTEX framework had spread to another China linked group, describing it as linked to both espionage and financially motivated campaigns running in parallel rather than a single operator's toolkit.

One Toolkit, Four Victims, Three Weeks

The practical effect of an open source agentic attack framework is that it lowers the cost of running a credible intrusion to the point where several unrelated operators can run the same playbook against different targets inside the same month. Chainstack is one entry on that list. The Hacker News coverage also describes a separate incident at WorkOS, an identity and infrastructure vendor, discovered on October 30, 2026 and limited to its go to market systems rather than its customer platform. WorkOS said the activity it found used the same autonomous AI agent framework, and the company's own statement is worth quoting directly because it names the shift plainly: the technique "increases the speed and scale of attacks that exploit weaknesses such as exposed applications and stolen credentials."

A separate incident involving Chainalysis surfaced in the same reporting window, and a distinct September 2026 breach at the Dutch Institute for Vulnerability Disclosure, caused by two zero day flaws in the open source Zammad ticketing system, has also been connected to the same broader campaign by researchers tracking the pattern. These are separate companies, separate entry points, and in at least one case a separate vulnerability class entirely. What links them is not a single attacker's infrastructure. It is a shared set of tools and techniques that make reconnaissance, exploitation, and lateral movement cheap enough to run against many targets in a narrow window, which is precisely what an autonomous agent is built to do well.

For a third party risk program, that distinction matters more than it sounds like it should. A security questionnaire built around "has this vendor had a breach" treats each incident as an isolated data point. A security program built around "what tooling classes are now capable of compromising our vendors at this speed" treats Chainstack, WorkOS, and the Zammad flaw as the same risk wearing three different names, which is the only framing that lets a risk team ask the right follow up question before the next one lands on their own supply chain.

The Credentials Chainstack Says It Has No Evidence Were Read

Read Chainstack's own language again, carefully. The company has no evidence that the systems holding node credentials were read, but it is treating those credentials as exposed and telling every customer to rotate them. Both halves of that sentence are responsible, and Chainstack deserves credit for erring toward disclosure rather than downplaying the risk because proof was thin. But consider what "no evidence" means in a forensic sense. It means the logs, monitoring, and audit trail available to Chainstack's investigators did not show the attacker reading that data. It does not mean the attacker did not read it. Those are different claims, and the gap between them is exactly where a regulator, a plaintiff's attorney, or an enterprise customer's own security team is going to push.

This is the sharper version of a problem Bonfy has argued since AI governance accountability became a board level topic. An absence of evidence of access is not evidence of absence of access. It is a statement about the limits of what was logged, not a statement about what happened. When the actor inside your systems is a human using familiar tools, your existing monitoring was at least designed with that actor in mind. When the actor is an autonomous agent moving through a development environment into production in three days, the question changes from "did our logs catch something" to "were our logs built to catch this kind of actor at all."

That question is exactly the kind of evidence-quality problem Kiteworks has tracked as evidence-quality audit trails moves from a nice to have into a compliance requirement. A log that proves a service account made an API call is not the same as a log that proves what data that call touched, in what context, and whether the result matched an authorized purpose. Chainstack's disclosure is honest about where its own trail runs out. Most organizations have not stress tested their own logging well enough to know where theirs would.

The Third Party Component Is Still the Easiest Door

Chainstack has not named the third party component the attacker used to reach its development environment, and that silence is itself instructive. It means the company either cannot attribute the entry point to a single disclosed vulnerability or has chosen not to name a partner publicly, and either way the lesson for every other organization running vendor relationships is the same. An attacker does not need to break your front door when a dependency, plugin, or integration your team trusts already has one propped open.

Third-party breach surge is not a new pattern, but an autonomous agent changes its economics. A human attacker must manually probe a dependency for a usable flaw, which takes time and favors patient, well resourced operators. An agentic framework can run that same reconnaissance continuously against a long list of targets, flag whichever one yields first, and move to exploitation without a human deciding to prioritize that specific company that week. Vendor breach liability research has already found that third party incidents now drive a disproportionate share of enterprise legal exposure, and an attack framework that makes probing cheaper at scale is going to widen that gap rather than close it.

The practical consequence for a CISO evaluating any infrastructure vendor, blockchain or otherwise, is that the due diligence questionnaire written for human attackers is now incomplete. Asking whether a vendor has a SOC 2 report or a penetration test on file answers whether they tested against a point in time threat model. It does not answer whether their detection program can catch an autonomous actor that moves from a side door to production in under three days, which is the timeline Chainstack itself reported.

What Real Proof Requires

If "no evidence of access" is not the same claim as "no access occurred," the next question is what would close that gap. The honest answer is a record that exists independent of the attacker's own path through the system, written at the moment data is touched rather than reconstructed afterward from scattered application and identity logs. Non-human identity governance is the discipline that makes this possible for AI agents acting on your own behalf, because it ties every automated action to a specific identity, scope, and purpose rather than a shared service account that could belong to anyone.

The same principle applies in reverse when the actor was an attacker's agent rather than your own. Exposed credentials research has repeatedly found that billions of valid credential pairs sit in attacker hands at any given time, which means the deciding factor in an incident like Chainstack's is rarely whether credentials existed to steal. It is whether the systems holding sensitive data can produce a record of exactly what was retrieved, by whom, and for what stated purpose, strong enough to answer a regulator's question without relying on the word "no evidence."

That kind of record is the idea behind Contextual Data Enforcement, an enforcement point that sits between an agent and enterprise data and evaluates what is being retrieved against the entities and context involved, rather than trusting that a credential being valid means the request was appropriate.

Credential rotation is necessary but not sufficient on its own. Outlive revoked credentials research presented at Black Hat and DEF CON in 2026 found that agentic sessions and cached tokens frequently survive a credential revocation event longer than security teams assume, which means a rotation announcement is the start of a remediation process, not its conclusion. Chainstack's advice to customers, rotate credentials and regenerate API keys, is correct and necessary. It is also only the visible half of what a defensible response requires, and the other half, proving the blast radius with evidence rather than inference, is the part most organizations have not built yet.

The Governance Question Every CISO Now Owns

ARTEX is a useful case study precisely because it did not start as malware. It started as a legitimate research project, the kind of tool a security team might reasonably have approved for its own red team program. AI red teaming is becoming a standard practice at exactly the moment the line between a defender's tool and an attacker's weapon has never been thinner, since the same autonomous reconnaissance and exploitation loop that helps a security team find its own weaknesses is the loop an attacker runs against someone else's production environment. An enterprise cannot assume that approving an agentic tool for internal use settles the governance question, because the same capability, once it exists in the world, does not stay inside the fence a license agreement draws around it.

That is also why limiting agent scope matters as much for defensive tooling as it does for the agents attackers deploy against you. An agentic pentesting framework given broad, standing access to probe infrastructure is dangerous in exactly the same shape whether your own red team is running it under a contract or an unrelated attacker downloaded it from a public repository before the source went private. The control that would have mattered in both cases is the same one Chainstack's own advisory implicitly points to: credentials and permissions scoped narrowly enough, and logged specifically enough, that a three day intrusion window produces a defensible record rather than an open question.

For Bonfy's own customers, the Chainstack disclosure is a preview of a question regulators are already circling from other directions, the one identity and intent work has tracked across UK, EU, and US agency guidance this year. It does not matter, to a regulator or to an affected customer, whether the actor that touched sensitive data was your own sanctioned AI agent or an attacker's autonomous framework. What matters is whether you can reconstruct what was touched, under what authority, and for what purpose, at the moment it happened rather than weeks later when the investigators have already said as much as the logs will let them say.

Relationship-aware governance treats that reconstruction as a design requirement rather than a forensic afterthought, because the record is built as a byproduct of enforcing policy at the moment data moves, not assembled later from whatever logs happened to be running. Continuous control over AI agents reaching enterprise data, including agents reaching data through agentic data security chokepoints like MCP servers, is what turns "we have no evidence" into "we can show you exactly what happened," and that distinction is the one Chainstack's customers, and every CISO reading this disclosure, will be asked to make good on the next time an autonomous tool gets inside the fence.

Frequently Asked Questions

1. A cloud vendor we rely on just told us it found no evidence that our password hashes or API credentials were read during a breach, but it cannot rule it out either. Should we treat that as low risk, or rotate every credential anyway?

Rotate every credential the vendor flagged as potentially exposed, regardless of whether the vendor found direct evidence of access. "No evidence of access" describes the limits of the vendor's own logging, not proof that nothing happened, so treating it as low risk assumes a certainty the vendor itself did not claim. Rotation, combined with monitoring for unusual authentication activity, is the only defensible response.

2. What is an open source AI pentesting framework, and how is it different from the vulnerability scanners our security team already runs?

An open source AI pentesting framework is software that uses a large language model to plan and carry out reconnaissance, exploitation, and lateral movement autonomously, rather than simply flagging known vulnerabilities for a human to act on. A traditional scanner matches signatures against a fixed rule set. An agentic framework reasons about a target in real time, chains discovered weaknesses together, and can be redirected against new targets without being rebuilt.

3. We are evaluating a blockchain node infrastructure provider for a fintech product. What security questions should we ask about how fast they can detect and contain an AI driven intrusion that moves from development into production?

Ask the provider to state, in writing, the shortest and longest time its monitoring has taken to detect lateral movement from development into production in the past year, and whether that detection relies on logs an attacker's own agent could alter. Also ask whether node credentials and API keys are logged at the moment of use, not only at issuance, since issuance logs alone cannot show what an attacker did with a stolen key.

4. If a vendor's breach notice says there is no evidence certain credentials were accessed, does that satisfy what a regulator or an auditor will expect as proof, or do we need something stronger to show our own board and customers?

A vendor's statement that it found no evidence of access does not satisfy what most regulators expect as proof, because regulators increasingly ask organizations to show what happened rather than explain what their logs failed to capture. Your own documentation should independently record your response after the notice, including credential rotation, monitoring steps, and any confirmation obtained directly from the vendor, since that record is what an auditor will examine.

5. What is the difference between a traditional SIEM and a system built for proving exactly what an AI agent touched during a third party vendor breach, and does Kiteworks handle that differently?

A traditional SIEM aggregates logs from many systems to show an event occurred, such as an API call or a login, but it typically cannot show what data an AI agent retrieved or why. Kiteworks instead builds that evidence at the moment data is accessed, tying each action to an identity, a classification, and a stated purpose, so the record answers what was touched and under what authority.

To learn more about non-human identity governance, schedule a custom demo.