AI-Powered Ethical Hacking (GitHub + Agent Skills), Part 4: Using AI for Defense, Triage and Reporting
Series: AI-Powered Ethical Hacking (GitHub + Agent Skills), Part 4. Previous: Part 3, agent skills and scope first prompts. Start: Part 1, AI meets Kali. Next: Part 5, retest checklists, evidence folders and a reporting skill.
Once your lab notes are full of scan output, the slow part is turning them into a clear fix list and a short report. This post shows how to use a local model to summarise findings you already collected, write manager ready wording, and keep sensitive details off cloud models.
First, the legal bit
Disclaimer: This post is for education and authorized security testing only. Scanning, auditing or accessing a computer, network or account without permission is illegal, including under India’s Information Technology Act, 2000 and similar laws in other countries. Only work with notes and tool output from systems you own, or systems where you have clear written permission from the owner before you start.
Everything below assumes your findings came from your own practice target on a closed lab network, the kind of setup in the Kali Linux safe practice lab and in Part 2 with local Ollama. If a host or file is not yours, leave it alone. Do not paste live customer data, production credentials or real employee names into any model.
Where does AI save real time?
Finding open ports is often the faster half of the job. The slower half is reading tool output, ranking what matters, and writing something a non technical reader can act on.
A local language model helps with three chores that eat evenings:
- Triage. Turn a long notes file into a short ranked list.
- Wording. Rewrite technical notes into plain sentences a manager can skim.
- Consistency. Apply the same report shape every week.
My day job sits close to network detection and response, so I care more about a one page list someone can fix by Friday than about flashy agent demos. AI is a writing and sorting assistant here. It is not a substitute for reading the raw tool files yourself, which Part 3 covered when you check every claim against real output.
Before you give any agent more access, read how OpenAI, AISI and CERT-In now think about containing AI agents.
Logs are the other place it saves time, and I show how to triage lab logs and write a detection rule with a local model.
How do you summarise your own findings safely?
Prerequisites
- Lab notes from a session you already ran on systems you own (raw Nmap files, listener lists, or a short findings file). The steps below assume a plain text file called
findings-raw.txtin that day’s notes folder. - Local Ollama from Part 2, ideally v0.40.7 or newer, with a small chat model such as
qwen3:4b. - A folder for today’s work:
mkdir -p ~/lab-notes/$(date +%F)/reporting
cd ~/lab-notes/$(date +%F)/reporting
Copy only files from your own lab notes into this folder. Do not copy production exports.
Step 1: Build a redacted input file
Before any model sees your notes, strip secrets and live identifiers. Keep the technical facts. Drop anything that could identify a real person, customer or production host.
# Start from a findings file you already wrote by hand
cp ~/lab-notes/$(date +%F)/findings-raw.txt ./findings-redacted.txt
# Replace obvious secrets with placeholders (edit the file by hand after)
sed -i \
-e 's/[A-Za-z0-9._%+-]\+@[A-Za-z0-9.-]\+\.[A-Za-z]\{2,\}/[REDACTED_EMAIL]/g' \
-e 's/\b[A-Za-z0-9+/]\{20,\}\b/[REDACTED_TOKEN]/g' \
./findings-redacted.txt
Open the file and replace real hostnames with labels like lab-web-01, and replace passwords or API keys with [REDACTED]. The model only needs ports, services and your severity notes. Then print it to check:
cat findings-redacted.txt
Expected output (sample, fake lab data):
Target: lab-web-01 (authorized practice VM)
Open: tcp/22 ssh, tcp/3000 http-ish
Note: service on 3000 answers with a default page; no auth checked yet
Listener on Kali itself: ssh on 0.0.0.0:22
Step 2: Ask the local model to triage, not to attack
Keep the model offline. Ollama’s FAQ (checked 23 Oct 2026) says that when you run a model locally, they do not see your prompts or data. Prefer that path for any security note.
Save this prompt as triage-prompt.txt (copy it as written):
You are helping me write a defensive triage note from my own authorized lab findings.
Do not suggest scanning, exploiting or contacting any host.
Only summarise and prioritise what is already in the NOTES block.
Return exactly three sections:
1) Top risks (max 5 bullets). Each bullet: finding, why it matters in one line, suggested fix owner (me / platform / unknown).
2) Quick wins (things I can fix today).
3) Needs more evidence (claims I should re-check against raw tool output).
NOTES:
Then send the prompt and your redacted notes to the local model in one go, and save the reply:
ollama run --hidethinking qwen3:4b "$(cat triage-prompt.txt findings-redacted.txt)" > triage-summary.txt
cat triage-summary.txt
Passing the prompt as one argument avoids a common snag: if you paste several lines into the interactive ollama run chat, each line is sent on its own unless you wrap the text in triple quotes ("""), according to Ollama’s CLI docs. The --hidethinking flag keeps qwen3’s thinking text out of your saved file.
Expected output (sample report text, not from a real engagement):
1) Top risks
- lab-web-01 tcp/3000 open with a default page: unknown app surface; owner me; confirm what listens and whether it should bind to localhost only.
- Kali ssh on 0.0.0.0:22: reachable from any host that can route to the VM; owner me; restrict to the lab network if you do not need remote shell.
2) Quick wins
- Document which services must stay listening.
- Re-read the raw Nmap .gnmap line and mark each port matched or wrong.
3) Needs more evidence
- "http-ish on 3000" is a guess; confirm with the saved scan file, not with a new scan outside the lab.
If the model invents a host, a CVE or a command you did not provide, discard that line. Trust your files first.
Step 3: Check the triage file sits next to your notes
pwd
ls -l findings-redacted.txt triage-prompt.txt triage-summary.txt
Expected output: pwd prints a path ending in today’s date and /reporting, and ls lists all three files. Open triage-summary.txt and delete any line the model invented before you move on.
How do you write a report a manager can read?
Managers rarely want tool dumps. They want what matters, how bad it is, and who owns the fix. Keep the report to one page.
Step 4: Turn the triage into a manager note
Save this second prompt as manager-prompt.txt:
Rewrite the triage below as a one page status note for a non technical manager.
Rules:
- No exploit steps, no scan commands, no tool flags.
- Use plain English.
- Sections: Context (2 sentences), Findings (table style bullets), Ask (what I need from them).
- Mark every item as High, Medium or Low using only evidence in the notes.
- If evidence is thin, say "needs confirmation" instead of guessing.
TRIAGE:
Run it on your cleaned triage file:
ollama run --hidethinking qwen3:4b "$(cat manager-prompt.txt triage-summary.txt)" > manager-note.txt
cat manager-note.txt
Expected output (sample, fake):
Context
Notes reviewed from an authorized practice lab on 23 Oct 2026. Goal: list what is exposed and what to harden first.
Findings
- Medium: practice web VM exposes port 3000 with a default page. Confirm the service and bind it only where needed.
- Medium: Kali SSH listens on all interfaces. Limit SSH to the lab network.
- Low: notes still need a second pass against the raw scan file.
Ask
Approve thirty minutes this week to close the two Medium items and file the updated notes.
Step 5: Edit by hand
Read it out loud. Cut any sentence that scares without helping someone act. If a severity has no evidence, drop it or mark “needs confirmation”.
What never goes into a cloud model?
Local models are the default for this series for a reason. Cloud chat products and cloud hosted model APIs receive whatever you paste. Treat that paste as leaving your machine.
Never paste into a cloud model:
- Passwords, API keys, session cookies or private keys
- Real customer names, employee names, emails or phone numbers
- Production hostnames, internal URLs or VPN profiles
- Full packet captures, memory dumps or raw authentication logs
- Screenshots with badges, desk locations or other workplace details
- Anything covered by an NDA or a client engagement letter
Ollama’s privacy policy (last updated March 2026, checked 23 Oct 2026) and FAQ say local runs keep prompts and responses on your machine, while cloud hosted models process prompts to provide the service. Their docs also describe a local only mode (disable_ollama_cloud in ~/.ollama/server.json, or OLLAMA_NO_CLOUD=1). Treat those as the vendor’s claims, and still redact before you paste.
If you need a stronger cloud model for wording only, paste a fully synthetic example (fake hosts, fake ports, no real org names), never the real notes. For watching what an LLM app sends and logs, see my LLM observability guide for 2026.
What to do next
Your plan for this week:
- Pick one dated lab notes folder you trust and create a
reportingsubfolder. - Redact a copy by hand until no real emails, tokens or production names remain.
- Run the triage prompt on local Ollama, then the manager note prompt.
- Compare both replies with the raw tool files and delete invented claims.
- Keep cloud models out of this workflow unless the paste is fully synthetic.
- Browse the security GitHub repos roundup for October 2026 for more defensive tools to study.
Keep the model as a clerk for your own notes, not as an operator against anything you do not own. Next, I turn this fix list into something I can check later: a retest checklist, an evidence folder and a reusable reporting skill.
Leave a comment