ARTEX: The Pentest Brain That Plans, Remembers, and Asks Permission
An open-source autonomous security system that turns reconnaissance, reasoning, and execution into a graph-driven workflow with human approval at the edge.
ARTEX was originally designed for the purpose of learning and research. It aims to help enterprises and organizations conduct security risk tests within the scope of authorized assets and improve security protection capabilities.
- ARTEX stands out because it treats pentesting as a memory-rich planning problem, not a sequence of disconnected tools.
- Its Planner, Worker, and approval gate separate strategy from execution and keep humans in the loop when actions matter.
- The exploration graph gives findings lineage, so the system can explain what it learned and why a result exists.
- Context compaction lets ARTEX preserve useful history without drowning the model in its own logs.
Most pentest tools are built around commands. ARTEX is built around state. The difference matters because once a security workflow gets long, the hard problem is no longer running nmap or launching a check. It is remembering what was learned, deciding what to do next, and keeping custody over every action.
Why ARTEX Feels Like a Pentest Operating System
ARTEX is easiest to understand as a control plane for security work. The Main Agent handles steering, the Planner turns graph state into intents, and the Worker executes one task at a time. That structure makes the project feel less like a chatbot bolted onto Kali and more like an operating model for autonomous red teaming.
That loop is the real novelty. ARTEX is not trying to replace the operator, and it is not pretending the model can safely freewheel forever. It is organizing autonomy around custody, so every action has a place in the plan and every finding has a traceable source.
The Planner, the Worker, and the Human in the Loop
The agent architecture is deliberately narrow. The Planner decides what matters next based on the graph. The Worker does the work. The human gate decides whether a tool action should proceed, be denied, or be steered midstream. That separation is what makes ARTEX feel credible instead of theatrical.
Human chat -> Main Agent -> Planner -> Intent queue -> Worker -> Tools
^ |
| v
Exploration graph <--- Facts and assets
^
|
Compactor / digest
Human approval can intercept worker actions before execution.This is also where the project moves past typical agent demos. A lot of autonomous systems can generate plans. Far fewer can maintain a persistent queue of intents, claim one task at a time, and let a human interrupt the execution path without collapsing the whole run.
Why the Exploration Graph Matters More Than the Shell
The graph is the memory model. ARTEX records hosts, ports, services, facts, and findings as linked nodes, then tracks lineage so the system can say where a conclusion came from. That matters because pentesting is full of partial truths, and partial truths become dangerous the moment their provenance gets lost.
| Dimension | Linear tool workflow | ARTEX graph workflow |
|---|---|---|
| Primary unit | Command | Intent and fact |
| Memory | Terminal scrollback | Lineage-rich graph |
| Decision style | Operator driven | Planner driven |
| Traceability | Manual notes | Ownership and parent links |
| Long runs | Context drifts | Context is compacted and preserved |
| Best fit | Single-task checks | Multi-step autonomous exploration |
That compaction step solves a practical problem. Security work generates too much state for raw prompts to carry forever. ARTEX trims the noise, keeps the lineage, and feeds the Planner enough structure to keep moving without losing the plot.
What the Self-Updating Lifecycle Says About the Project
ARTEX is designed to run like software that expects to survive contact with reality. The bootstrap and rollback logic are not decorative. They suggest an intent to support durable, unattended operation, which is exactly what you would want from a system that may spend hours exploring a target environment.
That production-mindedness changes how the project reads. It is not only an experiment in agent design. It is an attempt to make autonomous security work behave like infrastructure, with state transitions, recovery paths, and a stable record of what happened.
In view of the reality of tool abuse, the ARTEX project will no longer be updated and will be converted to a closed source. There will be no release of any version or maintenance support in the future.
ARTEX vs the Rest of the Landscape
ARTEX sits between classic tooling and autonomous exposure platforms. It is more structured than a shell-driven toolkit, more transparent than a black-box SaaS product, and more security-specific than a general multi-agent framework. That middle ground is the point.
| Project | Primary purpose | Autonomy | State model | Human oversight | Best fit |
|---|---|---|---|---|---|
| Nmap / Metasploit | Manual scanning and exploitation | Low | Session or command based | Operator controlled | Targeted checks and hands-on work |
| Sliver | Command and control and post-exploitation | Medium | Implant and operator state | Operator controlled | Red team operations |
| Pentera | Autonomous exposure validation | High | Commercial workflow state | Guided oversight | Enterprise validation at scale |
| XBOW | Autonomous pentesting platform | High | SaaS task orchestration | Platform governed | Cloud-first bug finding |
| MetaGPT | General multi-agent orchestration | Variable | Conversation and task state | Depends on implementation | Broad software workflows |
| ARTEX | Autonomous penetration testing system | High | Graph-backed intent lineage | Human-in-the-loop | Security exploration with traceable custody |
If classic tools are the arms, ARTEX is trying to be the brain. It does not just run checks. It decides what checks matter next, preserves the evidence chain, and pauses when the action should be reviewed by a person.