AI-Powered Ethical Hacking (GitHub + Agent Skills), Part 2: Fully Local AI With Ollama and MCP
Series: AI-Powered Ethical Hacking (GitHub + Agent Skills), Part 2. Previous: Part 1, how MCP and agents fit into ethical hacking. Next: Part 3, agent skills and scope first prompts for lab recon.
Yes, you can run AI with Kali fully offline. Ollama runs a small model with tool support on your own GPU, mcp-kali-server exposes Kali tools on localhost, and the 5ire desktop client connects the two. You keep approval on for every tool call and the VM on a host only network, so the agent stays inside your lab.
First, the legal bit
Disclaimer: This post is for education and authorized security testing only. Accessing or scanning a computer, network or account without permission is illegal, including under India’s Information Technology Act, 2000 and similar laws in other countries. An AI agent acting for you does not change that: you are responsible for every command it runs. Only test systems you own, or systems where you have clear written permission from the owner before you start.
Everything below targets your own isolated lab, or a legal practice platform such as TryHackMe or Hack The Box.
Why run AI for Kali locally?
Kali’s guide states the goal plainly: do everything locally and offline, on your own hardware, without relying on any third party service (Kali, 10 Mar 2026).
Privacy for your scan data
Scan output describes a network in detail: hostnames, open ports, software versions. Even in a lab, it’s good practice to treat that as sensitive. When the model runs on your machine, that data never leaves it.
No accounts, no API bills
A local setup needs no sign up and no pay as you go charges. The cost moves to hardware instead, and the Kali team is honest that local models are hardware hungry, so the real cost is buying and running the machine.
It works offline
Once the models are downloaded, the lab can run with no internet at all. That fits nicely with the isolated host only network we built in Part 1 of my Kali Linux Ethical Hacking series.
What hardware and model size do you need?
This is where most people get stuck, so let’s keep it simple.
What Kali used
The guide’s test machine had an NVIDIA GeForce GTX 1060 with 6 GB of video memory. The team installed NVIDIA’s proprietary driver, because the open source nouveau driver lacks CUDA support, then confirmed it with nvidia-smi after a reboot. They note that AMD and Intel GPUs were out of scope for that guide (Kali, 10 Mar 2026).
Picking a model that fits
The rule of thumb from the guide: your hardware decides how big a model you can run. With 6 GB of VRAM, they chose three smaller models and listed their download sizes:
llama3.1:8bat 4.9 GBllama3.2:3bat 2.0 GBqwen3:4bat 2.5 GB
Why “Tools” support matters
The guide stresses that the model must support “Tools”. That is the feature that lets the model ask the MCP server to run something. A model without it can chat, but it can’t act. When you browse models on Ollama.com or Hugging Face, look for tool support first.
How do you connect Ollama, an MCP client and Kali?
There are three pieces. Here’s each one, with versions I checked on 21 October 2026.
Piece 1: Ollama runs the model
Ollama loads and serves local models. Kali’s guide used v0.15.2, the latest at the time of writing in January. Today the latest release on GitHub is v0.40.7, published 18 October 2026 (UTC), checked via the GitHub API on 21 Oct 2026. Expect some things to look different from the guide.
The guide also avoids the common curl | bash installer. It downloads the release archive, checks its SHA512 hash, extracts it and creates a dedicated ollama system user and a systemd service. I like that approach: you see what you install, and the service runs without root. After setup, a quick check:
ollama -v
ollama pull qwen3:4b
ollama run qwen3:4b
ollama ps
ollama ps shows which model is loaded and whether it is running on the GPU.
Piece 2: mcp-kali-server exposes the tools
Kali packages its MCP server as mcp-kali-server. On the Kali package tracker (checked 21 Oct 2026), kali-rolling has 0.0~git20260317.00154c0-0kali2, with a newer packaging revision 0kali3 accepted into kali-dev on 20 October 2026.
The guide started from a fresh minimal Kali install with no tools, and installed the MCP server along with a long list of tools. For a recon focused lab, I’d start small with just the server and Nmap:
sudo apt update
sudo apt install -y mcp-kali-server nmap
kali-server-mcp
The server starts on 127.0.0.1:5000, the local machine only. In a second terminal, mcp-server connects to it, runs a health check and looks for the tools it expects. In Kali’s run, it checked for nmap, gobuster, dirb and nikto. If you skip some of them, it may warn you, and that’s fine. Fewer tools means fewer things the agent can do, which is a sensible limit while learning.
Piece 3: 5ire is the MCP client
Ollama doesn’t speak MCP on its own, the guide explains, so you need a client to bridge the two. Kali used 5ire, a desktop AI assistant and MCP client. The guide used the 0.15.3 AppImage. The latest release on GitHub today is v0.15.4, from 18 March 2026 (checked via the GitHub API, 21 Oct 2026). As noted in Part 1, GitHub doesn’t detect a standard license for 5ire, so read its license file before any work use.
The guide’s install steps are simple: download the AppImage, check its SHA512 hash, move it into /opt/5ire/, make it executable, add a menu entry, and install libfuse2t64 so AppImages can run.
Connecting them in 5ire
The guide then sets things up in the 5ire interface:
- Under Workspace, then Providers, enable Ollama and turn on “Tools” and “Enabled” for each model.
- Under Tools, then Local, add a server named mcp-kali-server with the command
/usr/bin/mcp-server, and enable it. - Choose an Approval Policy. The guide leaves this up to you.
My advice on step 3 is to require approval for every tool call while you learn. You’ll see each command before it runs, which is the single best guardrail you have.
How do you set it all up, step by step?
Here is the full build in order. Run every command inside your Kali VM unless a step says otherwise. Versions are as checked on 21 October 2026.
What you need before you start
- A Kali 2026.2 VM or install on a host only lab network, as built in Part 1 of my Kali Linux Ethical Hacking series.
- An NVIDIA GPU with about 6 GB of video memory passed through to Kali, or Kali installed directly on the hardware. Without a GPU, Ollama falls back to the CPU and is much slower.
- Internet access through a NAT adapter for the installs only. You’ll switch it off in Step 9.
- One practice target on the lab network, for example Juice Shop at
192.168.56.101. Use your own address.
Step 1: Install the NVIDIA driver and check it
Kali’s guide installs the proprietary driver together with the latest kernel and headers (Kali, 10 Mar 2026):
sudo apt update
sudo apt install -y linux-image-$(dpkg --print-architecture) linux-headers-$(dpkg --print-architecture) nvidia-driver nvidia-smi
sudo reboot
After the reboot:
nvidia-smi
Expected output: a table naming your GPU, the driver version and its memory, for example 6144MiB total on a 6 GB card. If you see “command not found” or no GPU, fix the driver before going on.
Step 2: Download Ollama v0.40.7 and check the hash
sudo apt install -y curl zstd
curl --fail --location https://github.com/ollama/ollama/releases/download/v0.40.7/ollama-linux-amd64.tar.zst -o /tmp/ollama-linux-amd64.tar.zst
file /tmp/ollama-linux-amd64.tar.zst
sha512sum /tmp/ollama-linux-amd64.tar.zst
Expected output: file reports Zstandard compressed data, and sha512sum prints a long hash. Keep that hash in your notes so you can compare it with any future download.
Step 3: Install Ollama as its own service user
These steps follow the method in Kali’s guide, which runs Ollama as an unprivileged ollama user:
sudo tar x --zstd -C /usr -f /tmp/ollama-linux-amd64.tar.zst
sudo useradd -r -s /bin/false -U -m -d /usr/share/ollama ollama
sudo usermod -a -G ollama $(whoami)
cat <<'UNIT' | sudo tee /etc/systemd/system/ollama.service >/dev/null
[Unit]
Description=Ollama Service
After=network-online.target
[Service]
ExecStart=/usr/bin/ollama serve
User=ollama
Group=ollama
Restart=always
RestartSec=3
[Install]
WantedBy=multi-user.target
UNIT
sudo systemctl daemon-reload
sudo systemctl enable --now ollama
ollama -v
Expected output: a “Created symlink” line from systemd, then ollama version is 0.40.7.
Step 4: Pull a small model with tool support
ollama pull qwen3:4b
ollama list
Expected output: a download progress bar, then a table listing qwen3:4b at roughly 2.5 GB, the size Kali’s guide reported.
Quick test:
ollama run qwen3:4b "Reply with the single word: ready"
ollama ps
Expected output: the model replies (it may show some “thinking” text first), and ollama ps shows qwen3:4b with a processor column such as 100% GPU.
Step 5: Install the MCP server and Nmap only
sudo apt install -y mcp-kali-server nmap
apt policy mcp-kali-server | head -3
Expected output: an installed version of 0.0~git20260317.00154c0-0kali2 or newer, matching the Kali package tracker on 21 Oct 2026.
Step 6: Start the server and confirm it is local only
Terminal 1:
kali-server-mcp
Terminal 2:
ss -ltn | grep 5000
Expected output: Terminal 1 says it is starting the Kali Linux Tools API Server on 127.0.0.1:5000. Terminal 2 shows a LISTEN line for 127.0.0.1:5000. If it shows 0.0.0.0:5000, stop and fix that first.
Step 7: Install 5ire v0.15.4
curl --fail --location https://github.com/nanbingxyz/5ire/releases/download/v0.15.4/5ire-0.15.4-x86_64.AppImage -o 5ire-x86_64.AppImage
sha512sum 5ire-x86_64.AppImage
sudo mkdir -p /opt/5ire
sudo mv 5ire-x86_64.AppImage /opt/5ire/
sudo chmod 0755 /opt/5ire/5ire-x86_64.AppImage
sudo ln -sf /opt/5ire/5ire-x86_64.AppImage /usr/local/bin/5ire
sudo apt install -y libfuse2t64
5ire &
Expected output: a hash for your notes, then the 5ire window opens.
Step 8: Connect 5ire to Ollama and the MCP server
- Workspace, then Providers, then Ollama: toggle Default on, then for
qwen3:4bswitch on Tools and Enabled, and Save. - Tools, then Local: Name
mcp-kali-server, DescriptionMCP Kali Server, Command/usr/bin/mcp-server, Approval Policy set to ask every time. Save, then enable it.
Expected result: the tool shows as enabled, and the kali-server-mcp terminal logs a health check request.
Step 9: Cut the internet and run a scoped test
Switch off Kali’s NAT adapter (in VirtualBox, with the VM off: VBoxManage modifyvm "<kali vm name>" --nic1 none on your computer). Start Kali, start Ollama and kali-server-mcp again, open 5ire and paste:
You are helping with a security lab I own.
Scope: 192.168.56.101 only. Refuse any other host, range or domain.
Before each tool call, show the exact command and wait for my approval.
Task: scan the top 100 TCP ports on 192.168.56.101 with nmap.
Show the raw output first, then a short summary that quotes the lines it relies on.
Expected behaviour: 5ire asks you to approve one Nmap call against 192.168.56.101 only. After approval, the command appears in the kali-server-mcp terminal, and the reply shows raw Nmap output, for example 3000/tcp open ppp for Juice Shop (Nmap guesses the name from the port number). The summary should quote those lines. If any other address appears, deny it.
How do you keep the agent inside your lab network?
Local doesn’t automatically mean safe. The model is on your machine, but the tools it calls can still send packets anywhere your Kali VM can reach.
Change the test target
Kali’s guide tested the setup with a port scan of scanme.nmap.org. For this series, I’d point your first prompt at a target in your own lab instead, such as an OWASP Juice Shop VM on your host only network. That way the whole loop stays inside walls you built. If you haven’t scanned your lab by hand yet, do that first with my Nmap recon guide, so you know what the agent should find.
Put the scope in the prompt
Start each chat with something like: “You may only scan 192.168.56.101. Refuse any other address.” Replace the address with your own lab target. Then read every proposed command before approving it.
Limit the network itself
Prompts can be misread, so add a hard limit too. Keep Kali on a host only network while the agent is running. If Kali has no route to the internet or your home network, a confused model can’t reach them.
Watch the logs
kali-server-mcp prints every command it executes. Keep that terminal visible. My day job sits close to network detection and response, and the habit carries over: if you can’t see what ran, you can’t explain it later.
For why this boundary matters beyond a test network, see my piece on the four walls of AI agent containment.
What to do next
Your plan for this week:
- Read Kali’s local guide in full, noting where versions have moved on.
- Check your GPU and its video memory, and pick one small model with tool support.
- Install Ollama from a download whose checksum you have checked and confirm it with
ollama ps. - Install only
mcp-kali-serverandnmap, and runkali-server-mcpon localhost. - Install 5ire, connect it to Ollama and the MCP server, and set approval for every tool call.
- Ask the agent to scan only your own lab target, then compare its summary with the raw Nmap output.
In Part 3 of AI-Powered Ethical Hacking (GitHub + Agent Skills), we’ll write small, repeatable agent instructions for lab recon, and learn to check every claim the model makes against real tool output. It’s live now: Agent Skills and Scope First Prompts for Lab Recon.
Once my local Ollama setup is running, I also use it to summarise lab findings without sending anything to the cloud, and I walk through that in AI defense triage and reporting.
Once Ollama is running, you can use it to write a retest checklist for your own lab findings without sending notes to the cloud.
Leave a comment