ARTEX (Artex) is open-source software that connects large language models (LLMs) to coordinate security inspection planning and tool execution. It is not the name of the model itself, but a system that bundles models, execution tools, and work records. Interest has grown recently with reports of personal information leaks in the financial sector, but it is important to distinguish between the fact that related traces were found and the claim that the entire attack was carried out solely by AI.
The same distinction is necessary when adopting it. Even security analysis software can expose the adopting organization to new risks if it reads files, executes commands, and sends content to external models. This article explains ARTEX’s structure, development history, risks during internal review, and boundaries to observe in external evaluations, based on public incident data and official repositories. It is not a user review based on installation, execution, or performance measurement.
Featured Image: AI-generated conceptual diagram. It is not a reproduction of an actual ARTEX screen or financial institution system.
1. What has been confirmed in the financial sector incident?
The existence of the incident, observations related to ARTEX, reporting on usage traces, and final technical verification are different levels. Reading them together with the date of the data can reduce the problem of initial and subsequent reports appearing to conflict.
On October 2, 2026, the Financial Services Commission (FSC) announced that additional damage occurred at Kookmin Bank and others following the Shinhan Bank data breach, and that on-site investigations and sharing of attack IPs and types were underway after reporting. It ordered the identification of all externally exposed services and the inspection of authentication and access controls. This official document does not mention ARTEX by name or a judgment of a fully autonomous AI attack. FSC Announcement
On October 2, Seoul Economic Daily reported that ARTEX’s Chinese penetration testing console mark was observed in the HTML title of a server presumed to have been used in the attack. The article at the time included a caveat that it was not confirmed whether it was actually used as an attack tool. This should be read as an observation indicating the possibility that a related environment existed. Seoul Economic Daily Initial Report
On October 3, Herald Economy cited a Financial Security Institute official, stating that traces of ARTEX utilization were confirmed in Shinhan Bank logs and attack IP backtracking. The same official explained that the attack was not carried out solely by AI without human intervention. Therefore, it is inaccurate to claim that there is no basis for its use, ignoring subsequent reporting. Herald Economy Follow-up Report
However, this article has not independently obtained, reproduced, or verified raw logs or final technical reports. It cannot be definitively stated from this data alone which version and model were used, how much each function was involved in the incidents at which banks, or what the degree of automation was. There is also insufficient evidence to infer the attacker’s nationality from the tool’s Chinese interface or development account.
| Source | Confirmed or Reported Content | Content Not Confirmable by This Source |
| — | — | — |
| FSC Announcement Oct 2 | Financial sector breach, on-site investigation, threat intelligence sharing, and access control inspection | ARTEX involvement and degree of AI automation |
| Seoul Economic Daily Report Oct 2 | Observation of ARTEX console mark on presumed server’s HTML title | Role in actual attack process |
| Herald Economy Report Oct 3 | Financial Security Institute official explains confirmation of usage traces | Independent verification of raw evidence, models used, and full automation |
This distinction is not to downplay the incident. To determine what needs to be defended, confirmed damage and assumptions about tools should not be mixed. Server-side access control for actual requests and external service list checks are necessary regardless of the involvement of a specific AI tool.
2. A System Connecting Multiple Components, Not Just One Model
The project analyzed in this article is Autumn-27/ARTEX on GitHub. The official repository describes it as a system combining a Go backend, Next.js frontend, PostgreSQL database, and multiple LLM agents. An agent is a program that connects model responses with tool calls. Official Repository
The overall structure can be understood as having parts for planning, performing tasks, storing results, and human review. The planning agent divides tasks to be checked next, and the execution agent processes assigned tasks with tools. The screen displays the progress and results. The term “automation” refers to this repetition, not the disappearance of human goal setting, configuration, or review.
Records are divided into two perspectives: an asset graph, which is a connected list showing what targets and services exist, and an exploration graph, which is a record showing how thoughts, observations, and discoveries were connected in the current task. Knowing the target and what was confirmed about it are managed separately. The two graphs are connected but do not have the same data structure.
Conceptual diagram reconstructed based on official documentation. Simplified based on README’s System Architecture and execution agent source. It does not represent an attack path.
The execution agent in the public source configures tools like file reading, writing, editing, and Bash. Bash is a conduit for executing operating system commands. While it creates dedicated directories for each task, simply dividing directories does not prevent processes from accessing other files or networks. Therefore, the permissions of the execution environment are an important subject for review. worker.go
3. Evolution and Security Fixes in Public History
According to GitHub metadata, this repository was created on July 26, 2026, and v0.1.0 is also listed in the release list on the same day. This is the starting point for the current public repository and distribution records, not proof of the development start date. The description “competition-winning project” is in the repository’s self-introduction, and this article has not independently verified the original competition results. Repository Metadata · Release List
The latest official release at the time of investigation is v0.3.14, released on September 24, 2026. The analyzed main branch is commit b55ceb1, which includes subsequent changes. Therefore, the current behavior of main should not be directly described as the behavior of the v0.3.14 distribution. For actual review, release, commit, and image identifiers should be fixed, and the settings for that version should be checked.
The change history includes items that demonstrate why safety controls must be continuously verified. The following content describes past issues and fixes recorded by the project and should not be interpreted as a claim that all current versions are vulnerable or that these were the cause of the incident. Official CHANGELOG
| Version·Date | Changes Recorded in History | Questions to Review |
| — | — | — |
| v0.3.10 · Sep 13 | Fixed query issue where assets from other tasks were mixed into the target | Is target separation per task actually maintained? |
| v0.3.11 · Sep 15 | Improved code block handling for model review results | How are review results handled if they cannot be interpreted? |
| v0.3.12 · Sep 17 | Restricted default address of record proxy to localhost | To which networks are the screen and proxy exposed? |
| v0.3.13 · Sep 19 | Mitigated incorrect allowance path due to truncated review output, added task-specific allow/block rules | Are blocking on failure and target restrictions independently verified? |
The key is not the number of fixes. Problems can arise at different layers, such as model output interpretation, task scope queries, and network exposure. Updates are necessary improvements, but the fact that an update has occurred once does not guarantee the safety of the entire execution environment.
4. Internal Use Can Make the Organization an Attack Target
The risk of adopting a security tool is different from implying a specific project has a backdoor. This read-analysis did not identify malicious backdoors. Risks become concrete when considering execution privileges, external connections, record sensitivity, and the supply chain together.
Installation Path and Supply Chain
The supply chain refers to the path through which executables are obtained, including programs, dependencies, containers, and updates. The official configuration uses external container images and PostgreSQL, connecting local data and skill directories to the container. If the base image tag changes, the executable may differ even if the same settings are reused. docker-compose.yml
Even in a learning review environment, it is advisable to check sources, versions, and hashes, and not to run unreviewed installation scripts directly on regular work equipment. Organizational source repositories, SSH keys, cloud credentials, and browser sessions should not be shared with the learning execution environment. This is not a claim that ARTEX steals such information, but a general control to reduce the scope of damage from tampered or overly privileged executables.
Model Connection and Detailed Records
The model connection source handles API keys and custom API addresses/proxy settings. Connecting to an external model means that the content included in the request can be transmitted to the selected provider or relay point. It is necessary to check which providers and addresses are approved, how much content is minimized, and what the retention policy is. The mere fact that the source has connection functionality does not confirm the actual transmission content of a specific installation. provider.go
The detailed LLM logging feature stores requests, responses, and raw communication bodies in the database according to settings. Body logging and token usage logging are separate. Information not visible on the screen during execution may also remain in the logs, so retention periods, access rights, and deletion/backup policies must be set separately. llmrec.go
This is why synthetic data is used instead of actual customer responses, operational logs, contract data, accounts, and keys. Simply turning off the logging button does not prevent content from being sent to external models. External transmission and local storage are different verification items.
Tool Permissions and Prompt Injection
Prompt injection is the risk of making the agent interpret sentences within the material to be read as commands. This is especially important when public pages, repository content, or tool responses are part of the task data. This is not a vulnerability report reproduced in ARTEX, but a threat model to consider in a structure that reads external data and calls actual tools.
For example, even if a learning material contains sentences that induce execution, those sentences cannot replace human approval or organizational policy. File, process, and network permissions should be restricted externally, and approval and logging should be verified before execution. Writing precautions in the prompt is a necessary explanation but cannot create operating system permission boundaries.
Web Interface and Network Boundaries
The Compose example specifies separate ports for the screen/API and a proxy port restricted to localhost. The exposure scope for the screen/API requires checking the host firewall and deployment settings. Using containers does not inherently block external communication or isolate it from the organizational network. The learning network should be separated from the business network, and communication other than approved model connections should be restricted. Official Compose Configuration
5. Even with an Approval Screen, Not All Actions Are Automatically Blocked
The analyzed main source includes rules for allowing, blocking, or requesting human approval for tool calls. However, the behavior varies depending on the list of tools to which the rules apply and the review function settings. If model review is off or not connected for calls that do not match the rules, there is an allowance path, and model failures or uninterpretable results follow the configured failure policy. guard.go · intercept.go
Therefore, it should not end with the confirmation “it’s safe because there’s an approval function.” It is necessary to verify in an isolated environment which calls are subject to review, whether actual execution stops during approval waiting, what happens in case of review failure or timeout, and how already started tasks are handled after interruption. This article does not cover how to disable or bypass the review function.
Operational review diagram reconstructed based on official code. Approval Source, Model Connection, Record Storage are the basis. It does not mean that all controls are provided or activated by default.
Organizations can establish clear judgment criteria. If verification requires connecting to work equipment or operational accounts, the scope should be narrowed again, and if unauthorized destination communication cannot be prevented, execution review should be postponed. If the design requires actual customer data, it should first be checked whether synthetic data can be used instead. The convenience of a security tool and the safety of the environment in which it is used must be evaluated separately.
6. How Can It Be Used for External Penetration Testing?
Here, tool usage restrictions come first. The author’s declaration in the README describes the allowed scope as personal learning, code research, and local isolated principle verification only. It explicitly prohibits performing actual tests on websites, online services, or network systems, and practical penetration testing or use in production environments, even if assets are owned or permission has been granted. Therefore, this article does not recommend procedures for deploying ARTEX to external live services. README Usage Restrictions
The repository license is AGPL-3.0, and the README also distinguishes between the open-source license itself and a separate author’s usage declaration. The two different documents should not be combined into one sentence to conclude that all commercial use is prohibited or that written permission alone makes it acceptable. The legal effect or applicability of separate declarations is beyond the scope of this technical article. Both documents should be reviewed together in an organization’s legal and security review. LICENSE Original Text
General operating principles derived from ARTEX’s structure can be applied to external evaluation tasks. Actual use should proceed after separately selecting tools and contracts that permit the intended purpose. The following is an example of an evaluation plan unrelated to the tool and is not a guideline for executing ARTEX on live targets.
- Define the scope in writing. Document and fix asset owner’s approval, target list, time, allowed and excluded activities, responsible persons, and interruption authority. Do not assume that the right to send contract customer’s operational data to the model is automatically included.
- Isolate the environment. Do not reuse work accounts and equipment; use approved test accounts, synthetic data, and separate workspaces. Prevent access to unnecessary files and destinations.
- Human judgment before execution. Separate model suggestions from actual tool execution. Proceed only with actions reviewed for scope and impact, and defer failed or uncertain results to interruption or human review.
- Minimize evidence retention. Link time, target, approval basis, observation results, and re-verification results after modification. Do not attach original personal information or unnecessary communication content to reports.
- Define interruption conditions first. Stop if out-of-scope targets, actual personal information exposure, unauthorized communication, service anomalies, or log omissions are confirmed. Categorize results as verified, unconfirmed, or needs re-verification, and communicate to the responsible person.
If learning ARTEX itself, limit the scope to using synthetic assets and records in a local isolated environment. Learning objectives can include verifying operational boundaries such as approval waiting, blocking out-of-scope requests, record retention/deletion, and interruption behavior. There is no need to test against actual financial institutions or customer systems for the purpose of learning its functions.
7. What Needs to Change First in Financial Sector Defense
Simply adding a specific tool’s name to a blocklist is unlikely to solve the problem. Whether used by a human or an automated tool, the server must determine if the requester is authorized to access the information. Authentication is the process of verifying who someone is, and authorization is the process of verifying if that person can use specific information or functions.
The FSC’s order to identify all external services and inspect access controls is linked to this fundamental issue. Even services used by employees or partners are subject to management if they can be accessed externally. Allowing all data queries simply because there was a legitimate login should not be done, and unnecessary response information and abnormal queries should be reviewed together. This is not an explanation that determines the ultimate cause of individual incidents but an interpretation of the public response direction from a practical perspective. FSC Response Direction
ARTEX’s open structure demonstrates that AI can connect the planning and execution of repetitive tasks. However, regardless of which specific functions were active in this incident, defense organizations must strengthen access control for external assets and their ability to observe automated requests. Organizations researching the tool internally must reduce model data and execution privileges, and verify human approval and independent isolation together. Distinguishing these two directions allows for creating necessary questions for actual preparation without exaggerating incident reports.
References and Scope of Verification
- Financial Services Commission, Announcement on Responding to Financial Sector Cyber Threats: Official basis for incident response and external system inspection.
- Seoul Economic Daily, Oct 2 Report on ARTEX Console Mark · Herald Economy, Oct 3 Report on Usage Traces: Distinguishes observations and follow-up reporting by date.
- Autumn-27/ARTEX · Releases · Fixed Commit CHANGELOG: Structure, deployment history, and context of fixes.
- Source Tree of Fixed Commit: Read-analysis of file, tool, model, approval, and record connections. Not data reproducing incident evidence.
- AGPL-3.0 LICENSE: Original text to be reviewed along with the separate usage declaration in README.
Only official data and public repositories were used. Actual internal logs, customer-attributed data, attack commands, or breach procedures were not included. Releases and the main branch were distinguished, and if the scope of tool involvement in the incident changes in subsequent investigations, this explanation should also be updated.
Leave a Reply