oxyle's picture
|
download
raw
9.41 kB
---
license: other
base_model: Qwen/Qwen3.6-35B-A3B
library_name: transformers
tags: [offensive-security, pentesting, tool-calling, cyberstrike, qwen3]
pipeline_tag: text-generation
---
# CyberStrike-OffSec-35B
Autonomous offensive-security / pentesting agent fine-tuned on **Qwen3.6-35B-A3B**. This model emits
**real, structured tool calls** with correct agent routing and clean termination — the behaviours a
tool-calling harness actually needs.
This release ships as a **single-piece merged checkpoint** (load with one command). A LoRA adapter
is also available for `--enable-lora` serving (see *Serving → Adapter*).
---
## What this fine-tune actually is (and isn't)
Set expectations honestly. This is a **small, targeted alignment**, not a capability upgrade:
- **It did NOT** add security knowledge — the base Qwen3.6 already knows offensive-security
concepts, and already emits tool calls (22/24 in our eval).
- **It DID** teach the model to emit tool calls *in the exact format a CyberStrike harness expects*,
route to *valid agent archetypes* instead of internal codenames, handle real observations without
fabricating them, and terminate cleanly.
In other words: we did not make the model *smarter* — we **aligned it to the harness** and **fixed
the specific collapse** of the previous version. Trained on a deliberately small **300-example**
dataset (one round), so gains are concentrated in tool-use behaviour, not broad capability. Broader
robustness is the goal of the next data iteration (Stage-2). We state this plainly so a returning
user knows exactly what changed and why.
---
## Why this release exists — measured before/after
The previous CyberStrike model failed in production: users reported "broken tool calling,"
"simulated executions," and "faked engagements."
**Root cause — the training data was in the wrong format.** The previous model's SFT dataset taught
tool calls in a format the model never learned to emit as *real structured calls*. As a result it
produced **wrong / malformed tool calls**, fell into **loops**, and — unable to actually invoke a
tool — **hallucinated**: it wrote fake tool outputs (invented `curl`/SSL handshakes, Nmap scans,
`Set-Cookie` headers, even fabricated flags) and narrated whole engagements while executing nothing.
This release fixes that by training on the correct tool-call format. To verify, we ran a controlled
**three-way A/B evaluation — base Qwen3.6 vs. the previous CyberStrike model vs. this model** — over
24 scenarios (6 axes × difficulty tiers, 62% out-of-distribution). Full methodology, all 24 prompts,
the complete result matrix, and verbatim raw-output quotes are in **[EVALUATION.md](./EVALUATION.md)**.
Every number below is grounded in **raw model output**, not auto-scored heuristics.
| Metric (24 scenarios) | Base Qwen3.6 | **Previous model** | **This model** |
|---|---|---|---|
| Genuine structured tool calls | 22/24 | **0/24** | **18/24** |
| Correct tool / archetype | 6/24 | 2/24 | **10/24** |
| Clean termination | 21/24 | **3/24** | **24/24** |
| Fabricated observations | none | **widespread (8+ scen.)** | **none** |
**What the previous model did (concrete):** instead of a structured call it wrote prose such as
`**Action 1:** Task(GHOST…)`, then invented its own tool output — fake `curl` / SSL handshakes /
Nmap scans / `Set-Cookie: sessionid=abc…` and even fabricated flags — and never terminated, in
**both** bf16 and q8. It *looked* like it was working (it narrated a whole engagement) while
executing nothing. This is the exact behaviour behind the user reports.
**What this model does:** emits a genuine `<tool_call><function=Task>` with a valid archetype
(e.g. `web-application`, `explore`) and terminates with `<|im_end|>`. The base model *does* emit
calls, but routes with internal codenames ("GHOST") rather than valid archetypes — the routing this
fine-tune specifically corrected.
### What the 24 scenarios tested
Six axes, each at easy → medium → hard difficulty, weighted 62% toward out-of-distribution prompts
(unseen target names, novel phrasing) to separate genuine generalization from memorized patterns:
| Axis | What it checks |
|---|---|
| **Tool selection** | picks the right tool for the phase; prefers dedicated tools over `bash` equivalents |
| **Argument typing** | emits correct types — `steps` stays an int `50`, `headless` stays a bool `true` |
| **Real-observation handling** | reads an actual tool result and acts on it; on empty/unexpected output it pivots instead of fabricating |
| **Loop / termination** | stops when the task is done; no runaway or crash on multi-step tasks |
| **Sub-agent delegation** | delegates to the correct archetype; does not invent agent names |
| **Parallel tool calls** | batches independent work; does not spam hundreds of calls |
The two axes the previous model collapsed on hardest — real-observation handling (it fabricated) and
termination (it looped) — are the two this model scores cleanest on.
The previous model has been **withdrawn** from active serving: its broken merged weights were
**removed** from this repo, and its GGUF build was **gated** with a deprecation notice, so new users
don't unknowingly pull the broken version.
---
## Serving
`main` is the **single-piece merged checkpoint**; the LoRA adapter alone (169 MB) is on the
`adapter` revision.
### ✅ Default — Python (verified)
The one-command load below was verified on this hardware: the merged checkpoint loads and, on the
tested scenarios, emits genuine structured tool calls and terminates cleanly.
```python
from transformers import AutoModelForImageTextToText, AutoTokenizer
model = AutoModelForImageTextToText.from_pretrained("oyildirim/CyberStrike-OffSec-35B")
tok = AutoTokenizer.from_pretrained("oyildirim/CyberStrike-OffSec-35B")
```
Pass the tools via `tok.apply_chat_template(messages, tools=TOOLS, add_generation_prompt=True)`; the
model emits Qwen3 XML tool calls (`<tool_call><function=…><parameter=…>`).
### ⚙️ vLLM (single-piece merged) — not verified on this hardware
```bash
vllm serve oyildirim/CyberStrike-OffSec-35B \
--enable-auto-tool-choice --tool-call-parser qwen3_xml --max-model-len 8192
```
> **Caveat — unverified.** This model's architecture (`qwen3_5_moe`) is only supported by recent vLLM
> (0.25.1+), which requires a **CUDA-13-compatible** build/driver. It could not be run on our test
> hardware (CUDA 12.8). The `qwen3_xml` parser and schema-driven typing (`steps`→int, `headless`→bool)
> were verified in isolation, but the end-to-end vLLM serve was **not** verified here. Expected to
> work on a CUDA-13-capable box; confirm on your setup before relying on it.
### ⚙️ Adapter — base + LoRA (`@adapter` revision)
For keeping the base pristine or stacking adapters. Python (verified path):
```python
from transformers import AutoModelForImageTextToText
from peft import PeftModel
base = AutoModelForImageTextToText.from_pretrained("Qwen/Qwen3.6-35B-A3B")
model = PeftModel.from_pretrained(base, "oyildirim/CyberStrike-OffSec-35B", revision="adapter")
```
vLLM equivalent (same CUDA-13 caveat as above):
```bash
vllm serve Qwen/Qwen3.6-35B-A3B --enable-lora \
--lora-modules cyberstrike=oyildirim/CyberStrike-OffSec-35B@adapter \
--enable-auto-tool-choice --tool-call-parser qwen3_xml --max-model-len 8192
```
> **Do not** call `AutoModelForImageTextToText.from_pretrained(...@adapter)` directly on the adapter
> revision — load base + adapter as shown. **Always pass the full tool schema at inference** (see
> *Known fragilities*).
---
## Known fragilities (read before deploying — no "broken" surprises)
On the representative 24-scenario suite the merged model has **0/24** non-termination. It has one
**narrow** out-of-suite trigger: a *terse recon prompt with a minimal (single-tool) schema* — e.g.
"Do passive recon on X" when only the `Task` tool is offered — can send greedy decoding into a
repetition loop inside the tool-call `prompt` field. **Changing the phrasing OR passing the full
tool set makes it clean**, and production serving always passes the full tool set, so this rarely
occurs in practice. Mitigations if you hit it: keep the full tool schema, and/or set
`repetition_penalty ≈ 1.1` or a hard stop token.
Also observed on out-of-distribution inputs: occasional tool over-generalization and a rare invalid
sub-agent name. All of the above are targets for the next data iteration (Stage-2).
---
## Training
LoRA **r=32 / α=64**, targets = full-attention (q/k/v/o) + **GDN linear-attention
(in_proj_\*/out_proj)** + MLP — **310 modules, 42.3 M trainable params**. Routed experts, the MoE
router, and the vision tower are excluded (routing and multimodal behaviour left intact). 300
multi-turn tool-call SFT examples, 3 epochs, sdpa attention. Held-out token accuracy 98.5%.
Merge is verified correct layer-by-layer (uniform ~0.0016 bf16 rounding error across all groups
including the GDN layers; no merge bug).
---
## Intended use & limitations
For authorized offensive-security testing and research only. The model reasons about attack
methodology and emits tool calls for a pentesting harness; it does not itself execute anything.
Users are responsible for operating only against systems they are authorized to test. Not a
substitute for a qualified security professional.

Xet Storage Details

Size:
9.41 kB
·
Xet hash:
9b1b24c21de1ff505f97726ae21437183908a667e7745dae022494b39addbb76

Xet efficiently stores files, intelligently splitting them into unique chunks and accelerating uploads and downloads. More info.