GHOSTNET: The Local Security LLM That Routes, Grounds, and Audits Itself

A deep dive into a privacy-first pentesting assistant that uses deterministic intent routing, live CVE aggregation, and model auditing to turn a chatbot into a security workflow.

9 min read • View on GitHub • More from Sarthak5-t

A wide command-center workstation with a prompt entering from the left and splitting into several routed lanes inside a local security system. One path feeds a local model, another pulls in vulnerability dossiers, and another loops through a scanner, showing that the system decides what machinery to use before it generates an answer. — GHOSTNET’s core move is not generation. It is decision-making before generation.

Key Takeaways

GHOSTNET is best understood as a routed workflow engine that decides how to answer before it decides what to say.
Its privacy story matters because security prompts, exploit ideas, and client artifacts stay local instead of leaving for a third-party API.
The CVE pipeline turns live vulnerability data into structured context, which forces the model to draft against evidence instead of memory.
The model scanner makes the project unusually self-aware, because it audits the very layer it relies on to generate output.

The chatbot that refuses to stay generic

GHOSTNET’s first interesting decision is also its sharpest: it does not treat every prompt as a chat prompt. A lightweight router classifies intent, then selects a mode, a model, and a prompt template that match the task. That makes the system feel less like a chatbot and more like an operator with a very short, very opinionated checklist.

That design changes the whole experience. A code question does not take the same path as a pentest question, and a CVE lookup does not rely on the same machinery as free-form analysis. The system is making a promise up front: different problems deserve different routes.

The important design choice is not model choice alone. It is that routing and grounding happen before generation begins.

Why local-first is the point

In a security workflow, the privacy argument is not decorative. Offensive research often includes exploit ideas, client context, internal findings, and sensitive fragments of infrastructure. Sending that material to a hosted API changes the trust boundary in ways a pentest team cannot ignore.

GHOSTNET’s local-first architecture keeps the work on the machine. That matters both practically and politically. Practically, it reduces leakage risk and avoids dependency on remote service policy. Politically, it makes the tool fit the realities of consultancies, red teams, and internal security groups that need to move quickly without exporting their most sensitive material.

The router is the product

The project’s routing logic is deliberately unglamorous. In `app/router.py`, `choose_mode` and `smart_route` use keyword scoring and regex matching to classify the prompt into a small set of modes: coding, analysis, pentest, or CVE work. That is a good sign. It means the system is optimizing for predictable behavior, not cleverness.

# Conceptual shape of the router
mode = choose_mode(prompt)
model = choose_model(mode)
system_prompt = SYSTEM_PROMPTS[mode]
response = call_model(model, system_prompt, prompt)

This is a strong design choice because security workflows punish ambiguity. A semantic router might be more flexible, but flexibility is not always what you want when the user is asking for a specific operational outcome. Regex scoring is blunt, but blunt can be stable, auditable, and easy to reason about.

A close-up of a prompt being stamped into one of several rigid routing slots, with different lanes leading to specialized tools and models. The image explains that GHOSTNET classifies intent first and only then chooses how to process the request. — The router is not a convenience layer. It is the product’s core control surface.

How CVE lookup becomes grounded exploit drafting

The CVE pipeline is where GHOSTNET stops feeling like a local assistant and starts feeling like a disciplined research tool. `cve_crawler.py` pulls from multiple sources, including NVD, OSV, CIRCL, and EPSS, then normalizes that material into a structured internal format. The point is not just to fetch descriptions. It is to assemble evidence.

That evidence then feeds `/cve/lookup` and `/exploit/generate`. Instead of asking the model to remember a vulnerability from training data, the system hands it the current metadata and tells it to work against that context. The difference is subtle in code and huge in practice. One path invites hallucination. The other constrains generation with live ground truth.

Generic security chatbot	GHOSTNET
One prompt goes to one model.	Intent is classified before any generation happens.
Answers lean on model memory.	Answers are anchored in live CVE metadata and EPSS data.
Remote API calls can expose sensitive context.	Local execution keeps sensitive material on the machine.
The model is trusted by default.	The model layer is routed and audited.
Output is conversational first.	Output is operational first.

# Conceptual CVE path
cve = fetch_from_sources(cve_id, sources=["NVD", "OSV", "CIRCL", "EPSS"])
context = build_prompt_context(cve)
exploit = call_model("code", SYSTEM_PROMPT, context)

The architectural lesson is bigger than vulnerability research. Any workflow that depends on facts, not vibes, benefits from a pipeline that fetches structured evidence before generation. GHOSTNET is just applying that principle to security work, where the cost of confident nonsense is much higher.

Auditing the model layer itself

`scanner.py` adds the most elegant twist in the repo. GHOSTNET does not only use a model for security tasks. It also subjects the model layer to security testing through Garak, looking for leakage, jailbreak behavior, and prompt-injection weaknesses. That is a useful inversion. The tool is not merely a consumer of trust. It is also a subject of trust assessment.

This matters because most LLM apps skip the uncomfortable part. They build output flows, but not adversarial evaluation. GHOSTNET at least acknowledges that the model is part of the attack surface. Even if the implementation is still early, the intent is unusually mature.

What GHOSTNET gets right, and where it stops

The codebase is promising, but it is still an alpha-stage system. That shows up in the likely reliance on local model quality, the narrow routing taxonomy, and the fact that future plans seem to include browser-assisted recon through Playwright. None of that is a flaw by itself. It just means the project is closer to an opinionated prototype than a finished platform.

Still, the architecture is the point. GHOSTNET is not trying to be broad. It is trying to be controlled, repeatable, and private. That trade-off makes sense for security work, where the best assistant is often the one that knows when to switch modes, when to fetch facts, and when to stop acting like a chatbot.

Strengths	Limits
Deterministic routing keeps behavior easy to reason about.	A regex router is less flexible than semantic classification.
Local execution preserves sensitive context.	Model quality still sets the ceiling on output quality.
Live CVE enrichment grounds generation in current evidence.	Coverage depends on the quality and freshness of upstream sources.
Model auditing adds a rare feedback loop.	The platform is still early and likely evolving quickly.

The shape of the next security assistant

GHOSTNET points toward a larger pattern. The next useful assistant in a hard domain will not be the most conversational one. It will be the one that routes well, grounds its answers in live data, and keeps enough of the workflow local to be trusted.

That is why this repo is worth paying attention to. It is not a chatbot with a security theme. It is a security workflow that learned how to talk only after it learned how to decide.