we wanted a 4b model that could inspect an unfamiliar network, find the things that mattered, and repair them without wandering outside its scope. after two training experiments, we got very close. one model learned a reliable network-inventory workflow, and another learned to produce small, validated infrastructure patches.
with a bigger, smarter model, we may be able to let it operate autonomously. these 4b versions did not clear that bar.
tl;dr
- we trained
Qwen3.5-4Bin two deterministic security environments: a boundedTCPnetwork simulator and a sandboxed infrastructure repair task. - the scan planner’s first-try success rate on unseen tasks rose from 45.83% to 79.17%. within two tries, it reached 100%. it sent zero packets: all training happened in a simulator.
- the patch agent’s success rate on unseen tasks rose from 42.34% to 86.25%, while unsafe final responses fell from 15% to 1.875%.
- both experiments still failed our autonomy bar. the scanner ignored the required response format, and the patcher produced 12 unsafe final responses across 640 unseen attempts.
giving an llm a network to break
the reckless version of this project is easy to imagine: give a model Nmap, point it at a
subnet, then let it edit whatever looks vulnerable. a model can look competent while scanning
the wrong target or writing a plausible fix that breaks something unrelated.
we split the problem into two environments with hard boundaries.
the first is a network simulator. the model can discover hosts, inspect open ports, identify services, and verify findings. every task defines exactly which addresses it may inspect and how much work it may do. requests outside that boundary are rejected before anything happens. the simulator never opens a socket or sends a packet.
the second environment gives the model insecure Kubernetes and Terraform files. it can propose edits and run checks against them, but it cannot deploy anything, invoke a shell, or access cloud credentials. every patch remains a proposal for human review.
both environments follow the same rule: the model can explore, while authorization and verification stay outside the model.
training it to scan and patch reliably
our first scan run used 64 training tasks and 24 unseen tasks. it succeeded on the first try 45.83% of the time and within two tries 62.5% of the time, but the model repeatedly got stuck. 217 attempts ran until the turn limit instead of producing a final answer.
the model understood each tool call in isolation. it struggled with the full sequence:
discover the network, inspect the useful services, gather enough evidence, then stop. when it
did finish, it often wrapped the report in prose instead of returning the exact JSON shape
we required.
we gave it eight verified worked examples covering 34 individual actions. those examples were used only during training and never appeared in the unseen tasks. after three passes through the training set, the model became much better at choosing the next step and knowing when it was done.
the patch experiment followed the same approach with 320 training tasks. each proposed patch had to pass real checks: did it fix the security issue, remain valid, preserve existing behavior, stay within the requested file, and avoid unnecessary changes? we then evaluated 640 unseen attempts.
the model learned to produce correct files more reliably than correct explanations. some patches passed every check, but the final response still repeated sensitive infrastructure details or included the old configuration in its rollback instructions. checking the file alone would have missed that.
results, failures, and what’s next
the second scan run succeeded on the first try 79.17% of the time and within two tries 100% of the time. after the fifth training step, it stopped hitting the turn limit entirely.
| scan policy | first try | within two tries | attempts stuck at turn limit |
|---|---|---|---|
| first run | 45.83% | 62.5% | 217 |
| with worked examples | 79.17% | 100% | zero after step 5 |
this shows that the model learned the workflow inside our simulator. live network behavior remains untested, and the model still ignored the exact response format. a strict parser and verifier would be required around it.
the patch agent learned too. from the first to the final evaluation on unseen tasks, unsafe responses fell from 15% to 1.875%, success rose from 42.34% to 86.25%, and average tool use fell from 6.32 to 5.90 calls.
| patch policy | first evaluation | final evaluation |
|---|---|---|
| unsafe final response | 15% | 1.875% |
| successful workflow | 42.34% | 86.25% |
| average tool calls | 6.32 | 5.90 |
more broadly, these results show that open-weight models can generalize to specialized cybersecurity tasks when given the right environment, feedback, and verification. we’re seeing more cybersecurity teams explore continually learning agents that validate systems, find vulnerabilities across an organization, and improve from each review.
if you’re building one, reach out. we’d love to work with you.