METATRON: a local LLM penetration testing assistant for Parrot OS

What METATRON solves and who it is aimed at

Running a scan is the easy part of a penetration test. The tedious part is reading the combined output of nmap, whois, whatweb, curl, dig and nikto, then writing up what each finding means. METATRON is built to collapse that step. The README describes the flow plainly: you give it a target IP or domain, it runs those recon tools, and it feeds the results to a local model for analysis, vulnerability identification, exploit suggestions and fix recommendations. Everything lands in a MariaDB database with what the README calls full scan history.

The intended user is a single operator working from a Linux box, most likely Parrot OS given the badge and the tech stack table. The selling point is that nothing leaves the machine. The README states there are no cloud calls, no API keys and no subscriptions, and the AI component is a fine-tuned Qwen model pulled through Ollama. That matters if you are testing a client network where sending target data to a third-party inference endpoint is a non-starter.

It is a solo tool, not a platform. There is no server component, no web interface and no scheduling. The CLI has a main menu with New Scan, View History and Exit. If you are looking for something a team can share, this is not that.

How the recon-to-analysis pipeline is put together

The repository layout tells you most of the architecture. There are five Python files at the top level: metatron.py, tools.py, llm.py, db.py and search.py, plus export.py for reports. That split maps cleanly onto the pipeline. tools.py wraps the external binaries, llm.py talks to Ollama, db.py owns the MariaDB connection, search.py handles DuckDuckGo and CVE lookups, and metatron.py is the menu loop that drives everything.

The AI side is not the stock base model. The repo ships a Modelfile, and the README's install step runs ollama create metatron-qwen -f Modelfile. According to the README, that produces a model with a 16,384 token context window, temperature 0.7, top-k 10 and top-p 0.9. The base is listed as huihui_ai/qwen3.5-abliterated:9b, described in the tech stack table as a fine-tuned Qwen 3.5. The 16k context is the number that matters most here, because scan output is verbose and the model has to hold several tool results at once.

The README also mentions an agentic loop in the feature list, where the AI can request more tool runs mid-analysis. That is the interesting design choice and the least documented one. Nothing in the README explains how many iterations the loop allows, what stops it, or how the extra tool output is merged into the running analysis. If you plan to rely on that behaviour, read metatron.py and llm.py before you trust it.

Storage is five linked tables: history, vulnerabilities, fixes, exploits_attempted and summary. The summary table holds raw_scan and ai_analysis as LONGTEXT alongside a risk_level. That schema is the reason history editing and deletion are possible from the CLI at all, and it is what the PDF and HTML export reads from.

Installing METATRON and running a first scan

The README gives a linear install. Clone, create a virtual environment, install the Python dependencies, then install the system tools the scanner shells out to. Note that the apt line includes dnsutils, which is what provides dig.

git clone https://github.com/sooryathejas/METATRON.git
cd METATRON
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
sudo apt install nmap whois whatweb curl dnsutils nikto

The Python side is pinned. requirements.txt lists mysql-connector-python 9.6.0, reportlab 4.4.10 for PDF export, rich 14.3.3 for terminal output, and both ddgs 9.12.1 and duckduckgo_search 8.1.1 for search. Seeing two DuckDuckGo libraries pinned at once is worth flagging: search.py presumably uses one of them, and the other is likely a leftover. It will not break the install, but it tells you the dependency list was not pruned.

Next comes Ollama and the model. The README warns that the 9b model needs at least 8.4 GB of RAM and points at a 4b variant otherwise, in which case you edit the FROM line in Modelfile before creating the model.

curl -fsSL https://ollama.com/install.sh | sh
ollama pull huihui_ai/qwen3.5-abliterated:9b
ollama create metatron-qwen -f Modelfile
ollama list

If the last command prints metatron-qwen, the model exists. Then create the database. The README's SQL creates a metatron user with the password 123, which is fine for a throwaway VM and unacceptable anywhere else.

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

The README then has you connect as that user and paste five CREATE TABLE statements for history, vulnerabilities, fixes, exploits_attempted and summary. There is no migration script and no schema file in the repository listing, so this paste step is the only way the tables get made.

Running it takes two terminals. The first holds the model loaded, the second launches the tool.

ollama run metatron-qwen
cd ~/METATRON
source venv/bin/activate
python metatron.py

The README says to wait for the >>> prompt in the first terminal before starting the second. The main menu then offers New Scan, View History and Exit. Choosing New Scan prompts for a target, and the README's example uses 192.168.1.1. Reports come out through View History: pick a record by serial number and export it as PDF or HTML.

Where METATRON breaks down in practice

The first limitation is the model itself. A 9b parameter model reading raw nmap and nikto output will produce plausible-sounding analysis that is sometimes wrong, and the README does not describe any validation step between what the model writes and what lands in the vulnerabilities table. Severity, port and service fields are filled from the model's reading of the scan. Treat the AI section as a draft, not as a finding. The exploits_attempted table has a payload column, but the README never explains whether METATRON actually executes anything or only records suggestions.

Second, the install assumes a lot. The OS badge says Parrot Linux, the tech stack table says Parrot OS (Debian-based), and the apt command assumes Debian packaging. Nothing in the README addresses other distributions. More importantly, the README never says what happens when one of the six recon binaries is absent or a scan against a filtered host returns nothing. There is no documented error handling for a failed tool run.

Third, setup is manual in ways that will bite on a rebuild. The database user password is hardcoded in the README as 123, the schema exists only as text to paste, and the model has to be rebuilt with ollama create on every machine. There are no releases in the repository, so the only version you get is whatever main points at when you clone. The last push to the repository was on 2026-04-11, which is roughly five months before this writing. That is not abandoned, but it is also not a project with a release cadence you can plan around.

Fourth, the target scope. This is a recon and analysis assistant, not an exploitation framework. If you need a tool that manages sessions, pivots and payload delivery, you are looking at the wrong project. The feature list mentions exploit suggestions, and suggestions are what the documentation supports.

How METATRON differs from the usual recon stack

The obvious comparison is running the same binaries yourself and writing your own notes, which is what most testers do. The difference is the storage layer. METATRON's five tables give you a queryable record of every scan against every target, with the AI analysis and the raw scan text stored side by side in the summary table. If you have ever tried to reconstruct what a host looked like three engagements ago from a folder of text files, that schema is the argument for the tool.

The closer alternative is an LLM-assisted workflow built on a cloud model, where you pipe tool output into an API and get analysis back. That approach is faster to set up and generally gives better analysis, because the models are larger. It also sends your target data off the machine, which is exactly the constraint METATRON is designed around. The README's framing is explicit: no cloud, no API keys, no subscriptions. If your engagement rules allow external inference, the local model is a cost you are paying for a privacy property you do not need.

There is also the general-purpose route: run nmap and nikto, then paste the output into whatever local chat interface you already have. You lose the database, the linked tables, the export, and the agentic loop, and you gain nothing to install beyond what you already run. METATRON's value is concentrated in the persistence and the report export, not in the recon itself, which is the same set of tools everyone else wraps.

Licence, upgrade cost and what you are committing to

METATRON is MIT licensed, and the LICENSE file is at the top level of the repository. MIT is permissive: you can use it commercially, modify it and redistribute it, provided the copyright notice and licence text are kept. That is the standard reading, not legal advice, and it is worth checking how the licence interacts with the model you pull. The base model is huihui_ai/qwen3.5-abliterated:9b, distributed through Ollama, and the README says nothing about that model's own licence terms. The abliterated variant name refers to a modified model, and model licences are frequently not the same as the code licence around them. If you plan to use METATRON commercially, verify the model's terms separately from the MIT licence on the repository.

Upgrade cost is the weak point. With no releases published, there is no version to pin and no changelog to read. Updating means pulling main and re-reading the files that changed. The database schema is the real hazard: if a future commit adds a column to vulnerabilities or summary, the README's CREATE TABLE statements will not match your existing tables, and there is no migration path documented. Back up the metatron database before pulling, and diff the README's SQL against your live schema after.

The model side has a similar cost. Modelfile is in the repository, so if the fine-tuning parameters change, you need to re-run ollama create metatron-qwen -f Modelfile to pick them up. Pulling a new base model means the same rebuild. Neither step is expensive in time, but both are manual and neither is scripted.

Editorial conclusion

Adopt METATRON if you already run Parrot OS or another Debian-based distribution, have at least 8.4 GB of RAM free for the 9b model, and want recon output and AI commentary stored in one MariaDB schema. Do not adopt it if you need a maintained release cadence, a documented API, or a tool you can hand to an analyst who is not comfortable editing a Modelfile and creating database tables by hand. Before running it, verify three things: that ollama list shows metatron-qwen after the create step, that the five tables in the README actually exist in your metatron database, and that every recon binary is on PATH, because the README does not describe what happens when one is missing.

Frequently asked questions

Official sources

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