GitHub Gems

ARTEX: Open-Source Autonomous Penetration Testing Powered by AI

A GitHub project page describes ARTEX, an LLM multi-agent system for autonomous penetration testing, with several installation routes and strict usage restrictions.

Screenshot preview of the ARTEX AI penetration testing system interface
Photo: GitHub

A project page on GitHub is drawing attention to ARTEX, an open-source system that uses large language model agents to carry out autonomous penetration testing, the practice of probing computer systems for security weaknesses. The repository is titled as a champion project from an attack-defence challenge linked to Baidu's agent+ programme. The page, dated 14 October 2026, sets out a detailed architecture, several installation routes and a firm set of rules on how the software may be used.

What the project is designed to do

According to the GitHub repository, ARTEX is a multi-agent system driven by large language models. Its backend is written in Go as a single program with the Next.js frontend embedded inside it, and it stores its data in PostgreSQL. The agent capabilities come from a separate software development kit named norma SDK, which provides components for the agent core, tools, permissions, memory and transcripts.

The project's main design idea is what its authors call a dual-graph architecture. Both graphs are built to help an automated system keep track of what it has already tested and what it has learned, rather than repeating the same work.

Two graphs, one shared picture

The first graph is the asset graph, which is shared across all tasks. It stores items such as root domains, subdomains, IP addresses, services, applications and endpoints, and it records which company each belongs to. The repository says the parent-child relationships between these items and the rules for removing duplicates are calculated by the program itself, so the AI agent only submits raw information.

The second graph is the exploration graph, which is separate for each task. It records the reasoning and progress of a single job, using nodes for goals, intentions, facts, findings and hints. Links between nodes show how one direction of inquiry followed from earlier facts and what it produced. Anchors connect the two graphs, so a user can see which assets a particular line of inquiry targeted, or which earlier tests were run against a given asset.

In the design described on the page, a planner reads the state of the exploration graph and decides on the next goals, adding new intentions only when there is an uncovered direction. Worker agents then take one intention each, run real tools, write their results back to the graphs and stop. The authors describe this as a loop: each change to the graph wakes the planner again, until the goal is proven.

Two ways the agents share knowledge

Workers exchange process-level observations

A useful detail in the repository is how individual workers can learn from each other. Many valuable observations, such as an unusual error message, a particular server response or a hidden parameter, appear during a worker's execution but are not always recorded as formal facts. To avoid repeated effort, the system lets a worker search the execution traces of other workers in the same task by keyword. Results show which intention they came from, and a worker can then open specific steps in full detail.

The authors note that each worker still handles only the single intention it was given. What changes is that information moves between workers at the level of their working steps, not just their final conclusions.

A shared to-do list for multi-step attacks

Real attack paths often depend on a sequence of steps, and the repository gives an example: finding an injection point, obtaining credentials, moving to another system and then escalating privileges. Dispatching all of these steps at once would make little sense. For that reason, the planner keeps a to-do list that is stored per task and carried across its repeated wake-ups, even though each wake-up starts a fresh session.

Each round, the planner only dispatches the next step once its prerequisites are complete and the facts it depends on exist. It then updates the list, marking steps as done when the facts that satisfy them appear. According to the page, this is what allows the chain to advance without repeating work or running steps out of order.

Asset sync and manual retesting

The repository also describes two practical features. The first is asset synchronisation with ScopeSentry, another security tool. Users enter the address and API key of their ScopeSentry instance, choose the targets and asset types they want, and import them in one step. The imported assets are grouped by company scope and placed in the ARTEX asset graph for the agent to explore.

The second is a manual retesting function. Users can select vulnerabilities from a task and start a new retest session without rerunning the original scan. A retest ends with one of three conclusions: still reproducible, fixed, or cannot be confirmed. The page says that if a retest session finishes with a conclusion of fixed, the system automatically changes the vulnerability status to fixed. Other outcomes leave the original status in place, and the original evidence and reports are kept.

Installation and deployment options

The installation guide lists PostgreSQL as a dependency and requires a large language model to be configured, using either an Anthropic or an OpenAI API key. Keys can be set as environment variables or entered in the web interface. The repository offers several routes:

  • A one-click install script that detects or installs Docker and then lets the user choose between a fully containerised setup or a local build.
  • Docker Compose, with a container image that already includes common tools such as nmap, curl and ripgrep.
  • Compiling a single binary from source, after building the frontend.
  • Cross-platform release archives, with the build script producing packages for Linux, macOS and Windows.

After installation, the web interface runs on port 8787, and the first visit leads to a setup page for the administrator password. The guide also explains that the system can run behind a reverse proxy, but warns that the proxy must disable buffering for its live event stream. Otherwise the browser connects but never receives updates.

Updates are handled differently depending on the installation. The page can check for and install new versions, verify them against checksums, and roll back to the previous version. The authors warn that a rollback does not undo database schema changes. In Docker setups, the guide notes that updating the program alone does not upgrade the surrounding tool images, so users must pull new images explicitly to keep those tools current.

Licence and strict usage limits

The project is released under the GNU Affero General Public License v3.0. The repository explains that anyone may use, modify and distribute the code, provided derivative works are also released under the same licence. If a modified version is offered to users over a network, its complete source code must also be made available to those users.

The authors add their own rules on top of the licence, and they are strict. The software is described as intended only for personal study, code research and local technical validation. The page explicitly forbids using the tool to scan, probe, exploit or attack any website, online service or networked system, whether or not the user has permission and whether or not the system belongs to them. Users are told they must comply with the cybersecurity, data protection and computer crime laws of their jurisdiction, and the page specifically cites China's Cybersecurity Law, Data Security Law and Personal Information Protection Law. The software is provided as is, without warranty, and the authors disclaim liability for losses that result from its use.

What readers should take from it

The repository presents ARTEX as a serious attempt to automate multi-step security testing with AI agents, and its architectural ideas, such as shared asset graphs and a persistent planning list, will interest researchers working on agent design. However, the page is written by the project's own authors. It describes features and design choices, but it does not include independent testing results, benchmark figures or a third-party assessment of how well the agents perform in practice.

For most readers, the most concrete takeaway is the set of limits the project places on itself. Its authors insist that it be used only in local, controlled environments, and they make clear that unauthorised scanning of live systems falls outside what the project permits. Anyone considering the software will need to weigh its technical ambitions against those restrictions and against the legal responsibilities the page places on users.

Source: GitHub

Comments (0)