An AI tool originally hosted openly on GitHub to help companies find their own vulnerabilities suddenly had its developer decide to stop publicly updating it.
The reason wasn’t that the project failed.
Nor was it due to lack of users.
The issue was that this tool was discovered by a cybersecurity firm to be used in real attacks against banks.
The AI agent is called ARTEX.
It was initially designed as an automated penetration testing tool.
Companies could run it within authorized environments to help identify network weaknesses and assess security risks.
But by October, things took a drastic turn.
When U.S. cybersecurity company CrowdStrike investigated attacks on South Korean financial institutions, they found the following inside attacker-controlled infrastructure:
ARTEX configuration files,
AI coding session logs,
and other data left from interactions with large language models.
A tool originally used to “find your own vulnerabilities”
was now appearing in “attacks on other systems.”
ARTEX Is Not a Language Model That Does Everything on Its Own
ARTEX itself is not a large language model like ChatGPT or Claude.
It’s more of a penetration testing agent that orchestrates AI.
It can connect to external models and automate testing processes that cybersecurity professionals would normally perform step by step.
According to Reuters, ARTEX can link to models including ChatGPT, Claude, and DeepSeek.
Its original purpose was to enable companies and organizations to conduct security assessments within their authorized environments.
Such tools are not inherently malware.
Penetration testing is a normal cybersecurity practice.
One must actively search for vulnerabilities and simulate attacks to understand whether systems are breachable.
The real problem is:
The same capability, if aimed differently, can turn a defensive tool into an offensive weapon.
CrowdStrike Found ARTEX in Real Attack Campaigns
CrowdStrike released their findings on October 7.
After analyzing attacker-controlled servers, researchers found ARTEX’s configuration data and multiple AI coding session logs.
CrowdStrike concluded that between late September and early October, a threat actor employed ARTEX combined with several large language models to target South Korean financial institutions.
CrowdStrike also suggested the attacker was likely a Chinese speaker pursuing financial gain.
However, these are attribution assessments made by the cybersecurity company.
South Korean police are still investigating.
Therefore, it’s inaccurate to claim:
“A court has proven ARTEX hacked nine banks.”
The more accurate statement is:
CrowdStrike linked ARTEX to this wave of attacks, with at least nine South Korean banks publicly reported or confirmed targets of cyberattacks since late September.
The Developer Made a Clear Decision: No More Public Updates
Following the exposure, ARTEX's developer “Autumn-27” announced:
ARTEX will no longer receive public updates.
The project is now closed source.
There will be no more new releases or public maintenance.
Reuters confirmed the original ARTEX GitHub page has been taken down.
The developer stated ARTEX’s original purpose was to help enterprises conduct security risk assessments and improve defenses.
They voiced opposition to any illegal use and emphasized that unauthorized, unlawful usage should not be the responsibility of the tool’s creator.
So far, it seems like a simple solution:
If the tool is abused,
just shut down the code.
But the problem is—
Open source doesn’t have a true “recall button.”
With GitHub Shut Down, What About Copies Already Downloaded?
Once code is published,
others may have already:
downloaded it,
forked it,
backed it up,
modified it,
and redistributed it.
The original repository disappearing
doesn’t mean all copies vanish as well.
ARTEX is a direct example.
Although the original project was taken down, publicly accessible backups of ARTEX’s code still exist online.
There are also derivative projects built on the original ARTEX source.
In other words, what the developer truly controls now is:
The future official versions.
They can stop updating.
Stop maintaining.
Stop adding new features.
But the old released code
will not simply disappear because the author deleted the repository.
This Is the Hardest Part About Open Source and Dual-Use Technologies
Many technologies have dual-use characteristics, meaning:
The same capability can be used for good or for harm.
Encryption protects data but can be used by criminals.
Drones can aid disaster relief or be weaponized.
Security scanners help companies find weaknesses but can also help attackers discover entry points.
ARTEX’s challenge is:
AI agents further automate capabilities that used to require manual operation.
So it’s not just about:
“Can this tool attack?”
But rather:
How much has it lowered the barrier to carrying out these tasks?
Another Reuters report noted that recent cybersecurity incidents in South Korea and Japan have raised concerns among governments and enterprises that AI is making certain attacks faster, cheaper, and easier to execute technically.
So Should These Tools Never Be Open Sourced to Begin With?
That question isn’t so simple.
If security research tools aren’t public, defenders lose:
methods to inspect,
research data,
testing tools,
and validation capabilities.
A key benefit of open tools is that the cybersecurity community can collectively inspect, modify, and research how to detect behaviors caused by those tools.
The real issue isn’t just:
“Is open source better or is closed source better?”
The complexity arises when a public tool evolves from “helping find weaknesses” to “AI agents capable of automating multiple steps of an attack chain.”
Then, relying solely on:
“It can only be used legally”
may no longer be sufficient.
How Much Responsibility Does the Developer Bear?
The developer’s position is understandable.
They build security testing tools.
Just because someone uses a knife to commit a crime doesn’t make the maker an accomplice.
Similarly, using penetration testing tools to hack others doesn’t automatically make the creator an attacker.
There’s no solid evidence that ARTEX’s developer was involved in the South Korean bank attacks.
This distinction must be clear.
But AI agents complicate this further than traditional tools.
Because as a tool becomes:
more autonomous,
easier to use,
able to integrate powerful models,
and capable of completing more steps independently,
developers must think earlier about:
Not just what they intended the tool to do, but what the worst actors can do once it’s public.
The Real Concern Isn’t That the Developer Shut Down GitHub
The real takeaway is why they had to shut it down now.
Once a tool is public,
its capabilities begin to move beyond the author’s control.
While it’s just speeding up certain steps for researchers, the risk might be limited.
But when an AI agent automates reconnaissance, analysis, and exploitation—tasks that were once dispersed—
“Publishing code” isn’t simply sharing a tool.
Sometimes it’s sharing a new capability.
The difference with capabilities compared to regular software is that:
Software can be taken down.
But learned, copied, or forked capabilities may never be fully retracted.
So the most important issue ARTEX highlights isn’t:
“Open source AI is dangerous.”
But rather:
When AI tools have real defensive and offensive capabilities, we must decide before public release which abilities, once out there, have no true recall.
Recommended Reading
This article approaches the issue from a different angle: even a non-malicious agent can cross security boundaries if its capabilities and goals are sufficiently strong.
When downloadable, modifiable AI models start aiding real vulnerability research, the difference between “making defenders stronger” and “lowering attack barriers” may just be user intent.
If AI agents grow more powerful, another path is to run fixed tests, permissions, and sandboxing before a full public release to understand how they might fail.
