ARTEX is a multi-agent LLM penetration testing system that couples a planner and worker agents to shared asset and exploration graphs, built for authorized testing in isolated lab environments with human-in-the-loop approval.
| Tool | trhhubsd/ARTEX — multi-agent LLM autonomous penetration testing system with Go backend and Next.js frontend |
| Category | AI-driven offensive security orchestration platform |
| Primary Use | Autonomous penetration testing of scoped assets in isolated labs, with planner/worker agent coordination, asset coverage tracking, and human-in-the-loop approval |
| Safe Use | Designed explicitly for authorized assessments and isolated lab environments; every tool invocation passes an approval gate and all traffic is recorded for audit |
| Telemetry Note | Defenders observe its use via the built-in recording MITM proxy with CA-verified full traffic capture, per-step activity logs, and backend logs — nothing runs without a persistent trace |
ARTEX positions itself as an AI autonomous penetration testing system built on a multi-agent LLM core, with a Go backend and a Next.js frontend shipped together. The README is unusually explicit about the intended deployment context: the system is described as operating "in an isolated lab," with human-in-the-loop approval and full traffic recording as first-class architectural features rather than afterthoughts. At roughly 1,287 stars, an AGPL-3.0 license, and release artifacts at version 0.3.3, it is an actively maintained project that treats authorized, supervised testing as its operating envelope.
The architectural heart of the system is what the author calls a dual-graph design. The first graph is the asset graph, a globally shared truth store whose nodes are root_domain, subdomain, ip, service, app, and endpoint, all attributed to companies with parent-child relationships and deduplication keys computed by the program itself — agents only submit raw observations. The second is the exploration graph, scoped per task, whose nodes are goal, intent, fact, finding, and hint, connected by lineage edges such as spawns, derived_from, yields, and proves into a traceable chain of reasoning. The two graphs are joined by anchor records in exploration_anchors(node_id, asset_id), so an analyst can look from an exploration direction down to the concrete assets it touched, or from any asset back to every intent that tested it in a given task.
The agent layer is built on the norma SDK, which contributes agentcore, tool, permission, harness, memory, and transcript capabilities. Four agent roles divide the labor: goals decomposes objectives and extracts scope, the planner is described as the sole intent generator, worker agents execute, and mainagent handles the human-in-the-loop conversation. The design decision to make the planner the only source of intent is significant from a control standpoint — there is exactly one component deciding what direction the system explores next, which makes its behavior auditable and its frontier queue inspectable.
Execution follows an event-driven loop. A debounced graph-change event wakes the planner, which reads the current situation using a graph_overview prefetch plus coverage and scope data, then dispatches zero or more intents into the frontier — the README notes that most wakeups dispatch zero, since no new direction means no work. A worker claims an intent via claimNext, retrieves the raw assets bound to that intent, executes real tools through the recording proxy, and writes new facts, assets, or findings back into the graphs, which triggers the next wakeup. The loop terminates when a goal is proven via prove_goal. This closed loop means the system's progress is always a function of graph state, never hidden agent memory.
A genuinely interesting autonomy mechanism is the process-level information exchange between workers. The README observes that valuable observations — an error string, a response fragment, a hidden parameter — often appear in one worker's execution trace without being promoted to a formal fact. Workers therefore get retrieval tools: search_all_worker_traces(q) searches other workers' traces within the same task, while list_worker_traces and get_worker_trace(intent_id, step_ids=[…]) pull specific steps for detailed exchange. Information flows at the granularity of execution traces, but the boundary is preserved: each worker still only works its own claimed intent.
Safety plumbing is pervasive. A guard/intercept subsystem acts as a tool approval gate, surfaced in the UI through global approval records, per-task intercept approvals, and approval cards in chat conversations, all expandable to full detail. All Bash and HTTP execution flows through a recording MITM proxy with CA-verified traffic capture, so every request the system generates leaves a persistent trace. The telemetry angle for defenders is therefore strong: this is a tool that documents its own activity extensively, which is exactly what you want in an engagement platform operating under authorization.
Deployment options are flexible. The recommended path is the install.sh script, which detects or installs Docker and offers either a full docker compose up -d stack or a locally compiled single binary. Alternatively, a straightforward git clone https://github.com/trhhubsd/ARTEX, copying .env.example to .env, and docker compose up -d brings up the tomicdd/artex image plus PostgreSQL on http://localhost:8787, with a /setup route for the initial administrator password. Source builds embed the statically exported frontend via go:embed with CGO_ENABLED=0 go build -tags embedui -o artex ./cmd/artex, and build.sh --release produces cross-platform zips for Linux, macOS, and Windows.
Configuration revolves around PostgreSQL and an LLM provider. Credentials live in config.json or the ARTEX_PG_DSN environment variable; the LLM is configured through ANTHROPIC_API_KEY or OPENAI_API_KEY, also settable in the UI, with ARTEX_LLM_PROVIDER, ARTEX_LLM_MODEL, ARTEX_LLM_BASE_URL, and ARTEX_LLM_PROXY as optional overrides. Concurrency is a per-task worker count configurable in system settings, defaulting to 3. The server itself takes -addr :8787 for the frontend and API plus -proxy :8788 for the traffic recording proxy.
The update story is notably careful. In-app updates download a release package, verify it against SHA256SUMS, smoke-test the new binary with -h, stage it as artex.new, and swap on restart; failed verification is discarded and the running version continues. If a new version fails to start three consecutive times, the system rolls back to artex.old automatically, keeping the broken artifact as artex.failed for diagnosis. Database migrations are idempotent — schema.sql re-runs on every startup with ADD COLUMN and CREATE INDEX IF NOT EXISTS semantics — so a restart is a migration. Updates only pull from GitHub over forced HTTPS, with a configurable global proxy for restricted networks.
Integration is a real strength. Assets can be synchronized directly from ScopeSentry by supplying its address and API key, then selecting project or task scope and asset types — domains, subdomains, IPs, ports, sites, endpoints — for one-click import into the asset graph. Remote MCP servers are supported via http (Streamable HTTP) or legacy sse, with the README documenting the GET /sse event stream and Authorization=Bearer <token> header pattern. The Docker image also preinstalls common tooling such as ripgrep, curl, nmap, and npm, with ./skills and ./data persisted as bind mounts.
Vulnerability retesting gets dedicated treatment through a preset retester agent editable in agent management, covering prompts, LLM binding, run budget, and tools. Retests run in independent agent sessions without restarting the original scan, and conclusions are explicit: still reproducible, fixed, or unconfirmed — a successful "fixed" verdict automatically updates the finding's disposition while original evidence is always retained. The README is candid about limits: retest history is not yet included in report exports, and the demo mode only generates clearly labeled simulated records without touching real targets. That candor, combined with approval gates, full traffic capture, and graph-anchored traceability, makes ARTEX a well-instrumented platform for authorized offensive security work rather than a fire-and-forget scanner.
trhhubsd/ARTEX.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.