Six recon tools feed one local language model
METATRON wraps 6 familiar commands: nmap, whois, whatweb, curl, dig, and nikto. A user supplies an IP address or domain, chooses tools, and receives the combined output. The program sends that text to a local metatron-qwen model through Ollama. It parses the response into vulnerabilities, fixes, exploit suggestions, a risk rating, and a summary. Results go into MariaDB and can later be exported as PDF or HTML.
The model can ask for as many as 9 additional tool rounds by returning [TOOL:] or [SEARCH:] tags. METATRON extracts the text inside those tags, executes allowed commands, compresses long output with the same model, and feeds it into the next round. That loop is the interesting part of the project. It is also the risky part because scan responses are untrusted input, the model writes command arguments, and the program may act on those arguments before a person reviews them.
The 8.4 GB model sits beside a manual database setup
The README targets Parrot OS and names 8.4 GB of RAM as the minimum for its 9b Qwen-based model. Lower-memory users are told to pull a 4b variant and edit the Modelfile. Ollama runs in one terminal while METATRON runs in another. Python installation is only one layer: nmap, whois, whatweb, curl, dig, and nikto must also exist on the host. There is no Dockerfile in the measured repository to package those pieces together.
MariaDB setup requires copying SQL for 5 related tables. Both db.py and export.py connect to localhost with user metatron, password 123, and database metatron. That fixed local credential makes the tutorial easy to follow but is a poor default on a shared system. Configuration is not read from environment variables. An operator who wants another host, socket, user, or password must edit source, and the generated scan history may contain sensitive network details and model-suggested payloads.
What happened when we ran it
Our sandbox installed commit 9dd2ee3 in 50 seconds, adding 49 Python packages and using 187 MB on disk. The build completed successfully in 6 seconds. The repository itself contained 17 files, roughly 2,021 lines of source, and occupied 2.4 MB before installation. These results cover package resolution and the build step in a fresh Python 3.12 Debian container. We did not supply a target, start Ollama, download model weights, or create the MariaDB schema.
The harness found no tests script or target, so tests were skipped. The checkout also had no tests directory and 0 CI workflow files. Pip-audit reported 30 known vulnerabilities in the installed dependency set. The measurement does not identify their severity, reachability, or fixes, so we will not guess. Even without that detail, 30 advisories plus no automated suite is a poor foundation for software that runs network commands and stores security conclusions. A successful 6-second build offers little assurance about those behaviors.
Two open reports show the model can leave its target
Issue 32 explains that the executable allowlist does not restrict the remaining command arguments. Current tools.py confirms the narrow guard: it accepts 6 binary names, splits the model-produced string, and passes every accepted argument to subprocess.run. Reconnaissance output can contain text controlled by the scanned service, and the model can turn that text into another [TOOL:] command. Nothing in the default branch checks that a new hostname or IP still matches the target the operator authorized.
Issue 33 covers a separate redirect path. METATRON's header check calls curl with --location for HTTP and HTTPS, so the scanned server can redirect the request to a different host. The report describes a local proof that reached a loopback service and returned an internal header. Open pull request 34 adds host checks for both problems, but it was still unmerged when we fetched the default branch. Until that changes, isolation and outbound network controls are more important than the Python allowlist.
One Log4j report shows why evidence must stay attached
Issue 28 gives a concrete accuracy warning. A user received a report claiming Log4j remote code execution on port 80 and describing the result as successful. Other scanners did not confirm the finding, so the user asked METATRON to record the commands and payloads supporting each conclusion. A polished severity label and named CVE can outrun the available evidence when the local model fills gaps.
The source contains prompt rules against guessed versions and unsupported CVEs, but prompt instructions are not enforcement. Stored records separate parsed vulnerabilities, fixes, exploits, and summaries across 5 tables without a strict evidence object linking each claim to a command and raw output line. For an educational lab, a human can inspect the raw scan and correct the database. A professional report needs a stronger rule: no vulnerability or successful exploit status without machine-captured evidence that another tester can reproduce.
April code and September reports show attention without resolution
GitHub recorded METATRON's last default-branch push on April 11, 2026. The repository had 3,947 stars and 18 combined issues and pull requests when fetched. Issue and pull-request discussion continued into September, including the target-scope report, the redirect report, and proposed fixes. That pattern does not support calling the project abandoned. It does mean the security work visible in September had not reached the branch or a tagged GitHub release, because the latest-release endpoint returned none.
METATRON earns attention for making its 2,021-line agent loop easy to inspect and for keeping the model local. The 30 known vulnerabilities, absent tests, fixed database password, evidence gap, and unmerged scope fixes rule out a serious deployment today. Run it only in a constrained practice network, verify every finding with the underlying scanner, and keep the model's commands inside a boundary it cannot rewrite.