AI models for offensive security: the open-weight ecosystem now wants to operate tools

The conversation around AI models for cybersecurity often collapses into one oversimplified question:

“What is the best uncensored model for hacking?”

That is no longer the most interesting question.

A repository maintained by Joas A. Santos, Offensive-Security-AI-Models, provides a September 2026 snapshot of the ecosystem: 27 open-weight models and variants grouped into security fine-tunes, general abliterated models, and older classics.

The most useful thing about the collection is not the uncensored label.

It is what the list reveals about where the market is moving:

security models are starting to move beyond specialized chatbots and toward components for agents that operate tools.

Repository analyzed: JoasASantos/Offensive-Security-AI-Models.

Note: VRAM, benchmark, context-window, and training figures cited here come from the repository snapshot and the model cards it links to. They should be treated as reported specifications, not as one independently standardized evaluation across all models.

The important shift: from knowledge to behavior

For years, a “cybersecurity model” mostly meant an LLM fine-tuned on technical material such as:

• CVEs;
• OWASP;
• MITRE ATT&CK;
• CTF writeups;
• bug-bounty reports;
• malware;
• incident response.

That remains useful, but it is not enough to build an agent.

An agent needs something closer to:

objective
  ↓
reasoning
  ↓
tool selection
  ↓
structured call
  ↓
real result
  ↓
replanning
  ↓
evidence

That is why attributes that were secondary not long ago now stand out in the list:

• tool/function calling;
• 128K, 262K, or even larger context windows;
• datasets of agentic conversations;
• GGUF formats for local execution;
• MoE variants with a small active parameter count per token;
• vision in some models;
• explicit training for CLI, terminal, and automation workflows.

The question stops being “does it know pentesting?” and becomes:

can it participate reliably in an agentic loop?

Three families worth separating

The repository groups related models together, but technically there are different families.

1. Security fine-tuned models

These models are trained or adapted with cybersecurity datasets.

Examples in the list include:

• DeepHat V2 on Qwen2.5-Coder;
• BugTraceAI with bug-bounty and CVE material;
• CyberPal 2.0 for CTI, SOC, IR, and AppSec;
• pentest-v2 with GTFOBins, HackTricks, and writeups;
• Lily-Cybersecurity;
• VEXT Pentest;
• Imperum CybersecurityLLM.

Their potential advantage is specialization.

Simply “removing refusals” is not the same thing as teaching a model the terminology, patterns, workflows, and artifacts of the domain.

2. Abliterated or “obliterated” models

Abliteration attempts to reduce or remove refusal behavior by modifying internal directions associated with refusals.

That does not magically turn a model into a cybersecurity specialist.

A general abliterated Qwen model may be more permissive, but it still depends on the capabilities of its base model.

The distinction matters:

uncensored / abliterated
        ≠
security trained
        ≠
good agent

The repository includes Qwen, GLM, DeepSeek, and other variants in this category.

3. Agentic models

This is the most interesting category.

Some entries do not merely claim security knowledge. They also advertise training for:

• function calling;
• tool use;
• multi-step reasoning;
• terminal work;
• automated workflows.

That brings the model much closer to the kind of component a modern harness needs.

Seven models that show the range

It makes little sense to rank all 27 models in one universal leaderboard. They vary too much in size, task, quantization, dataset, and intended use.

But several entries illustrate the spectrum well.

Model	Size	Context	Approx. VRAM	Tools	What stands out
DeepHat V2	7B	131K	~6 GB Q4	Yes	Security + Coder base + tool calling
Cyber-Ornith-1.5-9B	9B	128K	~7 GB Q4	Yes	Explicit focus on CLI, terminal, and agentic workflows
pentest-v2	8B	32K	~6 GB Q4	No	Small fine-tune built from pentesting material
Qwythos-9B	9B	up to 1M	~7 GB Q4	Yes	Tool calling + vision + huge context
RavenX-CyberAgent	36B / ~3B active	262K	~24 GB Q4	Yes	MoE, agentic training, structured outputs
security-slm-unsloth	1.5B	32K	~2 GB Q4	No	Very small model for narrow tasks
Qwen3.8-27B Uncensored	27B	262K	~18 GB Q4	Yes	Large general model with vision and tools

DeepHat V2: a practical entry point

DeepHat V2 uses Qwen2.5-Coder-7B as its base. The repository lists it at around 6 GB of VRAM with Q4_K_M, with 131K context and tool calling.

That profile matters because it fits within realistic consumer hardware.

A 7B model does not need to solve an entire assessment by itself to be useful.

It can act as a:

recon parser
   ↓
classifier
   ↓
hypothesis generator
   ↓
tool caller
   ↓
evidence summarizer

Inside an agentic system, total usefulness is not determined only by the model’s standalone intelligence.

Cyber-Ornith-1.5-9B: built for the loop

Cyber-Ornith stands out because its declared specialization explicitly includes:

• function calling;
• tool use;
• reasoning;
• CLI/terminal automation.

At roughly 9B parameters, 128K context, and around 7 GB in Q4, it sits in an attractive range for local experimentation.

If the goal is an agent, this kind of training may matter more than a few extra points on a generic benchmark.

pentest-v2: narrow specialization on a budget

pentest-v2 starts from Qwen3-8B and uses a small LoRA trained on 2,804 curated samples from GTFOBins, HackTricks, and HackTheBox writeups.

The repository reproduces a striking model-card claim: 100% accuracy on a GTFOBins evaluation compared with 25% for the base model zero-shot.

That should not be interpreted as “four times better at pentesting.”

It is a narrow measurement, likely close to the fine-tuning domain.

But it does illustrate something useful:

a small fine-tune can substantially alter behavior on a specific task.

Qwythos-9B: context and multimodality in a small footprint

Qwythos-9B is listed with:

• 9B parameters;
• native tool calling;
• vision;
• context scaled up to 1M;
• around 7 GB in Q4.

For agents that inspect code, screenshots, tool output, and long documentation, that combination can matter more than a purely textual model with a stronger academic benchmark.

RavenX-CyberAgent: when the model starts to look like a platform component

RavenX uses an MoE architecture with about 36B total parameters and ~3B active, 262K context, and tool calling.

Its declared specialization includes a structured protocol for:

Attack Surface
→ Exploit
→ Impact
→ Remediation
→ Document
→ Prevent

It also produces mappings such as CVSS, CWE, and MITRE ATT&CK.

That design looks less like a chatbot.

It looks more like a specialized worker inside a security system.

The hardware map has changed too

The list makes it clear that “running a security model locally” no longer necessarily means buying a workstation costing thousands of dollars.

We can think of four broad tiers.

~2 GB: ultra-light models

Models such as security-slm-unsloth-1.5B can fit on very modest machines.

They are not candidates to replace a large model, but they can still be useful for:

• classification;
• routing;
• extraction;
• labeling;
• triage;
• filtering.

~6–8 GB: the most interesting range for experimentation

Several 7B–9B models land here:

• DeepHat;
• Cyber-Ornith;
• Dolphin3-Cyber;
• pentest-v2;
• Qwythos.

This is probably the most attractive local-lab tier because it enables:

local model
+ Ollama / llama.cpp
+ real tools
+ harness

without requiring datacenter infrastructure.

~18–24 GB: more ambitious local agents

Several quantized 27B–36B models fall into this range.

You can gain more reasoning and generation capacity, but pressure also increases on:

• VRAM;
• system RAM;
• bandwidth;
• prompt latency;
• practical usable context length.

Multi-GPU: frontier-scale open weights

Some GLM variants and large MoE entries in the list require datacenter-class hardware.

They may be technically open-weight, but operationally they belong to a different category.

“Downloadable” does not mean “practical to run at home.”

“Uncensored” does not mean “better”

This is probably the most important caution.

Reducing refusals can be useful in authorized research because an overly restrictive model may block legitimate work involving:

• vulnerability analysis;
• malware research;
• reverse engineering;
• exploit reproduction;
• CTFs;
• red teaming.

But removing refusals does not automatically improve:

• reasoning;
• accuracy;
• grounding;
• planning;
• tool calling;
• scope adherence;
• hallucination resistance.

It can even introduce new risks.

A model that never says no can also execute a wrong hypothesis with great confidence.

For a security system, that matters enormously.

How I would evaluate a model for a real agent

Before looking at a leaderboard, I would test the model inside the actual workflow we intend to build.

For example:

1. receive a bounded objective
2. read context
3. select a tool
4. emit a valid call
5. interpret the result
6. cite evidence
7. distinguish "possible" from "confirmed"
8. recover from errors
9. respect scope
10. produce a reproducible report

The relevant metrics would be:

• valid tool-call rate;
• false-positive rate;
• ability to cite real evidence;
• consistency after tool failures;
• scope compliance;
• latency;
• tokens per task;
• long-context stability;
• performance under quantization;
• license and dataset provenance.

That evaluates a system, not just a model.

The harness matters as much as the LLM

The author of the model-list repository also maintains NeuroSploit, a Rust-based multi-model penetration-testing harness.

Its current architecture emphasizes problems that a checkpoint cannot solve by itself:

• agent selection;
• parallel execution;
• tool use;
• cross-model validation;
• tool receipts as evidence;
• scope control;
• reporting;
• support for local models through Ollama and llama.cpp.

Repository: JoasASantos/NeuroSploit.

That suggests a more realistic architecture:

                 ┌───────────────┐
                 │     scope     │
                 └───────┬───────┘
                         ↓
┌──────────┐     ┌───────────────┐
│ model A  │ ──→ │    harness    │
└──────────┘     └───────┬───────┘
                         ↓
                  ┌─────────────┐
                  │    tools    │
                  └──────┬──────┘
                         ↓
                  ┌─────────────┐
                  │  evidence   │
                  └──────┬──────┘
                         ↓
                 ┌───────────────┐
                 │ validator B   │
                 └───────────────┘

The model proposes.

The tools observe.

The harness constrains.

The evidence decides.

The real opportunity for local models

Small specialized models have one advantage that can get lost when we compare them directly with frontier models:

they can become infrastructure.

A local 7B or 9B model can stay online continuously and handle subtasks without sending data outside the environment.

For example:

large remote LLM
        │
        ├── hard reasoning
        │
        ▼
      harness
        │
        ├── local model → classification
        ├── local model → tool routing
        ├── local model → triage
        └── local model → evidence summary

It can also run fully offline in isolated labs.

That is particularly attractive in security, where context may include:

• proprietary source code;
• network topology;
• logs;
• temporary credentials;
• indicators;
• unpublished reports.

What to watch before adopting one

There are several reasons to stay cautious.

1. Benchmarks are not directly comparable

Each model card may use different datasets, prompts, and criteria.

We cannot turn heterogeneous figures into a clean universal ranking.

2. Maximum context is not guaranteed useful context

“262K” or “1M” describes a technical context capacity, not necessarily stable reasoning quality across the whole window.

3. Quantization changes behavior

Q4 may work beautifully for one task and degrade another, particularly structured outputs or narrow reasoning tasks.

4. Dataset composition matters

A model trained on writeups may learn useful patterns.

It may also memorize artifacts or overfit to the style of those examples.

5. A permissive model needs more controls, not fewer

For an agent with access to shell, network, or credentials, safety cannot depend on the model deciding to stop itself.

External controls are required:

• explicit scope;
• sandboxing;
• least privilege;
• logging;
• approvals;
• secret separation;
• result validation.

From hacking chatbot to red-team operating system

The Offensive-Security-AI-Models list is interesting because of the models it contains.

But it is even more interesting because of what it represents.

In a short period, the ecosystem has moved from:

general LLM
+ cybersecurity prompt

toward something more like:

specialized model
+ tool calling
+ long context
+ local quantization
+ agentic harness
+ evidence
+ validators

That shift is probably more important than any individual model.

The future of AI in security does not look like one “super hacker model.”

It looks like an architecture of specialized agents, some large and some small, coordinated by a harness that controls tools, permissions, evidence, and scope.

And that is where open-weight models may have a particularly strong advantage: we do not merely have to ask them questions.

We can turn them into programmable components of a platform.

---

Sources

• Offensive-Security-AI-Models — JoasASantos
• NeuroSploit — JoasASantos
• WhiteRabbitNeo on Hugging Face
• Cyber-Ornith-1.5-9B GGUF
• pentest-v2
• Dolphin3-Cyber-8B
• Qwythos-9B
• RavenX-CyberAgent

Responsible use: these tools and models should only be used on systems you own, in labs and CTFs, or in environments where you have explicit authorization to perform security testing.