Tech Teardown 020｜ARTEX: Bringing Penetration Testing into Agent Workflows, Backup Repo Gains 721 Stars in One Day

TEXT>>>
On October 8th, a repository named mhtsec/ARTEX appeared on GitHub. It introduced itself as an AI autonomous penetration testing system, the champion project of the Baidu “agent+” attack and defense challenge (according to the project’s own statement). A day later, it received 721 stars. This was not just another scanner script; it was a complete multi-agent system: a Go backend with 327 source files, over 10,000 lines of agent packages, a Next.js frontend embedded as a single binary, and two images stored in PostgreSQL. What’s more interesting is the repository’s identity: the first page of README declared that this was “the last version of pure source code backup,” and the original repository was no longer accessible. This article breaks down the project into six parts: what it is, why it’s relevant now, its core mechanism, numbers and boundaries, how it runs, and value judgments.

I. What it is

Let’s start with the repository’s identity, where there’s a point that can easily be miswritten. mhtsec/ARTEX is a backup repository: README states “this repository is the last version of pure source code backup for ARTEX,” and notes that the Docker deployment source has become invalid and requires local building. The installation script in the repository still uses the clone address Autumn-27/ARTEX. This original repository has now returned a 404 on GitHub; the reason for deletion or moving to private is unknown. In other words, the project’s development history, issues, and releases remain in the original repository, and this backup is merely a frozen set of source code. The 721 stars represent the security community’s attention to the “champion project’s source code backup” within one day, not the project’s long-term reputation.

Now, let’s talk about the system itself. ARTEX is a complete engineering project that turns penetration testing into agent workflows: a Go backend with 327 .go files, including 10,391 lines of agent packages; a Next.js frontend that is statically exported and embedded as a single binary using go:embed; and a database in PostgreSQL. The core dependencies are just one line: the author’s own agent framework library norma (providing modules like agentcore, tool, permission, transcript, etc.), plus several basic libraries. The license is AGPL-3.0, but the end of README includes additional usage restrictions that are stricter than the license, which will be discussed later.

The system’s framework is multi-agent collaboration: the planner is responsible for planning, the worker for execution, and the mainagent handles human-to-agent dialogue. This collaboration is embodied in two diagrams: the asset diagram and the exploration diagram; the mechanism will be explained in the third paragraph.

II. Why it’s worth reading now

There are three reasons.

First, LLM penetration testing is a current hot topic in security competitions. “agent+” type attack and defense challenges have made it a formal subject. ARTEX’s appearance at this time as a champion project itself is a sample of the trend: competitions are forcing teams to complete agent engineering to a level where it can be used in competitions. What the champion solution looks like is worth seeing.

Second, common components for agent engineering are now mature. Event-driven scheduling, cross-conversation shared storage, tool approval gates, and evidence tracking have been developed over a year in scenarios like programming assistants and automated operations. ARTEX integrates these into a niche field. Seeing how they’re assembled and what changes have been made in security scenarios is more valuable than reading ten concept articles.

Third, it’s the final installment. We have already discussed the offensive side (poisoning models) and defensive side (weight manipulation), and this episode fills in the middle section: the attack-defense workflow itself is rewritten by the agent. Together, these three articles cover the full picture of this direction: offense, defense, and workflow.

III. Core Technical Mechanisms

The four-piece set: event-driven Planner, dual graphs with a blackboard, interception and approval, evidence chain. Let’s discuss each one.

Event-driven Planner. The comments in agent/planner.go explain its role: “Planner is the event-driven LLM planner.” It doesn’t poll; instead, it wakes up whenever the asset graph or exploration graph changes (with anti-jitteriness to avoid triggering sequential scheduling due to graph fluctuations). Upon waking, it reads the current situation and determines whether the goal has been achieved, then sends 0 to N exploration intentions to the pending queue (frontier). Two key designs worth noting: first, it is the “unique intention generator” for the entire system; workers only receive intentions, never generate them, ensuring planning authority remains centralized. Second, most times when it wakes up, it sends no intention: it remains silent unless there’s a new direction, avoiding forced tasks. Additionally, there are two callbacks, killWork and steerWork, which can terminate or change the direction of ongoing tasks mid-process. Cold nodes have a compression mechanism to control the context length of long tasks.

Shared to-do list. Each wake-up of Planner is a new session, with no state retention. However, real usage often involves multiple steps with dependencies. The output of one step becomes the input for the next, and sending them out simultaneously would cause chaos. The solution is a shared to-do list per task across wakes: Planner records a serial utilization chain once, then only sends intentions for the next step when “prerequisite steps are completed.” As facts are added, subsequent steps are gradually unlocked. In this event-driven, stateless session environment, multi-step sequences can proceed smoothly without repetition or disorder. This is key to the system’s ability to complete long processes autonomously.

Dual graphs and blackboard. “What is the goal?” and “To what extent have we achieved it?” are broken down into two graphs. The asset graph is shared globally, with nodes ranging from root domains, sub-domains to IPs, services, endpoints. Parent-child relationships and deduplication keys are calculated by the program; the agent only submits raw information without determining duplicates. The exploration graph is independent per task, with nodes being goals, intentions, facts, vulnerabilities, and hints. These are connected by edges of derivation, output, and proof, allowing visibility into which facts derive from which directions and what was produced. The two graphs are connected by anchors, enabling both viewing which assets have been touched along the exploration direction and checking which intentions have tested a specific asset. Tasks are communicated via the blackboard: subsequent tasks see only a read-only view of active data from previous tasks, and inherited vulnerability evidence is read-only and unmodifiable. States can be inherited, but contamination cannot enter.

Interception Approval. The system has set up an approval process for tool calls. Built-in rules prevent clear destructive operations: in addition to the HTTP DELETE method, a rule for “delete-like interface paths” was added to cover requests with /delete, /del, /remove, /unlink, /erase, or /destroy, requiring a separator after the verb. Methods like /delivery and /details will not be incorrectly blocked. The motivation for adding this rule is written in the update log: most applications’ deletion interfaces can be triggered using GET or POST, but only the DELETE method prevents issues. The remaining cases are left to the “model for final approval” to decide whether to allow them; the token usage for this is measured separately, with a usage card and daily bar charts for the past 30 days on the interface. Approval itself costs the model, and we show you how much it costs.

Evidence Chain. This is a testament to engineering skill. The linking of vulnerabilities and traffic is many-to-many, with each link marked with one of four purposes: baseline (normal comparison), proof (vulnerability proofing), verification (supplementary verification), and supporting (auxiliary evidence). During linking, the corresponding traffic is hashed with SHA-256 to create evidence files, and multiple vulnerabilities can share the same file. The design philosophy is stated in the document: the system does not guess links based on domain names, time, or browsing history to prevent false attribution; it prefers you to explicitly choose instead of guessing for you. Reports are generated by an independent report agent in two stages: they are automatically triggered after discoveries are stored, then checked and linked to traffic, and written according to the latest evidence version. The file is signed with an optimistic lock on the evidence_version, and if the evidence changes during generation, the old version is rejected. Version conflicts return 409, while returning 403 for inherited evidence.

On the code quality side, the update log for version 0.3.15 (October 7) contains a complete security audit record, including over a dozen fixes, one of which was rated “serious” due to a configuration merge vulnerability (credential masking could be bypassed by certain commit methods). Each issue is first reproduced, then fixed, and regression testing is performed; almost every core file in the agent package has corresponding test files. The backup repository does not mean a hasty one.

IV. Numbers and Boundaries

Full numbers: 721 stars (as of October 9, for one day); 327 .go files; 10,391 lines in the agent package; Go backend plus Next.js frontend and PostgreSQL; dependency framework norma v0.4.3; AGPL-3.0; The latest version, 0.3.15, was signed on October 7, and the repository was made public on October 8.

Four boundaries need to be mentioned.

First, the title of “Champion of Baidu Agent+ Attack and Defense Challenge” only appears in the about section of the repository; no independent reports or public lists exist to verify this. This title should be used as a self-introduction for the project, not as a report card.

Second, the meaning of the number of stars should be discounted. 721 stars for one day represent attention from the security community, not long-term usage; the original repository is now 404, so its development history cannot be compared. What this source code went through before backup is invisible to the outside world.

Thirdly, the maintainability of the single-author fixed-point archive. In the contribution list on 0.3.15, there is only one author; the README explicitly states that this is a backup of the final version. It is unlikely that further submissions to this source code will occur. Reading and using it should be done according to the expectations of the “fixed-point archive.”

Fourthly, the disclaimer is more stringent than that of conventional penetration tools. Most penetration tools’ disclaimers state “for authorized testing only.” ARTEX clearly states: Scanning, probing, exploiting, or attacking any website, online service, or networked system is strictly prohibited. The sentence in parentheses specifically adds “whether authorized or not, whether it is your own asset or not.” Even authorized online testing is banned, leaving only three options: personal learning, code research, and local isolated environment verification.

Fifthly, How to Run and Who Can Use It

Let’s first discuss how to run it within the boundaries. It depends on three things: a PostgreSQL, an LLM key (ANTHROPIC or OPENAI, which can also be configured in the interface), and a local isolated environment. There are two ways to deploy: the install script allows you to choose between compiling all Docker images or doing local compilation. The latter involves compiling a single binary with an embedded frontend using Go. After deployment, the service runs on port 8787 locally. For the first access, set the admin password. Note the special nature of the backup repository: The README describes that docker deployment sources are no longer valid. If images cannot be pulled, local construction must be used. The author even suggests “letting AI build locally for you.” In terms of ecosystem, it can synchronize assets with the author’s asset mapping tool ScopeSentry, importing by project or task.

There are three types of people who should read this: Those doing offensive and defensive engineering: The dual graph, approval gate, and evidence chain are architectural samples that can be directly referenced. Especially the last two, they can be applied in other fields. Those developing agents: Event-driven with stateless sessions and shared to-do lists is a ready-made solution for “how to steadily progress in a stateless environment.” planner.go is worth reading in its entirety. Those doing security research: The four-use binding and optimistic lock evidence chain are reference implementations for “how agent outputs can become auditable evidence.”

For those who just want to observe, the easiest entry is the online demonstration site described in the README. Click to see what the interfaces for tasks, assets, exploration process, and approval records look like, then decide whether to read the source code.

Sixthly, Value Judgment and Who It Suits

Sample value: High. It transforms “AI penetration testing” from competition news and demonstration videos into source code that can be read line by line. To judge the true completion of an agent system, I look at three aspects: whether planning power is centralized, whether execution leaves traces, and whether outputs are auditable. ARTEX provides engineering answers in all three areas: a unique intent generator, a record proxy with full traceability, and an evidence chain with hashing and version locks.

Industry value: This is a rewrite of the workflow, not a replacement of tools. A large part of penetration testing involves enumeration, trial and error, recording, and organizing, which are standard tasks. ARTEX shows a division of labor where agents handle heavy work while humans make key decisions. The approval gate prevents destructive operations, and the evidence chain allows for line-by-line review of agent conclusions. For the red team, this means increased productivity, reduced repetitive labor, and focus on areas that truly require judgment. For the blue team, it means enhanced countermeasures, with low-cost automation increasing the frequency of reconnaissance and attempts. Both offensive and defensive sides are pushed in the same direction by the same source code.

Stick it down again: It lacks third-party data, the champion is self-descriptive, and the repository is a frozen backup. Whether it’s worth the time depends on what you want to take. If you want the architecture (approval gates, evidence chain, shared tasks), it’s useful everywhere; if you want a ready-to-use penetration tool, it violates its terms and overestimates its purpose.

One-line judgment: The strength of ARTEX lies not in the champion title, but in turning “agent self-running security testing” from a slogan into an approved, evidence-based, and auditable engineering process. This direction has never lacked demonstrations, what’s lacking is this kind of auditable restraint.

Reference sources

• Repository itself: github.com/mhtsec/ARTEX (Local clone then compare README, CHANGELOG, docs/vulnerability-traffic-evidence.md, agent package source code, go.mod, git log; No build performed)
• GitHub API (721★, about description, creation date 2026-10-08)
• Original repository Autumn-27/ARTEX, API returns 404 (Deleted or moved private, reason unverified)
• 721★ stars are data from 2026-10-09, still changing