FuturPulse analysis · 15 October 2026
ARTEX says its original Docker image was removed from Docker Hub and points users to a replacement image or a local build. ARTEXX still documents the former image in its Docker Compose instructions. Both repositories describe an LLM-driven penetration-testing system, so teams should treat either project as untrusted evaluation code until they test its build process, network access, credentials and scope controls.
At a glance
- ARTEX says the former
autumn27/artexDocker image was deleted from Docker Hub. - ARTEX names
mianhuatang11/artexas its maintained replacement image. - ARTEXX still names
autumn27/artexin its Docker Compose instructions. - Both repositories describe PostgreSQL storage, LLM credentials, traffic recording and tool-approval screens.
- Both repositories document a source-build route, but a source build still needs review.
Which Artex GitHub project is the pentest tool?
ARTEX and ARTEXX describe AI-assisted penetration-testing applications. Their READMEs describe a Go backend, a Next.js interface and PostgreSQL storage. They also describe agents, tool use, traffic recording and approval or interception views.
The similar names matter because an “Artex” search can return unrelated software. ArCode, for example, is a Java program-analysis tool. Its maintainers say it analyses framework API use and recommends corrections or missing calls.
The distinction is supported by the underlying research. The ArCode paper, submitted on 16 February 2021, describes a learning-based approach for helping programmers use framework APIs. It evaluates API recommendations and misuse detection rather than penetration testing.
ArCode also has a published software record. Zenodo lists ArCode-1.2.1 as software published on 4 March 2021 and links it to the SoftwareDesignLab GitHub project. That evidence helps separate a Java development-analysis project from the ARTEX repositories discussed here.
The ARTEX repositories call the product an autonomous penetration-testing system. That phrase describes a product design, not an assurance result. A repository description cannot show that an agent will respect a target boundary when a model response, tool result or redirect points elsewhere.
Practical verdict: do not treat a dashboard, a mock demo or an approval panel as proof of containment. Verify what the program can reach, what it can retain and what happens when a request falls outside the agreed test scope.
What do ARTEX and ARTEXX say they contain?
ARTEX describes a dashboard, task list, asset views, traffic recording, agent management, LLM configuration and approval records. It also describes a traffic proxy and a human-in-the-loop conversation interface. Those features indicate that the application is designed to collect testing data and present it to an operator.
The ARTEX README describes an asset graph and an exploration graph. It presents the asset graph as a shared record of domains, subdomains, IP addresses, services and endpoints. It describes the exploration graph as task-specific evidence about goals, actions, facts and findings.
That split could help an operator distinguish a known asset from a testing claim. It also creates a data-handling question. Shared asset data can outlive one task, so evaluators should determine who can view it, how long it remains stored and whether later tasks inherit earlier information.
ARTEXX presents nearly the same interface and architecture claims. Its README lists PostgreSQL, LLM configuration, traffic recording, agent management and tool interception. The visible documentation therefore does not establish a clear operational difference in the core product design.
Neither README is an independent assessment. They are maintainers’ descriptions of the projects. A careful trial should separate repository claims from behaviour observed in a controlled environment.
What differs between ARTEX and ARTEXX?
The clearest documented difference is the Docker image reference. ARTEX says the original autumn27/artex image is unavailable. It directs users to mianhuatang11/artex or a local build from the repository’s source code.
ARTEXX’s Docker Compose instructions still say they pull autumn27/artex. That does not prove bad intent or unsafe code. It does show a deployment inconsistency that must be resolved before anyone follows that installation path.
ARTEX also labels its online demonstration as a front-end preview using mock data. That limits what the demo can establish. A mock front end cannot demonstrate the behaviour of the backend, database, proxy, approval path or external tools.
Both repositories include a source-build route. Their instructions export the web interface, copy it into the server bundle and compile a Go binary. That gives an evaluator a way to inspect repository contents, but it does not establish that dependencies, build hosts or output artifacts are trustworthy.
| Visible verification signal | ARTEX | ARTEXX | Why an evaluator should care |
|---|---|---|---|
| Current image reference is reconciled | Yes | No | An unavailable image can stop a documented deployment path. |
| Local source-build route is described | Yes | Yes | A source build gives reviewers an alternative to a prebuilt image. |
| Demo is clearly labelled as mock data | Yes | Not stated in the visible project description | A mock preview cannot establish backend behaviour. |
| Former-image failure is explicitly addressed | Yes | No | Operators need a documented response when an artifact disappears. |
| Documentation-consistency total | 4 of 4 | 1 of 4 | This is not a security score or a product benchmark. |
The table counts four visible documentation signals from ARTEX and ARTEXX. ARTEX meets 4 of 4 listed signals, while ARTEXX meets 1 of 4. The count measures documentation consistency only.
The table does not establish that ARTEX is safe. It also does not establish that ARTEXX is malicious. It identifies a narrower problem: ARTEXX retains an installation reference that ARTEX says is unavailable.
The sensible response is not to trust the replacement image automatically. Record the exact source revision, image digest and configuration before running either project. Then confirm that the image, source tree and compiled program correspond to the intended release.
How should an evaluator install either repository?
Use a disposable lab that you own. The lab should not have routes to production networks, customer environments or personal accounts. Start with a deliberately limited test target and synthetic data.
ARTEX says installation requires PostgreSQL and an LLM credential, such as an Anthropic or OpenAI key. That creates separate trust boundaries around the application host, database and model provider. Use different credentials and logs for each boundary.
The repositories describe an installation script, Docker Compose and a local source build. Scripts reduce setup work, but they also perform actions that deserve inspection. Read them before execution, especially package installation, network downloads, environment-file creation and Docker commands.
For Docker, do not assume a tag identifies fixed content. ARTEX documents named image repositories and a default tag path. Record the full image digest after pulling it, then preserve that value with the source commit and test configuration.
A local build has different risks. ARTEX’s instructions use npm ci for the web component and Go compilation for the server. Review the lockfile, package scripts, build arguments and downloaded modules before treating the output as suitable for a security test.
The ARTEX README says its Dockerfile is a multi-stage build. It describes a static web export, a Go build and a final runtime image. It also says the image includes tools such as nmap, curl, npm and vim.
That bundled-tool claim matters because it expands what a running container may be able to do. Inventory the actual image contents rather than relying only on the README. Run the container without external credentials first, then inspect its processes, open ports, mounted directories and attempted outbound connections.
ARTEXX documents a similar source-build sequence and a Docker deployment route. Its README also says the image contains common command-line tools. Apply the same review to ARTEXX even where its documentation resembles ARTEX.
What data and credentials can the system retain?
The repositories say PostgreSQL stores project data. ARTEX also documents persistent directories for skills and application data. Its update documentation says database volumes, data files and skills remain after an upgrade.
Persistence can be useful during an authorised engagement. It can also preserve target lists, traffic records, reports, session context and credentials longer than expected. Define a retention period before testing begins, then verify deletion when the test ends.
Both READMEs show a database example with sslmode set to disable. That may be workable for a local-only laboratory database on the same host. It should not be copied unchanged into a remote or shared deployment without reviewing encryption and server identity checks.
Use a database created only for the evaluation. Give the application a dedicated database account with no access to unrelated schemas. Back up only records required for review, and keep those records outside the agent’s reachable environment.
Use a separate LLM key as well. The key should have a spending limit where the provider offers one. It should not unlock production services, shared administration or unrelated projects.
ARTEX says credentials can be supplied through environment variables or entered in the interface. That makes secret handling part of the test plan. Check shell history, container inspection output, process listings, logs and browser storage for accidental exposure.
The ARTEXX README presents the same broad credential options. Its configuration section names environment variables for database and LLM settings. An evaluator should test where each option is stored and whether it appears in recoverable diagnostic data.
Can approval screens enforce pentest scope?
No visible approval screen alone proves that scope is enforced. ARTEX describes interception and approval features, including expandable approval records. They are useful review features only if the system blocks a disallowed action before a tool contacts a target.
The repository also describes a planner, workers and a main agent. It says workers can use Bash and HTTP tools through a recording proxy. Test whether every route is subject to the same target policy.
Build a written target matrix before enabling any agent. List allowed domains, IP ranges, ports, identities, test windows and prohibited actions. Name the person who can stop the test.
Then run negative tests. Ask the system to reach a blocked hostname, follow an out-of-scope redirect and use a prohibited request method. The desired outcome is a recorded denial before an outbound request reaches the target.
Do not accept a natural-language task description as the scope boundary. A model can misunderstand text, and tool output can introduce new instructions. Enforced controls should sit below the model at the network, identity and tool-execution layers.
CSO Online reported that security specialists stressed sandboxing, egress controls and monitoring after incidents involving AI systems reaching external environments. For an ARTEX trial, the practical lesson is to deny unapproved destinations by default and monitor every allowed route.
That advice does not mean an ARTEX repository caused any such incident. It sets a standard for evaluating software that can combine a language model with command execution and network access. Scope should be enforced by systems that do not depend on the model choosing the right action.
What should logging show during a trial?
Logging should show both permitted and blocked activity. Capture the person who created the task, each scope change, the model configuration, tool calls, network destinations, approval decisions and stop events. Keep logs outside the host running the agent.
ARTEX describes traffic recording, backend logs, activity streams and approval details. Those features can aid review if they are complete and resistant to alteration. Verify that failed and denied requests appear clearly, not only successful actions.
The proxy configuration deserves separate testing. ARTEX documents an application address and a traffic proxy address. Confirm that direct tool traffic cannot bypass the proxy through a different interface, DNS route, local process or container network.
Record time consistently across the host, database, proxy and log collector. That helps an investigator reconstruct cause and effect. It also shows whether an approval happened before or after a request was sent.
Test the emergency stop while workers are active. Stop the system, then check for surviving processes, queued jobs and open connections. A stop button is useful only if it ends the relevant activity and leaves usable evidence.
What should happen during updates?
ARTEX says its browser-based update flow downloads a release package, compares SHA-256 sums, runs a smoke test and stages a replacement binary. The README also says the system rolls back if a new program fails to start 3 times. These are documented maintainer claims, not independent test results.
The same documentation says an update preserves the PostgreSQL volume, data directory and skills directory. It warns that an update interrupts active tasks because the program restarts. Schedule updates only when no authorised test depends on the current process state.
ARTEX also notes that updating a binary inside a Docker deployment does not update tools bundled in the image. A later container rebuild can restore the image’s bundled version. The application binary and scanner tools can therefore drift apart.
ARTEXX includes similar update text in its README. Similar wording does not establish that the repositories ship the same code, releases or container artifacts. Test each repository and each artifact as a separate deployment.
Before an update, export the current configuration and record the running binary hash. After the update, repeat network, scope and logging tests. An update is a new security decision when it changes code, tools, dependencies or retained data.
What should an evaluation report contain?
A useful report should let another security team repeat the decision. Include the repository URL, commit identifier, image digest or build hash, deployment date, host configuration and model provider. Separate observed behaviour from the repository’s own statements.
Document the allowed target scope and every enforced control. Include the outbound firewall policy, database identity, test credentials, mounted paths and emergency-stop procedure. State where logs were stored and who could modify them.
Include negative results. Report whether the system blocked an out-of-scope destination, whether a redirect was denied and whether a restart left work running. Those tests reveal more about operational control than a long list of findings from an intentionally weak target.
Classify model-generated findings as hypotheses until a qualified reviewer reproduces them. Preserve the prompt, tool output, traffic evidence and reviewer decision. A finding without reproducible evidence should not become a customer-facing security conclusion.
What could we not verify?
The visible repository material does not establish that ARTEX or ARTEXX has completed an independent security assessment. It also does not establish signed build provenance, immutable scope enforcement or successful operation in a customer environment. Those questions require evidence beyond the READMEs.
It is not clear from the visible ARTEXX documentation whether it is an intentionally maintained fork of ARTEX. It is also not clear whether its former Docker image reference still resolves. A maintainer could clarify this with a fork statement, pinned image digests and release records.
The next useful evidence is a reproducible lab demonstration. It should show an out-of-scope request blocked before network contact, followed by a complete record of that denial in protected logs.
