What Is ARTEX? How AI-Driven Autonomous Penetration Testing Works, and Its Internal Architecture, Read From Public Analyses

What is ARTEX? The short answer

ARTEX is an open-source platform in which multiple LLM-driven agents decide for themselves what to do next in a penetration test, run real tools, and keep recording the results. Google Threat Intelligence Group (GTIG) describes it as "an autonomous, multi-agent penetration-testing and C2 (remote-control) platform written in Go, with an embedded Next.js web console."

It was published as an OSS pentest tool, but in autumn 2026 several organizations published cases of it being used in attacks. Without trying to alarm anyone, this article answers three questions:

1. What is running inside? How much of the internal design can public material actually support?
2. What actually happened? What can and cannot be concluded from the reported abuse?
3. What should builders and defenders decide? What has changed, and what has not?

Three points to hold onto before you read on:

• "ARTEX" is not one fixed thing. According to GTIG, the original was deleted by its author in October 2026, and what circulates now is community forks, derivatives such as ScopeWeaver, and a commercial edition called ARTEX PRO. They are not necessarily the same.
• The author did not obtain, run or analyze the source of ARTEX itself. What follows is a comparison of public analyses from five organizations (Google, Microsoft, AhnLab ASEC, JPCERT/CC and CrowdStrike) and the README of one derivative.
• The reported cases do not measure ARTEX's performance. Behind every successful intrusion are failed attempts and the attacker's other means.

How to read the confidence labels

The author has run no reproduction experiment of ARTEX. The defensive tests in the companion article are general tests against a fictional SaaS.

Descriptions of the structure rely mainly on AhnLab ASEC's analysis, with details filled in from the README of one derivative. A README describes that derivative, not the current code of the original, so the body distinguishes the sources and does not link to it (so as not to encourage anyone to run it).

Understanding it in three minutes: Planner and Worker

Start with an analogy.

The Planner is the lead who decides "what to examine next"; the Worker is the person who actually does the work. The lead reads the reports and issues the next instruction. The Worker takes one instruction, checks it with real tools and records the result.

The precise definitions ([Confirmed], AhnLab ASEC):

Glossary: C2 is the mechanism by which an attacker remotely controls compromised machines; SSE is a way for a server to keep streaming progress to a screen; JWT is signed login information; forensics is after-the-fact investigation of traces.

The key point: the LLM "decides" the direction, but ordinary tools send the traffic. ASEC writes that "what is recorded on the target system is not the name of the agent, but the requests the tools actually sent and the execution that followed." What a defender sees is not the presence of AI but the same kinds of traces an ordinary attack leaves.

How it differs from conventional tools

Splitting by "who decides the next move" makes the difference visible (the following table is the author's own framing).

GTIG treats it as a turning point for defenders that agents now explore multiple attack paths on their own, isolate errors and reach an objective in seconds to minutes.

Overall architecture

 Operator (browser)
     |  HTTP / SSE (progress)        [SSE, REST, JWT: fork README only]
     v
+--------------------------------------------------+
| Go backend (Next.js web console embedded)        |
|  - API server                                    |
|  - Engine : per task, 1 planner loop + N workers*|
|  - Agents : goals / planner / worker / chat*     |
+----+---------------------------+-----------------+
     |                           | real tools (shell, HTTP)
     v                           v
+-------------+    +------------------------------+
| PostgreSQL  |    | Recording proxy + approval   |--> Target
|  asset graph|    | gate (some tools)            |
|  explor.    |    +------------------------------+
|  graph      |
+-------------+
 * = described only in a derivative's README (not in ASEC/GTIG/Microsoft)

This diagram is the author's composite, built from ASEC's description and the README of one derivative. The elements marked *, and SSE, REST and JWT, appear only in the README. The operator enters targets, goals and the permitted scope in the web console and connects an LLM API. The server manages the agents' execution state and stores assets and work history in PostgreSQL. The Workers' tool traffic goes through a recording proxy, and some of it goes through an approval process.

What each source supports

The author has not been able to determine whether the differing agent counts reflect different versions or different ways of counting. Refusing to force a single number is part of being accurate.

CrowdStrike's VAPOR PANDA analysis contains one more important detail. Recovered logs include scenes where the operator gave instructions in Chinese, marked 【人类指令】 ("human instruction"), and the company states that a human was involved. The label "autonomous" does not mean there is no human involvement at all.

ARTEX v2: the "Agent Security Workbench" ASEC observed [Confirmed]

In a follow-up dated 13 October 2026, ASEC says it found an internet-facing instance of ARTEX v2. Its interface describes ARTEX as an "Agent Security Workbench", and a central Planner coordinates several Worker Agents. Each agent's execution state and run time, the exploration path, identified assets, evidence and traffic collection, and tool execution are managed as separate components, alongside shared Workspace data and reports, Model Context Protocol (MCP) integration, reusable Skills and agent settings. In a test run that had actually completed, ASEC also observed the central Planner managing several Workers at once.

This leaves room to explain the "three, four or six" disagreement as a difference between versions. But ASEC does not describe the difference between v1 and v2, nor how it relates to GTIG's "six", so which count refers to which version is [Unverified]. ASEC also states that this evolution does not immediately mean fully autonomous attacks, and that real attacks still involve areas that need human judgment and expertise.

Two graphs: why separate "the state of the world" from "the history of decisions"?

The most instructive part of ARTEX's design is that it splits its records in two.

[Confirmed] According to ASEC, ARTEX manages "information about the target itself" and "the judgments made during the work" in an asset graph and an exploration graph respectively.

• Asset graph: domains, IP addresses, services, applications, endpoints. Shared across tasks.
• Exploration graph: goals, facts confirmed, vulnerabilities found, and a record of how later decisions connect to each other.

The README of one derivative is more specific (a derivative's description). The parent-child relations and de-duplication keys of the asset graph are computed by the program, not the LLM; the agent only hands over raw information. The exploration graph's nodes are goal / intent / fact / finding / hint, its edges are spawns / derived_from / yields / proves, and the two graphs are tied together by "anchors".

Exploration graph (per task: why / how far)
  goal -spawns-> intent A -yields-> fact -derived_from-> intent B
                                                    intent B -proves-> finding
  (every node is pinned to assets by an "anchor")
Asset graph (shared: what exists)
  root_domain -> subdomain -> service -> endpoint

Why separate them? [Design analysis]

What follows is the author's design analysis. None of the sources says ARTEX's author split them for these reasons.

1. They have different lifetimes and owners. A fact such as "this subdomain runs this service" outlives the task, whereas "why we tried this direction" only means something inside that task.
2. You can separate what can be made deterministic from what cannot. Parent-child relations and de-duplication keys can be computed by a program. LLM output varies from run to run, but the parts that must not vary (the same asset is one record) can be handed to processing that does not.
3. Decisions become explainable. You can trace which facts and which work led to a given finding. When running an LLM whose results vary, keeping the path rather than only the result is the foothold for auditing and reproduction.
4. Duplicate work shrinks. ASEC also writes that linking the two records reduces repeated investigation of the same asset.

This lesson applies to anyone building their own AI agents too. An agent with no history of its decisions tends to hit the same place repeatedly and is hard to explain afterward. Production design for AI agent tool use covers this in detail.

The control loop: from goal through execution and observation to re-planning

[Confirmed] In ASEC's description the flow is as follows. The user enters a goal and the permitted scope, and Goals organizes them. The Planner creates Intents based on the asset information and observations gathered so far. A Worker runs tools according to an Intent and records new information, and the Planner reviews the returned results to decide the follow-up work.

The README of one derivative draws this as a closed, event-driven loop (a derivative's description).

graph changes -> (debounce) -> wake Planner
Planner : read graph overview + scope
        : assign 0..N intents to a queue      <- most wakes assign 0
Worker  : claim ONE intent -> run real tools (via recording proxy)
        : write fact / asset / finding + per-step activity
write   -> graph changes -> wake Planner ...   (until a goal is proven)

Four design decisions can be read from the README:

• Only the Planner creates work (Intents); a Worker takes exactly one and finishes. Responsibility for creating work is separate from responsibility for executing it, and Workers can be disposable.
• The Planner starts a fresh conversation every time it is woken, and state persists in a shared TODO list. An attack chain is a sequence of dependencies, so the README explains that Intents are not issued in parallel all at once; the next step whose prerequisites are met is assigned each time. State lives in the DB, not in the LLM session.
• A woken Planner often assigns nothing. If there is no new direction, it ends with zero assignments.
• Workers can search each other's in-progress work and reuse it. Observations that have not yet become formal facts can be pulled by later Workers.

What happens when you run in parallel

GTIG records an incident in which ARTEX reached partial command execution and generated 240 log events, accompanied by "errors suggesting that multiple sub-agents pursuing the same objective may have been overwriting each other" ([Confirmed]). But the context there is writes to the target's MySQL log file and to a web-shell filename.

Reading this as a state race inside ARTEX is the author's speculation [Design analysis]. GTIG itself writes "may have", and whether it is an internal race is unknown. What is certain is only this: a problem common to parallel designs, namely that multiple agents pursuing the same goal in parallel can interfere with each other on a shared counterpart, is visible from the outside. The README's emphasis on the boundary "each Worker handles only the one Intent assigned to it" can also be read as a design that contains this kind of problem.

In a separate observation, GTIG says individual runs came in bursts of 2 to 25 seconds, and that in at least one operation 27 events were observed within 23 seconds.

Separating authority to execute from authority to decide

Mechanisms for not trusting the LLM's judgment also appear in ARTEX's structure ([Confirmed], ASEC).

• Work is controlled by an approval process, and the traffic of some of the tools a Worker uses is stored in a recording proxy.
• The LLM decides the direction, a Skill guides the procedure and a Tool runs the command. Even with the same goal, the result changes with the tools, privileges and network scope available.

[Design analysis] This can be read as the flip side of "LLM06 Excessive Agency" in LLM application security (OWASP LLM Top 10), the problem of giving an LLM too much functionality, permission and autonomy. ARTEX is an example of a design that still works when all three are enlarged for the purpose of attacking.

But there is an [Unverified] point. What the approval gate stops by default, and whether the operator can disable it, cannot be established from public material. Approval exists for the operator, so it does not work as a defense when the attacker is the operator.

Failure and retry: why idempotency matters in an agent platform [Design analysis]

This section is not a description of ARTEX's implementation. It covers the questions a designer would ask about a design like this.

When a Worker dies midway, what must have been saved?

The README says the schema creates its tables idempotently at every startup. Making writes idempotent makes retries safe. Side effects that leave the system, however, cannot be made idempotent. GTIG cites a case in which ARTEX made an application's notification feature "send test emails in bulk to more than 1,300 internal recipients". An email cannot be recalled. When an operation chosen by an LLM has real-world side effects, write idempotency alone cannot protect a retry. The same structure shows up in payments. What Exactly-once Actually Guarantees covers it in detail.

What public information shows about usage, and the constraints

This article gives no installation or run instructions.

1. Origin and contents cannot be verified. The original was deleted, and a derivative is not necessarily the same as it. A commercial edition (ARTEX PRO) has also been reported. The README of one derivative says a core dependency (the agent SDK) is unreachable.
2. Using it against a target you have no permission to test can itself be illegal. The README of that derivative also warns to use it only against targets you own or have written permission to test.
3. The point is to understand the structure, not how to use it.

Here is only what public material says about how it is used. The operator registers assets and work in the web console, connects an LLM, passes a target, a goal and a permitted scope, and checks progress and results on the same screen (ASEC). Any model can be used as the LLM (Microsoft). The UI and generated output default to English and can be switched to other languages (Microsoft).

The precondition for researching it is an environment that you own, that is isolated from the outside and that holds no real credentials. If you cannot prepare one, the right call is to skip the research.

Abuse that has actually been reported

The reports from each organization are different activity seen from different vantage points. Do not treat them as the same thing.

CrowdStrike (7 Oct): South Korean financial institutions

• According to press reports, data breaches occurred at several South Korean financial institutions from late September to early October 2026 (a loan-progress inquiry service, and a back-office support system for employees at another bank). CrowdStrike assesses that an ARTEX instance was likely involved.
• The attacker is not named; it is assessed with "moderate confidence" to be Chinese-speaking and financially motivated. The number of affected organizations is unconfirmed. The main LLM is said to be DeepSeek v4.1-flash.

Microsoft (21 Oct): Storm-0940

• From around September 2026, it used ARTEX to target hundreds of organizations worldwide. In some cases, less than 3 hours passed from targeting to privileged access.
• Password spray on 10 to 14 October: 327 accounts, 8 organizations, more than 151,000 failed logins, peaking at 2,900 per minute on 11 October. About 98% of responses were lockouts, and no authentication success was observed from this spray itself.
• A separate event: Microsoft assesses the same actor to be responsible for the compromise of a ConnectWise multi-tenant application. According to the report, the attacker took control of the identities of multiple ConnectWise cloud applications (as Microsoft summarizes it, ConnectWise's advisory concerns attempted unauthorized access associated with Cloud Backup). Details are in the connected-app permissions guide. It then used ARTEX to attempt sign-ins to more than 2,250 tenants at machine speed.
• Microsoft says "most targeting did not succeed, but the actor gained privileged cloud persistence in many organizations within a short time." It also states explicitly that this was not a compromise of its own products.

AhnLab ASEC (29 Oct): infrastructure and verification

• 600 public IPs running ARTEX (322 in the US, 53.7%). As of 14 October, about 900 or more. The location of an IP does not indicate the operator's nationality or the origin of an attack.
• In two tests of its own, a short instruction was enough to reach intrusion. But these were run in environments where known weaknesses had been placed on purpose.
• Follow-up (13 October): among the web services found on ARTEX-related infrastructure, the ARTEX console appeared on 394 systems (46.46%), the AI API gateway Sub2API on 252 (29.72%), Scope Sentry on 22 and CyberStrikeAI on 15. But several services on one system prove neither a common operator nor malicious use; ASEC itself notes that legitimate research environments and shared infrastructure may be included. ASEC also says ARTEX itself cannot be regarded as a malicious tool and can serve legitimate research and testing.
• The User-Agent (for example artex-selfupdate) can be changed and is not, by itself, grounds for detection.

Google GTIG / Mandiant (31 Oct)

• Used since late August 2026 by financially motivated groups and by an actor suspected of espionage. The campaign tracked by Wiz (UNC7228 in GTIG's naming) overlaps with Microsoft's Storm-0940.
• For that actor, from the first compromised account to deep access took about 4 hours, at the fastest 15 minutes.
• Examples of observed behavior: attempts to create a web shell through MySQL log writes, credential theft through SQL injection, Kerberoasting, DCSync, and abuse of a writable admin flag (is_admin=true).

JPCERT/CC (published 8 Oct, updated 23 Oct)

• In Japan, it confirmed attack attempts that abused AI-based platforms such as Cairn, CyberStrikeAI and ARTEX (Case E). Mainly targeting internet-facing web apps, they probed for and tried to exploit various vulnerabilities, including misconfigurations such as theft of configuration and backup files, and attempts against public WSUS servers. Nine suspicious source IPs are listed.

CrowdStrike has one more analysis: VAPOR PANDA used ARTEX to target more than 200 organizations worldwide from 17 October 2026. The company states explicitly that this is separate activity from Storm-0940.

What the Microsoft case shows

The large volume of failures (the spray) and the successful path (permissions a customer had granted to an app) are separate events. Microsoft says it has confirmed, in multiple environments, authentication into customers' Microsoft 365 without an interactive user sign-in through permissions already granted to the app, followed by Graph operations. It also notes that the presence of the app or a successful authentication does not necessarily mean data was stolen, and it does not state the scale of damage. Reading the lockouts as what stopped the spray is the author's interpretation, but the point is not to confuse "a high count of failures" with "a path that succeeded". In technique terms, these correspond to MITRE ATT&CK T1078.004 and T1098.003.

ARTEX's capabilities and limits

Capabilities shown [Confirmed]

• Speed and parallelism: bursts of seconds in GTIG's observations, about 4 hours (fastest 15 minutes) in one campaign. Microsoft gives an example under 3 hours.
• Recovering from failure: GTIG records a case in which the agent saw a "script too large" error, truncated the script, re-ran it and succeeded.
• Reaching the goal from a short instruction: in ASEC's tests, an instruction on the order of "I want you to break into the target. Attack only the specified target" got it as far as arbitrary program execution, and for ActiveMQ as far as command execution on 4 internal hosts.
• Records of business-function abuse: GTIG recorded abuse of a writable admin flag, attempts to read other users' attachments, and bulk email through a notification feature. The success rate, and how much of this the agent found autonomously, are unknown.
• Low barrier to entry: GTIG cites the low barrier, how easily new exploits can be incorporated, and the large scale.

Limits shown [Confirmed]

• Success is not uniform. Microsoft says most targeting did not succeed.
• It is noisy. GTIG assesses that, compared with a skilled human, the path to code execution is dominated by trial and error and is far noisier forensically. It also says speed is bought at the expense of stealth, which raises the chance of detection. At the same time it points out that detecting and preventing are separate functions, and detecting in time does not stop the objective from being achieved.
• A falling success rate is offset by scale. GTIG expects attackers to make up for a lower success rate by widening the reach of a campaign.
• Possible interference between agents. As noted above, whether it is an internal race is unknown.

What has not been established [Unverified]

• ASEC's tests ran in an environment with known weaknesses placed in it. They do not show the ability to find unknown weaknesses.
• At what rate, and how autonomously, it can find authorization flaws and business-logic flaws. GTIG's records are cases, not rates.

What this means for web app developers

The detailed design is left to How Should Web Apps Prepare for ARTEX-Style AI Attacks?. Here is only the mapping table.

The defenses GTIG lists are long-standing best practices: "separating the control plane, short-lived credentials, least privilege, segmentation and behavioral detection." GTIG also says that, given the scale of attacks, defense strategy needs to be rethought fundamentally. There is no new magic, but the fact that speed and the barrier to entry have changed is reason enough to revisit it.

For logging and detection, see Security logging and detection engineering; for response afterward, Incident response based on NIST SP 800-61 Rev.3. For preparing against probing of public servers, see Detecting and preventing port scans, and for another incident reported around the same time, the GMO Desktop Cloud unauthorized access explained.

What this article has not verified

• Running ARTEX, analyzing its source code, or reproducing anything independently: none of this was done.
• The design of the original code, and how it differs from derivatives and the commercial edition.
• The default behavior of the approval gate, and whether it can be disabled.
• The correct way to count the agents.
• The rate at which it can find unknown weaknesses or authorization flaws.
• The full picture of the activity each organization reported (each sees only part of it).

Going forward, watch for how the deleted original is handled, how derivatives diverge, and revisions to each organization's analysis.

One point to take away: what AI has changed is the speed of recovering from failure, the number of things tried at once and the barrier to entry. That is exactly why a design that does not leave judgment to an LLM, and secures systems with deterministic mechanisms such as authorization, input validation, execution control and audit logs, is a principle that holds for both attack and defense. Whether you can verify those yourselves is what actually separates outcomes. The next article lays this out.