ARTEX is limited to isolated local research
ARTEX calls itself an autonomous penetration-testing system, but its usage terms set a smaller boundary. The README permits source study and technical validation in an isolated local environment. It forbids scanning, probing, exploitation, or attacks against any online or networked system, even when the operator owns it or has authorization. That rules out client work and internal assessments.
Inside that boundary, a planner creates intentions, workers execute one intention at a time, and a human can approve intercepted commands. The interface records tasks, assets, findings, traffic, token use, and activity. The default is 3 workers per task. PostgreSQL stores the results, and the Go backend embeds a static Next.js interface.
Two graphs keep assets separate from the reasoning trail
ARTEX stores targets in a shared asset graph and each task's reasoning in an exploration graph. Asset nodes cover domains, IP addresses, services, applications, and endpoints. Exploration nodes represent goals, intentions, facts, findings, and hints. Anchors join the two, showing which task tested an asset and which evidence led to a finding.
The planner wakes when the graph changes and keeps a task-level to-do list across fresh sessions. Workers can search one another's traces before repeating an action. ARTEX also has a recording proxy, command approvals, reports, skills, memory, and remote MCP connections over Streamable HTTP or older SSE. It is closer to a security operations application than a single prompt loop.
What happened when we ran it
Our sandbox cloned commit d003372 with 598 files, about 151,519 lines of source, and a 12.5 MB checkout. Installing its Go dependencies succeeded in 35 seconds and brought in 184 packages. The build also succeeded, taking 66 seconds. We ran this in an unprivileged golang:1.24-bookworm container with 3 CPUs, 8 GB of RAM, and no secrets.
The test command failed with exit code 1 after 99 seconds. The harness summary recorded 28 passed and 3 failed out of 31. The final log lines named seven failing server tests: status-change suppression, the test-message endpoint, delivery history and retry, metadata and settings round-trip, public-base-URL deep links, missing-base-URL behavior, and digest segmentation. The server package failed, while sidequestion and traffic finished successfully. The log tail does not establish why those notification tests failed.
The repository has 1 CI workflow, a Dockerfile, and a Compose file, but no directory named tests. Go tests commonly sit beside source files, so that layout does not measure quality. The useful result is that commit d003372 failed its complete test step in our fresh container. Reproduce the named notification cases before relying on alerts.
Setup needs PostgreSQL, an LLM, and an isolated network
The shortest documented route is install.sh, which can select a full Docker deployment or a local build. Manual Compose setup needs a PostgreSQL password and may take an Anthropic key. OpenAI credentials and compatible base URLs are also supported, and model details can be entered in the interface. The application listens on port 8787, sends the first browser visit to /setup for an administrator password, and can run its traffic proxy on port 8788.
Source builds compile the web interface first, copy its static output into the Go embed directory, and then build with the embedui tag. Prebuilt archives use start.sh or start.bat as a supervisor for the in-app updater. Version v0.3.14 was published on September 24, 2026. The README warns that a binary-only update does not refresh the security tools in a Docker image and that updating interrupts active tasks.
AGPL-3.0 requires a modified network service to provide its corresponding source to users, according to the README. A hosted fork needs a source-distribution process and license review. PostgreSQL data, local files, and skills persist across upgrades. Back up both the database and data directory because schema changes do not roll back with the binary.
Open issue 153 shows why scope needs an external guard
A September 20 report describes ARTEX moving outside a supplied list of 60 IP addresses. According to issue 153, agents derived root domains from certificates and pages, automatically added those domains to task scope, enumerated subdomains, and continued testing the resulting assets. The issue calls that expansion outside explicit authorization. This is one report, yet it concerns the control that matters most in any autonomous security tool: where activity is allowed to go.
Keep the lab behind firewall rules that cannot reach anything else, use disposable credentials, and review command approvals. Open issue 164 asks for clearer retry and allow-or-block behavior when command interception errors. Neither report proves every run crosses scope, but both support placing the effective boundary outside the agent process.
October activity shows speed, while English support remains absent
GitHub showed 1,465 stars, 39 open issues, and 2 open pull requests on October 3, 2026. The repository was pushed that day, nine days after v0.3.14. Issue traffic continued through October 2, and September releases were frequent. This is active development, even though the current version number, failing test step, and open operational requests point to an early product.
The documentation is detailed if you read Chinese. It covers five installation paths, proxy behavior, updates, database configuration, architecture, and license limits. The root listing has one README.md, and docs/ contains one Chinese-named document about vulnerability traffic evidence. There is no English README or English documentation file in those locations. English-only teams would be translating safety rules and deployment instructions, which is a poor place to accept ambiguity.