Run an autonomous AI pentest in your own lab: a hands-on guide to ARTEX

Penetration testing is expensive, scarce, and — for most teams — something that happens once a year, if that. A new open-source project asks a provocative question: what if an AI could carry a pentest from reconnaissance to report on its own? ARTEX Global Edition is exactly that — an autonomous, LLM-driven penetration-testing system (around 1,560 GitHub stars in its first two weeks) that breaks a goal into tasks, runs real tools, and accumulates findings into a graph. This guide deploys it with Docker Compose, clears the first-run setup, aims it at a deliberately vulnerable target in your own lab, and shows you the defender-side material it ships with — with the legal lines drawn in permanent marker.

• What: ARTEX Global Edition — an autonomous penetration-testing system driven by LLM multi-agents (Go backend, Next.js frontend, PostgreSQL store).
• Who: jiwoochris/artex-global — a localized fork of the Chinese upstream Autumn-27/ARTEX (AGPL-3.0); the upstream repository was unreachable as of October 2026.
• Traction: created October 3, 2026; around 1,560 GitHub stars within its first two weeks (checked October 16, 2026).
• Deploy: one Docker Compose stack; UI at http://localhost:8787; image ghcr.io/jiwoochris/artex-global; first run requires a setup token from the startup log.
• Brain: needs an LLM — ANTHROPIC_API_KEY or OPENAI_API_KEY (env or UI); default model claude-opus-4-8; three worker agents per task by default.
• Legal line: only targets you own or have explicit written authorization for; unauthorized scanning or intrusion is a crime.

Authorized use only. ARTEX is an autonomous offensive tool — it can carry an attack from reconnaissance to exfiltration with little human involvement. Run it only against systems you own or have explicit written authorization for: deliberately vulnerable targets such as OWASP Juice Shop or DVWA, in a locally isolated environment. Unauthorized scanning, probing, or intrusion is a crime on its own. This guide is written from the defender’s point of view: understand the attack so you can detect and block it.

What you’ll need

• A machine with Docker and Docker Compose installed — that’s the only hard requirement. PostgreSQL comes up with the stack.
• An LLM API key — Anthropic or OpenAI. The README is explicit: exploration requires an LLM; you can set the key in .env or later in the UI.
• A browser, and about 20 minutes.

What you are deploying: a single Go binary (with the Next.js frontend embedded) plus PostgreSQL, from the image ghcr.io/jiwoochris/artex-global. The image bundles common tools — ripgrep, curl, vim, npm, nmap — and the ./skills and ./data directories are bind-mounted so they survive container recreation.

Step 1: Clone and configure

Grab the repository and copy the example environment file. The one variable you must set is POSTGRES_PASSWORD; the LLM key is optional here (you can add it in the UI later).

git clone https://github.com/jiwoochris/artex-global.git
cd artex-global
cp .env.example .env          # set POSTGRES_PASSWORD; ANTHROPIC_API_KEY is optional
# Edit .env with your editor: POSTGRES_PASSWORD=

Pin a release instead of floating on latest with ARTEX_TAG in .env if you want reproducible runs.

Step 2: Bring up the stack

docker compose up -d          # brings up the artex image + postgres together
# → open http://localhost:8787

Both the frontend and the API live on the same backend port, :8787, and by default it binds 127.0.0.1 only — loopback, not your LAN. That’s a deliberate first-run protection (more in Step 3). If you ever need it reachable from other machines, pass -addr :8787 or set ARTEX_BIND=0.0.0.0 — but finish the initial setup first.

Step 3: Clear the first-run setup

The first time you visit http://localhost:8787, you land on /setup, which asks you to create the single admin account (ARTEX). To stop whoever reaches an uninitialized instance first from claiming it, the page also demands a setup token that the server printed once at startup:

docker compose logs artex | grep -F '[auth]'
# copy the Setup token, paste it at /setup, set your admin password

For unattended deployments you can pin it with ARTEX_SETUP_TOKEN or set the password directly with ARTEX_ADMIN_PASSWORD (8+ characters). Changing the password invalidates every existing session within seconds — the token signing key is bound to the password hash.

Step 4: Put a deliberately vulnerable target in your own lab

ARTEX may only ever be aimed at systems you own. The right playground is a deliberately vulnerable app, run locally. OWASP Juice Shop fits — it’s the example the README itself names, alongside DVWA:

docker run -d --name juice-shop -p 3000:3000 bkimminich/juice-shop
# → your target: http://localhost:3000 (your machine, your container)

Keep everything on loopback. Juice Shop on localhost:3000 and ARTEX on localhost:8787 are both invisible to the internet — which is exactly where this kind of tool belongs.

Step 5: Run an autonomous task

In the ARTEX UI, create a new task pointed at your lab target (http://localhost:3000). If you skipped the API key in .env, add it now in the LLM settings — remember the OpenAI pitfall the README warns about: OpenAI-family models cap response tokens at 16,384, while the OpenAI-compatible path defaults to a 32,768 output cap that makes every call fail with 400 (max_tokens is too large). Set that profile’s max_tokens to 16,384 or lower on the LLM settings page; Anthropic-family models (including the default claude-opus-4-8) allow 32,768 and don’t hit this.

Then watch the closed loop work. The architecture the README documents:

• A planner breaks the goal into a shared to-do list across multiple rounds, keeping a stable attack chain.
• Worker agents (three per task by default, adjustable under System settings) execute real tools against the target.
• Everything discovered — assets and vulnerabilities — accumulates into a dual graph: an exploration graph plus an asset graph.
• A reporter turns it into findings, summaries, and chat replies in your selected display language.

The live activity stream is same-origin SSE, so what you see in the browser is the agents’ actual progress. A Juice Shop run will surface its classic issues — the point isn’t the specific findings (they’re famous), it’s watching an autonomous loop discover them.

Step 6: Read the report — then study the defense material

The report language follows the display language you pick in Settings — English (default), Korean, Chinese, Spanish, or Japanese — while the agents’ internal reasoning prompts stay in the original language to preserve performance. Expect fidelity to track model capability: in the project’s own validation, a frontier model kept output in the selected language across all roles, while a cheaper small model let reports fall back.

This is where ARTEX earns its keep for defenders. The repository ships the attack mirrored into defense:

• Defense & Detection Guide (docs/defense-en.md) — how autonomous AI attacks differ from classic scanners, the fingerprints they leave, hardening checklists, and incident-response notes.
• Deployable rules (detections/) — Sigma rules (host/log/SIEM layer, convertible for Splunk and Elasticsearch with sigma convert) and Suricata rules for the network layer.
• MITRE ATT&CK coverage layer (detections/attack/) — a Navigator JSON mapping each rule to the techniques it tags.
• Machine-readable indicators (detections/indicators/) — artex_indicators.csv plus a ready-to-import MISP event, droppable into a SIEM lookup table.

Import the Sigma rules into your SIEM and the Suricata rules onto your sensor: you’ll be detecting the exact class of autonomous-agent traffic you just generated in your lab.

What you built

A self-contained autonomous pentest lab on one machine: ARTEX’s Go + Next.js stack in Docker with PostgreSQL, a single admin account behind a setup token, a deliberately vulnerable Juice Shop target on loopback, and an LLM-brained agent loop — planner, workers, reporter — that runs a real task end to end and reports in your language. Plus the part that outlives the demo: deployable detection rules for the exact agent behavior you just watched.

Honest limitations

• Autonomous doesn’t mean reliable. It needs a capable frontier model; the project’s own validation shows cheaper small models degrade output quality and language fidelity. And every task is many LLM turns — the API bill is real.
• It’s an offensive tool. The README itself reports that the upstream was implicated in personal-data breaches targeting Korean financial institutions in October 2026, with investigations ongoing. The legal line is absolute: authorized environments only.
• Brand new. This global edition was created October 3, 2026; the upstream is Chinese-only and currently unreachable. Long-term maintenance, release cadence, and code review are all unproven.
• Agents miss things. An autonomous loop can overlook vulnerabilities a human tester would catch, and its findings need human review. It doesn’t replace a real pentest — it’s a lab for understanding how AI-driven attacks behave.
• Language fidelity is model-dependent. Reasoning stays in the original language; only user-facing output is forced into your selected language, and how well that holds depends on the model.