METATRON: a local-LLM pentest assistant wired to nmap, nikto and MariaDB
AI-powered penetration testing assistant using local LLM on linux (Parrot OS)
At a glance
- What is it?
- METATRON is a Python CLI that runs recon tools against a target, pipes the raw output into a locally hosted Qwen variant through Ollama, and stores the model's vulnerability analysis in MariaDB. It is a single-operator tool with a two-terminal setup, and its usefulness depends heavily on the quality of the model you build.
- Who is it for?
- Adopt METATRON if you are a single operator on Parrot OS or another Debian derivative, you already have 8.4 GB or more of RAM to spare for the 9b model, and you want a local record of recon output plus model commentary without sending target data to a hosted API.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 158 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap METATRON fills: recon output that nobody reads
A typical manual engagement produces a directory of text files: an nmap service scan, a whois record, whatweb fingerprints, HTTP headers from curl, dig answers, and a nikto report. The tools are fast. The reading is not. METATRON's premise is that a local model can do the first pass over that pile and return a structured list of suspected vulnerabilities, suggested exploits, and fixes, which is then written into MariaDB so the operator can revisit it later. The README states the tool runs entirely on the local machine with no cloud, no API keys and no subscriptions, and the target audience is implicit in the OS badge: Parrot OS, a Debian-based distribution aimed at security work. Anyone running Parrot or Kali on a laptop with enough RAM is the intended user. A team running a commercial scanning platform is not.
How a scan actually flows through the tool
The README describes a linear pipeline. You choose New Scan from the menu, enter an IP or domain, and METATRON invokes nmap, whois, whatweb, curl for headers, dig for DNS, and nikto. Those results are concatenated and handed to the model running under Ollama. The model returns an analysis, and the tool writes to five linked tables: history holds the target and scan date, vulnerabilities holds the individual findings with severity, port and service, fixes holds remediation text with a source field, exploits_attempted holds exploit name, tool, payload and result, and summary holds the raw scan alongside the ai_analysis and a risk_level. The foreign keys all point back to history.sl_no, so a single scan is the unit of record. The README also mentions an agentic loop in which the AI can request more tool runs mid-analysis. That is the most interesting design element and the least documented: the README does not say which tools the model may request, how many iterations are permitted, or whether the operator approves each request. Treat that loop as unverified until you read the source.
Setup: two terminals, one Modelfile, five tables
Installation follows the README closely. Clone the repository, create a virtual environment with python3 -m venv venv and source venv/bin/activate, then pip install -r requirements.txt. System tools come from sudo apt install nmap whois whatweb curl dnsutils nikto. The AI side needs Ollama, installed with curl -fsSL https://ollama.com/install.sh | sh, then ollama pull huihui_ai/qwen3.5-abliterated:9b. The README warns this model needs at least 8.4 GB of RAM and points smaller machines at the 4b variant, which requires editing the FROM line in the Modelfile. You then run ollama create metatron-qwen -f Modelfile and confirm with ollama list. The Modelfile sets a 16,384 token context window, temperature 0.7, top-k 10 and top-p 0.9. Database setup is manual SQL: start MariaDB with sudo systemctl start mariadb, create the metatron database and a user metatron with password 123, then paste five CREATE TABLE statements. At runtime you need two tabs, one running ollama run metatron-qwen and waiting for the >>> prompt, the other running python metatron.py from the project directory with the venv active. The default password 123 is in the README; change it before the database listens on anything but localhost.
The abliterated base model is the weakest link
METATRON does not ship a model. It ships a Modelfile that layers sampling parameters on top of huihui_ai/qwen3.5-abliterated:9b, a community model whose name indicates refusal behaviour has been removed. That choice is deliberate for a pentest assistant, since a safety-tuned model will decline to discuss exploit payloads. The cost is that you are trusting an unaffiliated fine-tune to produce accurate technical output about CVE details and service versions, and the README offers no evaluation, no benchmark, and no accuracy claim. Nothing in the repository verifies that the model's vulnerability identifications are correct. A hallucinated CVE number written into the vulnerabilities table looks exactly like a real one. If you use this in a report, every finding the model produces needs manual confirmation against the raw scan text stored in summary.raw_scan. That is the workflow the schema supports, and it is the workflow you should follow.
Single-user by design, and the schema shows it
There is no user table, no session table, no role column and no audit trail beyond scan_date and the generated_at timestamp. The database credentials are a single metatron user with full privileges on one schema. Two operators running METATRON against the same MariaDB instance would share one history list with no way to attribute a scan to a person. The CLI is interactive and menu-driven, so there is no headless mode described in the README, no scheduling, and no way to queue scans. For a solo consultant keeping a local record, that is fine. For anything resembling a team workflow, the five-table schema is the wrong shape, and retrofitting ownership would mean altering history and every table with a foreign key to it. The export feature, reached through option 2 (view history), select slno, then export, produces PDF or HTML reports, but the README does not describe a template, branding options, or whether the report includes the raw scan or only the model's summary.
Where a plain script or a hosted scanner fits better
The honest alternative for the recon half is a shell script or a Makefile that runs nmap, whois, whatweb, dig and nikto and writes to timestamped files. That gives you the same raw data with no RAM requirement, no model to build, and no database to maintain, and the output is diffable between scans. The honest alternative for the analysis half is a hosted scanner with a curated vulnerability database, which trades the offline guarantee for findings that are versioned and reproducible. METATRON sits between them: it adds model commentary and a queryable history, and it gives up reproducibility, because the same scan run twice can produce different analysis at temperature 0.7. If your requirement is a defensible finding, a deterministic scanner wins. If your requirement is a first pass that costs nothing per scan and never leaves the machine, METATRON's approach is coherent.
Maintenance load and the MIT licence
The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That covers the Python code and the Modelfile. It does not cover the base model weights, which come from a separate Ollama registry entry with its own terms, and the README does not restate them. Check those terms before shipping anything built on the model's output. On maintenance: there are no releases retrieved for this repository, so there is no versioned upgrade path and no changelog to read before pulling. Updating means git pull and re-reading the README for schema changes, since a new column in vulnerabilities or summary would require an ALTER TABLE you write yourself. The Ollama dependency moves independently, and a change in how Modelfile parameters are parsed would surface as an error at ollama create time rather than at scan time. Pin the base model tag in your own notes, because huihui_ai/qwen3.5-abliterated:9b is a moving tag unless the author publishes digests.
Editorial conclusion
Adopt METATRON if you are a single operator on Parrot OS or another Debian derivative, you already have 8.4 GB or more of RAM to spare for the 9b model, and you want a local record of recon output plus model commentary without sending target data to a hosted API. Do not adopt it if you need multi-user access control, a scheduler, or reproducible findings that survive a model swap, because the analysis is generated by whatever metatron-qwen you built and the database stores no model version or prompt hash. Before trusting a scan, verify three things: that ollama list shows metatron-qwen with the context size you expect, that the metatron MariaDB user can write to all five tables, and that the export path from view history produces a PDF whose contents match the summary row rather than the raw scan text.
Community notes