Why Kali's New AI Pentest Stack Won't Touch a Cloud API

Kali recently released a guide for running an AI-assisted pentest stack on your own hardware, and it's worth a look. Ollama runs an open-weight model locally. On top of that, mcp-kali-server sits on localhost and hands the model the usual scanners through an API bridge: nmap, gobuster, dirb, and nikto, while 5ire is the assistant that turns your plain-language prompts into actual tool calls. The demo they walk through has a small Qwen model run a port scan across the whole chain, and nothing it touches ever leaves the machine.

The interesting bit is why they bothered keeping it all local. Their own wording is pretty direct: cloud-dependent AI has become a liability for sensitive pentest work, so the model runs where you can see it and the data stays put. For anything past a demo, though, "your hardware" stops being a laptop and becomes a server you run yourself, which is more or less what aPrivateAlps Kali Linux VPS is for: a Kali box you've got root on, one that stays up and keeps its own spot on the network. That decision raises a question a lot of testers haven't really chewed on.

Why it can't just call a cloud API

Think for a second about what's actually in the prompt while an AI assistant drives a test. Nobody cleans it up first. You've got live attack commands, exploit strings, the target's details, scan output stuffed with a client's internal hostnames and IP ranges, plus whatever the job digs up as it goes. You don't hand that to a third-party inference API and then quietly forget about it, because the moment it leaves your box, you lose any say over how long it's kept or who reads it later.

Two things go wrong. One's about confidentiality: the client's data lands in a stranger's logs, under terms nobody ran past the client, and if that provider gets popped down the line, the engagement data goes with it. The other is more of a daily annoyance. Every commercial AI provider filters for safety, and a steady feed of exploit payloads is pretty much the textbook thing those filters exist to stop, so you can watch your own authorized work get bounced mid-engagement because the traffic reads like an attack. Which, to be fair, it does.

Host the model yourself and both of those go away. Prompts never leave your environment, so nothing gets retained somewhere you can't see, and no vendor sits in the middle to slam the door when the traffic looks hostile. For real authorized testing, that's basically table stakes, since you can't invoice a workflow that leaks the client's data or freezes halfway through.

What running it actually takes

For a quick poke around, a laptop's fine. Real engagements are where that falls apart. The model needs a GPU to respond quickly, because the stack runs on CUDA and basically crawls without one. A job that runs for days wants uptime that doesn't hinge on your laptop lid being open on some café Wi-Fi. And the scanning side wants a steady spot on the network with an IP tied to the engagement rather than your home line, partly so long scans behave predictably, partly because the address doing the scanning carries a reputation you'd rather keep well away from your personal connection.

Add all that up and you're looking at a dedicated server for the Kali environment, which gets you the private self-hosted model the guide wants, plus the uptime and the network footing the testing leans on.Private Alps is built around exactly this: a Kali-ready box you run down to the root, with the model and the tools it drives both sitting on hardware whose jurisdiction and logging you picked instead of inheriting from whoever happened to rent it to you.

Hosting becomes a data-governance call

Putting Kali on a server was always practical for boring reasons, and those still hold: a clean IP, room for heavy scans, a box that survives a long job, a wall between your testing traffic and your own network. The AI layer adds a second reason, and it's the heavier one, because the question is now where sensitive data gets processed, something the old reasons never really addressed.

With an assistant in the mix, that server's running the model that reads the client's data and your attack commands both. The privacy of all that processing becomes the host's problem, effectively. Where the box lives, who runs it, what it logs, whose law can knock on its door- every one of those now touches material that belongs to the client you're testing for. What used to be a convenience call becomes a data-governance one, and for authorized work, the provider you pick matters more than how many gigahertz it clocks. Simplest way to put it: the box has to be somewhere you're genuinely okay processing confidential engagement data, which means a provider whose jurisdiction and logging you chose on purpose rather than by accident.

Where cloud AI still fits

None of this writes off cloud AI for security work. For learning, for CTF practice, for anything where the data isn't sensitive and the prompts aren't a stream of live exploits, a hosted model's fine and honestly less hassle to set up. The self-hosted route earns the extra effort in one spot specifically: authorized testing against a real client, where the data can't leave your hands and an external filter would bin the traffic on sight. Kali's already made the call and written it down, run the model yourself, keep the data on the machine, and the only thing left on your plate is deciding what the machine is. For real engagements, it's infrastructure you control, chosen as much for jurisdiction and logging as for speed.

Common questions

What does the Kali AI pentest stack actually consist of? Three parts. Ollama runs the open-weight model locally, mcp-kali-server is a small bridge that exposes command-line tools like nmap, gobuster, dirb, and nikto over a localhost API, and 5ire is the assistant that lets the model call them from plain instructions. In Kali's own demo, a small Qwen model drives a port scan end to end through that chain, all of it staying on the machine.

Why does Kali run its AI assistant locally instead of on a cloud API? The prompts are full of live attack commands, exploit strings and client data, and none of that belongs on a third-party service where it hits external logs and can get refused by a safety filter. Running it locally keeps everything on the machine and under your control.

Can I run the Kali AI stack on my laptop? For a quick test, sure. For real work, not really. It wants a GPU for speed, uptime a laptop can't promise over a long job, and a stable IP tied to the engagement, and together those point at a server you control.

Does hosting Kali on a server affect client data privacy? Yes, straight away, once the assistant's handling prompts, because the host's jurisdiction, logging and administration end up governing the client data the model reads. That makes the provider a governance decision, not just a performance one.