apxi/qwen3-5-0-8b-security-triage-v4-7-gguf

Qwen3.5 0.8B Security Triage v4.7 GGUF

This repository contains GGUF exports of a fine-tuned unsloth/Qwen3.5-0.8B checkpoint for the AI Security Log Triage Assistant proof of concept.

The model is designed to analyze one security log line and return a structured JSON triage result: whether the log looks normal or suspicious, the most likely activity pattern, evidence copied from the log, severity, a short reason, and the next investigation action.

This is a triage assistant, not an incident-confirmation system. Its output should be treated as an investigation aid for analysts.

Files

File	Use
qwen3-5-0-8b-security-triage-v4-7-q4_k_m.gguf	Recommended local inference file. Smaller, practical default for llama.cpp-compatible runtimes.
qwen3-5-0-8b-security-triage-v4-7-f16.gguf	Full F16 GGUF export for users who want the unquantized GGUF artifact.
SHA256SUMS	SHA-256 checksums for the GGUF files.

Intended Use

The model is scoped to a small security-log triage taxonomy:

• normal
• failed_login_bruteforce
• sql_injection_attempt
• directory_traversal_attempt
• port_scan_or_recon

Use it for experiments, evaluation, demos, and local proof-of-concept workflows where a structured JSON response is more important than open-ended explanation.

Do not use this model as the sole source of truth for production security decisions. It has a narrow label set and was trained for a POC workflow.

Prompt Format

The training and adapter path used prompt version triage-json-v2.1. A good inference prompt should tell the model to return only one JSON object and should include exactly one log line.

Minimal prompt:

You are a security log triage assistant.
Analyze exactly one security log input and classify it for investigation.
Use triage language only. Do not claim that a system is compromised.
Return only one valid JSON object.
Do not include markdown, code fences, comments, or explanatory text outside JSON.
Do not add fields beyond the required schema.

Analyze this security log and classify whether it is suspicious.
Respond with the JSON object only.

Log:
<put one log line here>

For strict JSON in an automated pipeline, use runtime-side JSON schema or grammar constraints when your inference runtime supports them, then validate the result against the contract below.

JSON Output Contract

The model should return a raw JSON object with exactly these six fields:

{
  "label": "sql_injection_attempt",
  "severity": "high",
  "is_suspicious": true,
  "evidence": ["admin%27%20OR%20%271%27=%271"],
  "reason": "The request contains a SQL injection tautology in a login parameter.",
  "recommended_action": "Review web application logs for the source IP and block or rate-limit repeated payload attempts."
}

Schema rules:

Field	Type	Required	Rules
label	string enum	yes	Must be one of the five labels listed below.
severity	string enum	yes	Must be one of low, medium, high, or critical.
is_suspicious	boolean	yes	Use false only for normal; use true for every other label.
evidence	string array	yes	Must contain 1 to 3 short exact substrings copied from the input log. Each item must be 1 to 160 characters. Do not invent evidence.
reason	string	yes	Short explanation of why the label was selected.
recommended_action	string	yes	Concrete next step for an analyst to investigate or de-prioritize the event.

The output contract disallows extra fields. Do not add fields such as confidence, attack_type, mitre_id, raw_log, or metadata unless your downstream schema has been changed to accept them.

Label Reference

Label	Meaning	Typical Evidence
normal	Routine or expected activity with no clear suspicious pattern in this taxonomy.	GET /health 200, successful routine request, normal service check.
failed_login_bruteforce	Repeated failed authentication suggesting password guessing or brute force behavior.	failed password, invalid user, many 401 or 403 responses, repeated attempts from the same source.
sql_injection_attempt	Input contains SQL injection indicators.	' OR '1'='1, UNION SELECT, --, sleep(, information_schema.
directory_traversal_attempt	Request tries to access files outside the intended directory.	../, ..%2f, %2e%2e%2f, /etc/passwd, win.ini.
port_scan_or_recon	Activity suggests scanning, probing, enumeration, or reconnaissance.	nmap, masscan, SYN scan, many destination ports, repeated probe paths.

Severity Guidance

Label	Default Severity
normal	low
failed_login_bruteforce	medium, or high when repeated failure volume is clearly large.
sql_injection_attempt	high
directory_traversal_attempt	high
port_scan_or_recon	medium, or high when scanning is explicit, broad, or touches sensitive services.

Use critical only when the log itself contains strong evidence of successful impact, not merely because the pattern looks severe.

Example

Input log:

192.168.1.20 - - [10/May/2026:13:45:00 +0700] "GET /login?user=admin%27%20OR%20%271%27=%271 HTTP/1.1" 200

Expected output shape:

{
  "label": "sql_injection_attempt",
  "severity": "high",
  "is_suspicious": true,
  "evidence": ["admin%27%20OR%20%271%27=%271"],
  "reason": "The login parameter contains a SQL injection tautology pattern.",
  "recommended_action": "Review related web requests from the source IP and check whether the login endpoint handled the payload safely."
}

llama.cpp Example

llama-cli \
  -m qwen3-5-0-8b-security-triage-v4-7-q4_k_m.gguf \
  --temp 0 \
  --ctx-size 1024 \
  -p 'You are a security log triage assistant.
Analyze exactly one security log input and classify it for investigation.
Use triage language only. Do not claim that a system is compromised.
Return only one valid JSON object.
Do not include markdown, code fences, comments, or explanatory text outside JSON.
Do not add fields beyond the required schema.

Analyze this security log and classify whether it is suspicious.
Respond with the JSON object only.

Log:
192.168.1.20 - - [10/May/2026:13:45:00 +0700] "GET /login?user=admin%27%20OR%20%271%27=%271 HTTP/1.1" 200'

Training And Export Details

• Base model: unsloth/Qwen3.5-0.8B
• Fine-tuning method: LoRA / QLoRA-style Unsloth training
• LoRA rank: 16
• LoRA alpha: 16
• Target modules: q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj
• Prompt version: triage-json-v2.1
• Max sequence length: 1024
• Training split: train-v4-7-qwen35-auth-sqli-severity-calibration.jsonl (1460 records)
• Validation split: validation-v4-7-qwen35-auth-sqli-severity-calibration.jsonl (130 records)
• GGUF export: merged checkpoint converted with MTP disabled because this checkpoint has 24 transformer layers and no extra MTP tensors.

Evaluation Snapshot

These metrics came from the project evaluation harness before GGUF packaging, using an OpenAI-compatible/vLLM structured-output path. They are useful as development signals, not as a production benchmark.

Split / Probe	Samples	Label Accuracy	JSON Parse	Schema Success	Severity Accuracy	Evidence Partial Match	Invalid Outputs
Hard-contrast probe	50	0.92	1.00	1.00	0.92	1.00	0
v4.7 auth/SQLi/severity calibration probe	30	0.366667	1.00	1.00	0.60	1.00	0

Important caveats:

• The fixed test split was intentionally held for this v4.7 artifact.
• Raw GGUF generation may vary by runtime, chat template, sampling parameters, and whether JSON grammar constraints are used.
• The model still showed weakness on benign authentication negatives and auth-context SQL injection calibration examples.

Checksums

29d6af51eb3ab77ce772194e633144b45032d72953f5c2310126342e5f25edf8  qwen3-5-0-8b-security-triage-v4-7-f16.gguf
77e49acd253c7f927c9e53b3eccc54873fa3d126e8e6432931841483d0f17475  qwen3-5-0-8b-security-triage-v4-7-q4_k_m.gguf

Limitations

• Narrow taxonomy: only the five labels listed above are supported.
• Synthetic/POC training data: results may not transfer to real SOC logs without more evaluation.
• Triage only: the model recommends investigation, but does not prove compromise.
• JSON should still be validated downstream. For reliable automation, combine the model with constrained decoding, schema validation, and retry/fallback handling.