📖 13 min read
Quick Verdict: METATRON is a real, working, MIT-licensed CLI pentesting assistant that wires together nmap, whois, whatweb, curl, dig, nikto and a local LLM (a fine-tuned 9B Qwen variant served via Ollama) into an agentic loop with a MariaDB scan-history backend. It will not replace a senior pentester, but for reconnaissance triage, first-pass vulnerability analysis, and report scaffolding on engagements where client confidentiality forbids cloud AI, it is the most concrete offline AI pentesting tool available today. Rating: 7/10
Discovered: April 2026
What METATRON Is
METATRON is an open-source, CLI-based AI penetration testing assistant published by Soorya Thejas and released in early April 2026 under the MIT license. The project lives at github.com/sooryathejas/METATRON and has been picked up by a handful of security outlets including Cyber Security News, Medevel and Cyber Technology Insights. It targets Debian-family distributions, with Parrot OS as the design platform, and is written in Python 3 on top of MariaDB.
The framing in the GitHub README is unusually explicit about what it is and what it is not: a “CLI-based AI penetration testing assistant that runs entirely on your local machine — no cloud, no API keys, no subscriptions.” You give it a target IP or domain, it runs the canonical reconnaissance utilities you would run by hand, feeds the raw output to a locally hosted language model, and the model produces a vulnerability analysis, suggested exploits, and remediation steps. Every session is persisted to a five-table MariaDB schema, so scan history is queryable, editable and exportable to PDF or HTML.
METATRON is not a phantom project, not vaporware, and not a marketing-only release. The repository ships working code, a Modelfile for the model, schema definitions, screenshots of the actual CLI in action, and an MIT license. It is, however, a single-maintainer v1.0 release that has not yet been audited, and that distinction matters when you are about to point offensive tooling at a real environment.
Why “Offline” and “Zero Cloud” Matter for Pentesting
The offline + zero-cloud claim is the engineering decision that matters, and the reason the project deserves a serious look rather than a dismissive one. Pentesting engagements routinely come with contractual and legal constraints that explicitly forbid sending client data, target banners, IP ranges, or vulnerability findings to third-party services. Cloud AI assistants are out on those engagements by default, regardless of how capable the model is.
There are several distinct reasons a senior tester cares about this:
Client confidentiality. Standard rules of engagement include clauses that findings, internal hostnames, and unredacted banner data cannot leave the engagement environment without written approval. Sending that material to a remote LLM endpoint — even an enterprise-tier one — is itself a data-handling event. An offline tool sidesteps the entire question.
OPSEC and telemetry. Cloud AI tools are not silent observers. Inference endpoints log prompts, the upstream provider’s own tooling may retain logs, and metadata about timing and volume is visible to the network. For a red team operating against an environment with detections in place, that traffic pattern alone can compromise the engagement. A local model means no DNS resolution to OpenAI, Anthropic, or Google, and no outbound API calls to fingerprint.
Air-gapped and classified networks. Some engagement environments — defense industrial base, certain financial-sector enclaves, manufacturing OT segments — are air-gapped by design. Cloud AI is physically unavailable there. A self-contained tool that runs on a laptop with Ollama and a 9B model is one of the few ways to get AI-assisted analysis in those environments without a classified cloud enclave.
No telemetry leaks. Even consumers of pentesting tools often underestimate how much their daily workflow tools leak. An offline tool by construction leaks nothing, because there is no channel to leak through.
The claim is also falsifiable. You can test it: pull the network cable, kill Wi-Fi, run a full METATRON session, and verify that nothing reaches the public internet beyond, optionally, the DuckDuckGo search module — and even that is optional and can be disabled.
How It’s Built
METATRON’s stack is small, conventional, and worth understanding in detail because the model choice is what determines everything the tool can and cannot do well.
Base model. The underlying language model is huihui_ai/qwen3.5-abliterated:9b, a 9-billion-parameter Qwen 3.5 variant distributed through Ollama’s model library. The “abliterated” qualifier refers to a community fine-tune that removes the base model’s refusal behavior, which is necessary for a tool whose job is to discuss exploits candidly. The repository ships a Modelfile that wraps this base with a custom system prompt and parameters tuned for penetration testing work.
Fine-tuning and parameters. The Modelfile produces a custom tag, metatron-qwen, configured with a 16,384-token context window, temperature 0.7, top-k 10, and top-p 0.9. The 16K context is meaningful — it is large enough to ingest a full nmap service-detection dump plus HTTP headers plus nikto output without aggressive truncation, which is the mode of failure that breaks most “AI + recon” wrappers.
Runner. The model is served locally through Ollama. Ollama is the right choice for a 9B model on consumer hardware: it handles model loading, quantization, KV-cache management, and a clean HTTP API. Alternatives like llama.cpp directly, vLLM, or ExLlamaV2 would also run the same model and are interchangeable here, but Ollama’s packaging makes the install path a one-liner.
Quantization. The default 9B model needs roughly 8.4 GB of RAM at standard quantization. The repo explicitly documents a 4B parameter variant for systems with less than 8 GB, and notes that the 9B variant runs more comfortably on 16 GB. This is realistic; a 9B Qwen 3.5 quantized to Q4_K_M is exactly the size that fits on a current-generation prosumer laptop with 32 GB of unified memory.
Recon tools. METATRON shells out to the standard CLI utilities: nmap for port and service scanning, whois for registration data, whatweb for technology fingerprinting, curl for HTTP header inspection, dig for DNS records, and nikto for web server misconfiguration checks. None of these are stubs — they are the same binaries you would run by hand, with their output piped into the AI for interpretation.
Database and exports. A five-table MariaDB schema persists every scan. The central history table is keyed by a session number (sl_no); linked tables store vulnerabilities with severity, AI-suggested fixes, attempted exploits with payloads and results, and the full raw scan + AI analysis dump. Reports export to PDF and HTML.
The honest takeaway: this is a small, well-structured Python project that does the unglamorous plumbing — subprocess calls to nmap, database writes, prompt construction — and lets a modest open-source model do the interpretive work.
Core Capabilities
- Automated reconnaissance orchestration. Selectable execution of nmap, whois, whatweb, curl headers, dig, and nikto, with a “run all” preset. Each tool runs as a real subprocess, not a mock.
- Agentic loop. The model can request additional tool runs mid-analysis if it determines more data is needed before producing a verdict. This is a meaningful design choice — the tool is not a one-shot summarizer; it can iteratively refine.
- CVE cross-reference via DuckDuckGo. No API key required. The tool performs web search against DuckDuckGo’s free endpoint and pulls relevant CVE identifiers for detected versions. The no-key detail matters for air-gapped and OPSEC-sensitive environments.
- Vulnerability cataloging with severity. Findings are written to MariaDB with severity tags, the port and service they were detected on, and a free-text description — enough structure to query or filter for report assembly.
- AI-suggested fixes per vulnerability. Each finding gets a remediation note sourced from the model’s analysis, linked back to the originating vulnerability row.
- Exploit attempt logging. Payload, tool used, result, and tester notes can all be persisted per session, which is what an audit trail actually requires.
- Editable scan history. Any record can be modified or deleted from the CLI, which is non-trivial — pentesters routinely need to redact client-specific data before sharing reports.
- Report export. PDF and HTML output for delivery to clients or for archival.
Real Test: What Does It Actually Do Well?
Reviewing the public documentation, screenshots, and architecture against how a 9B model actually performs on security tasks, here is where METATRON realistically adds value, and where it just produces plausible-looking text.
Recon triage at the beginning of an engagement. This is the tool’s strongest use case. A tester who needs to spin up a new external attack surface assessment can hand METATRON a target and get a structured first pass — open ports, service versions, technology fingerprint, header analysis, web server misconfigurations — with a plain-English summary at the end. That summary will not be brilliant, but for a 9B model it will be competent and it will save 30 to 60 minutes of manual reading.
Pattern matching against well-documented CVEs. When the model is given clean service banners (“Apache 2.4.41 on Ubuntu 18.04”), it is reasonably reliable at recalling the relevant CVEs and producing a sensible first-pass patch guidance. This is exactly the kind of recall task that local 9B-to-30B models handle well in 2026, and the offline posture does not materially hurt them because the knowledge is in the weights.
Report scaffolding. The structured vulnerability records, severity tags, and fix suggestions are useful as report scaffolding. A tester can pull a session, lightly edit each entry, and have a respectable client deliverable in a fraction of the time it takes to write one from scratch. The exports to PDF and HTML are real outputs.
OPSEC-respecting workflows. For engagements where any cloud call is a non-starter, METATRON is one of the few realistic options. It is not the only option — PentestGPT can be pointed at a local model, and HackingBuddyGPT runs locally as well — but it is the most packaged.
Where it genuinely underperforms. Novel exploit logic, chained vulnerability reasoning, business-logic flaws, and anything requiring a working memory of multi-step exploitation across pivots are all well beyond a 9B model. The tool does not generate working zero-days, and it will not. Anyone who tells you otherwise is selling you something.
Limitations and Where It Falls Short
- 9B parameters is a ceiling, not a floor. Qwen 3.5 at 9B is a capable model but it is not in the same reasoning class as a 70B+ model, let alone a frontier cloud model. Long-horizon reasoning, subtle logic flaws, and creative exploit chaining are out of scope. A tester who treats the AI output as ground truth is going to ship bad reports.
- Single-author v1.0. There is one maintainer, no independent security audit, and a small star count as of writing. For offensive tooling that is going to be pointed at real environments, that is a non-trivial risk surface. Use it on your own lab first, run it in a VM, and inspect the source before letting it loose on an engagement.
- No active exploitation module. METATRON runs recon and suggests fixes. It does not include Metasploit, sqlmap, or a burp-style active-testing harness. It is a triage and documentation tool, not an exploitation framework, and the README is honest about that scope.
- Reconnaisance quality is exactly as good as the tools underneath. nmap service detection still misses things, nikto is signature-based and dated, and whatweb’s fingerprints lag reality. None of that is METATRON’s fault, but it means the AI’s analysis is bounded by what the upstream tools see.
- DuckDuckGo search and CVE lookup are not authoritative. They are the only web calls in the system and they are opt-in, but they are also unauthenticated and rate-limited. For high-stakes CVE matching, NVD or the vendor advisory remains authoritative.
- Context window pressure on large scans. 16K tokens is generous for a 9B model, but a heavy nmap scan combined with nikto output on a large web property can still push the prompt budget. There is no documented automatic truncation strategy beyond standard Ollama behavior.
- Linux/Parrot-OS only. macOS testers will need to run it in a VM or a container. Native Windows support is not on the roadmap.
Comparison: METATRON vs PentestGPT vs HackingBuddyGPT vs Burp AI Extensions
The honest landscape in mid-2026 for AI-assisted pentesting tools looks like this. None of these is a category winner across the board; each makes different tradeoffs.
PentestGPT (the academic project by Marcus Boyd / Greydesert, the original “PentestGPT” published in 2023 and iterated on through 2025) is a general-purpose prompting harness for penetration testing workflows — reconnaissance planning, vulnerability analysis, and report drafting. It is cloud-default and does not ship its own model; you wire it up to an OpenAI-compatible API. By default it is in the cloud, which immediately disqualifies it from confidential engagements. Compared to METATRON, PentestGPT is more flexible on the reasoning side because the user can attach a frontier model, but it does not orchestrate the actual recon tools and does not have an offline mode out of the box.
HackingBuddyGPT (the academic research project from the Schneider / Athene group) is focused on autonomous exploitation of captured lab environments. It is more agentic and more experimental than METATRON, but it is also more research-grade: less packaged, less documented for production use, and oriented toward “can an LLM autonomously compromise a vulnerable VM” rather than “can an LLM help a working pentester triage an engagement.” It runs locally with the right setup, but its target user is researchers, not delivery consultants.
BurpGPT and Burp AI extensions live inside Burp Suite and are point-tools — they help with individual HTTP request analysis, payload generation, and decode work as you click through the proxy. They are not orchestrators. They are excellent at what they do, but they require a Burp workflow, they typically forward requests to a cloud endpoint, and they do not generate full-engagement scan narratives. METATRON is a complement to Burp rather than a substitute; a serious engagement uses both.
METATRON’s positioning lands in the gap between PentestGPT’s flexibility and HackingBuddyGPT’s research ambition: a packaged, single-purpose, offline-first CLI that hands you structured triage, exploits suggestions, and a report-ready history. Its tradeoff is modest model size and a smaller community.
Legal and Ethical Use
The README carries a clear disclaimer and this article will not soften it: penetration testing tooling, including AI-assisted tooling, is restricted to authorized targets. The Computer Fraud and Abuse Act in the United States, the Computer Misuse Act in the United Kingdom, and equivalent statutes across most jurisdictions make unauthorized access a criminal offense even when the actor’s intent is benign. The 2022 update to DOJ CFAA prosecutorial guidance de-prioritizes good-faith security research that stays within defined scope, but it does not provide legal immunity, and out-of-scope testing remains legally exposed.
Concrete rules of engagement should always include explicit written authorization, defined scope (hosts, applications, methodologies permitted), data-handling clauses, and contact channels for in-engagement questions. Do not run METATRON, nmap, nikto, or any of the underlying tools against systems you do not own or have not been authorized to test in writing. Bug bounty programs provide safe harbor only when their specific scope rules are followed; testing outside that scope voids the protection and is treated as unauthorized access.
METATRON’s offline posture is, from a legal standpoint, not a free pass. The same laws apply. The zero-cloud architecture is a confidentiality and OPSEC feature, not a license to widen scope.
Who Should Use This
METATRON is the right tool for security consultants, in-house red teamers, and bug bounty researchers who need structured, repeatable reconnaissance triage without sending target data to a cloud endpoint. It is a strong fit for engagements with data-handling restrictions, for air-gapped or OPSEC-sensitive environments, and for small teams that want a free, auditable triage pipeline. It is not the right tool for anyone who needs a frontier model for subtle reasoning, for anyone whose workflow is built around Burp Suite as the primary surface, or for teams whose risk register forbids single-maintainer offensive tooling on production engagements without an audit.
Final Verdict
METATRON is the rare case where the headline — “an offline AI pentesting assistant that needs zero cloud” — is also the technical reality. The architecture is small enough to be auditable, the model choice is honest for the hardware it targets, and the agentic loop with persisted scan history is genuinely useful for early-engagement triage. It is not going to find novel exploits, it is not going to replace Burp, and it is not going to replace a human tester. What it will do is compress hours of recon reading into a structured first pass, keep sensitive data on your laptop, and produce a report-shaped artifact you can edit and ship. For a free, MIT-licensed, single-maintainer v1.0 that delivers what the README promises, that is enough to earn a 7/10 and a place on the shortlist.