METATRON: a two-terminal pen-testing assistant with the database password in the README

Two terminals, because the model is loaded before the CLI

The usage section is built around a constraint that is easy to miss. METATRON needs two terminal tabs to run.

The first tab loads the model.

ollama run metatron-qwen

You wait until the prompt appears, which is the signal that the model is in memory and ready, and the instructions say you can leave that terminal running in the background. The second tab runs the tool.

cd ~/METATRON
source venv/bin/activate
python metatron.py

So the AI is not started by the application. It is started by you, separately, and the application talks to the model server that is already running. That is the ordinary Ollama arrangement, and it has a practical consequence: if you close the first tab, the CLI has nothing to talk to.

The README says the 9b model needs at least 8.4 GB of RAM.

The base model comes from a personal namespace, not from Qwen

The model stack is three layers: a local model named metatron-qwen, served by Ollama, whose parameters come from a fine-tune described as Qwen 3.5.

The base model that fine-tune starts from is not an official Qwen release. It is pulled from a personal Ollama namespace.

ollama pull huihui_ai/qwen3.5-abliterated:9b

That matters more than it might appear. An official base model has a vendor, a release process and a version you can point at. A repository namespace on a model hub belongs to whoever published it, and it can change or disappear without a version note. Anyone evaluating this project for an assessment should decide deliberately whether that matters to them.

Memory is the other constraint, and it is stated precisely: the 9b model needs at least 8.4 GB of RAM. Below that the instructions point you to a 4b variant of the same repository, and then tell you to edit the FROM line in the Modelfile to point at it. So the smaller model is a one-line change to a file in the repository rather than a configuration option.

The Modelfile fixes the sampling parameters for you

The custom model is built from a Modelfile that ships in the repository.

ollama create metatron-qwen -f Modelfile

That one command produces a local model with four parameters pinned. The context window is 16,384 tokens. Temperature is 0.7. Top-k is 10 and top-p is 0.9.

Those numbers are worth reading as a design decision rather than a default. A low temperature and a narrow top-k produce more repeatable output, which is what you want when a model's job is to summarise scanner output consistently across runs. A wider context matters for the same reason: recon output from several tools concatenated is what fills the prompt.

Verification is a list command, and the check is that the new name appears in it.

ollama list

Note the naming: the repository file is the Modelfile, and the model it creates is the lowercase name. Anything you change in that file becomes a new model definition rather than an edit to the running one, so switching to the smaller base model means creating the model again.

The database password is in the setup section in plain text

The MariaDB setup creates a database, a user and a password, and all three are written out.

CREATE DATABASE metatron;
CREATE USER 'metatron'@'localhost' IDENTIFIED BY '123';
GRANT ALL PRIVILEGES ON metatron.* TO 'metatron'@'localhost';
FLUSH PRIVILEGES;
EXIT;

The password is a three character string, and the next step passes it on the command line when creating the tables, with the user, the password and the database name in one line.

That is a placeholder, and anyone who keeps it will have a database that anyone on the machine can reach. It is called out here because the instructions also say the application stores full scan history, which means the stored rows describe what you scanned and what the model found. Target addresses and vulnerability detail are exactly the kind of data you do not want readable by another local account.

The second thing to notice in that block is a formatting artefact. The CREATE TABLE statement for the history table indents its last two columns oddly, so the lines for the scan date and the status column appear misaligned compared with the first two. It is a documentation blemish rather than a bug, but it is the kind of paste that ends up copied into a console.

Five tables hang off one session number

The schema is organised around a single spine.

history              ← one row per scan session (sl_no is the spine)
    │
    ├── vulnerabilities   ← vulns found, linked by sl_no
    │       │
    │       └── fixes     ← fixes per vuln, linked by vuln_id + sl_no
    │
    ├── exploits_attempted ← exploits tried, linked by sl_no
    │
    └── summary           ← full AI analysis dump, linked by sl_no

One row in history per scan, with the session number as the key everything else joins on. Vulnerabilities link to the session, fixes link to a vulnerability and also to the session, exploits tried link to the session, and the summary table holds the model's full analysis as one row per session.

Two consequences follow. The fixes table has a redundant join key, which is duplication in a schema. And the summary table means the model's raw output is retained rather than only its extracted findings.

The repository keeps all of that database access in one module, described as the MariaDB connection and all CRUD operations, with the edit and delete capability exposed from the CLI so any saved result can be changed after the fact.

nikto is separated from the batch because it is slow

The recon menu is the part of the tool you interact with most, and one of its choices is a warning.

  [1] nmap
  [2] whois
  [3] whatweb
  [4] curl headers
  [5] dig DNS
  [6] nikto
  [a] Run all (except nikto)
  [n] Run all + nikto (slow)

Five tools are cheap enough to bundle into one batch. The sixth is not, so the interface offers both a batch without it and a batch with it, labelled slow. That is a better default than hiding it: a port scan and a DNS lookup take seconds, while a web vulnerability scan against a slow target can run for minutes, and a batch option that silently includes it would make the tool look hung.

The five other entries are deliberately coarse. curl headers rather than a full request, dig for DNS rather than a resolver library, and the same three names the installation step installs on the system.

The system packages are where the scanning actually happens.

sudo apt install nmap whois whatweb curl dnsutils nikto

So the tool is an orchestrator and an analyst. Its versions, their configuration and their output format are as much a part of the result as the model reading them.

The export module is missing from the documented structure

The README lists the project's files in a tree, and it is almost complete.

METATRON/
├── metatron.py       ← main CLI entry point
├── db.py             ← MariaDB connection and all CRUD operations
├── tools.py          ← recon tool runners (nmap, whois, etc.)
├── llm.py            ← Ollama interface and AI tool dispatch loop
├── search.py         ← DuckDuckGo web search and CVE lookup
├── Modelfile         ← custom model config for metatron-qwen

One module present in the repository is not in that list: the export module. The features section promises report export, names PDF and HTML as the two formats, and the walkthrough describes getting there through the history menu. The requirements file confirms the mechanism, since it pins a PDF generation library alongside the HTML tooling.

So the feature is documented by its output and its menu path, while the file that does the work is missing from the structure listing. It is a small documentation gap, and it is the kind you notice when you go looking for the code that writes the report.

The requirements file is worth reading for what it says about dependencies: the CLI is driven by a terminal table library, the database layer uses a MySQL connector for Python, and two different DuckDuckGo search packages are pinned side by side, along with the HTTP and parsing chain each of them needs.

Editorial conclusion

Use METATRON on a Parrot OS or Debian-based machine where you can run a 9b parameter local model, you are authorized to test the target, and you want scan history in a database you control rather than in a cloud service. Check four things before a real assessment. The base model is pulled from a third-party namespace (huihui_ai), not an official Qwen release, so know what you are loading into memory. The database credentials in the setup steps are a placeholder that you must change. The system packages are installed from your distribution and are the actual scanners, so their versions and their configuration are part of your result. And the export module is documented only by its output formats, so read the code before trusting a report. Legal use is limited to systems you own or have written permission for.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. sooryathejas/METATRON on GitHub