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. Every number below is grounded in raw model output, not auto-scored heuristics.

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:

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.

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

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):

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):

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.