AIRecon: A Local-Only Pentest Agent Wired to Ollama and a Kali Container
AIRecon is an autonomous cybersecurity agent that combines a self-hosted Large Language Model (Ollama) with a Kali Linux Docker sandbox and a Textual TUI. It is designed to automate security assessments, penetration testing, and bug bounty reconnaissance — without any API keys or cloud dependency.
At a glance
- What is it?
- AIRecon runs an autonomous RECON to REPORT pipeline against a self-hosted Ollama model inside a Kali Linux Docker sandbox, with no API keys and no cloud calls. The design is coherent, but the project's own documentation sets a hard floor on model size that most laptops will not clear.
- Who is it for?
- Adopt AIRecon if you already have a GPU with roughly 16 to 20 GB of VRAM, you are comfortable running Kali tooling inside a container, and the target data you handle cannot leave your machine. Do not adopt it if your only hardware is a laptop with integrated graphics, or if you need a deterministic, auditable scan whose every step is reproducible; the README's own 20 to 40 percent tool-call error estimate for 8B to 14B models makes that use case a poor fit.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The cost problem AIRecon is built around
Recursive reconnaissance is chatty. An agent that observes an HTTP response, decides on a follow-up probe, runs it, reads the output and decides again can burn thousands of model calls in a single session. The README states this directly: commercial API-based models become prohibitively expensive for these workflows. AIRecon's answer is to move the model onto your own hardware. There are no API keys, no per-token billing, and no target data leaving the machine. That is the whole pitch, and it is a narrow one. If your recon volume is low, or you already have a metered API budget you are happy with, the tradeoff AIRecon makes (weaker local models in exchange for zero marginal cost) is not obviously in your favour. The project is for people running long, repetitive, autonomous sessions against targets they are authorised to test, on hardware they own.
Four phases, soft enforcement, and checkpoints on a fixed cadence
The pipeline is RECON, ANALYSIS, EXPLOIT, REPORT. Each phase carries its own objectives, recommended tools and transition criteria, but the README is explicit that enforcement is soft: the agent is guided, never blocked. That is a deliberate design choice and it has consequences. A hard state machine gives you repeatability and a clean audit trail; a soft one lets the model jump back to reconnaissance mid-exploit if it decides it needs more context. AIRecon picks flexibility. The cadence is fixed rather than adaptive: checkpoints fire every 5 iterations for phase evaluation, every 10 for self-evaluation, and every 15 for context compression. Context compression at a fixed interval is a reasonable hedge against a local model's limited window, though whether 15 is the right number for your target is something only your own runs will tell you.
What the learning layer actually is
The README is unusually honest here, and it is worth quoting the framing: AIRecon does not fine-tune the LLM. What it calls learning is structured telemetry written to disk. Sessions, findings, patterns, target intel, tool usage, model performance and attack-chain discoveries land in a SQLite database at ~/.airecon/memory/airecon.db. Tool performance statistics, strategy patterns, an observation log and distilled insights go to ~/.airecon/learning/global_learning.json. Per-target files under ~/.airecon/memory/by_target/ hold endpoints, vulnerabilities, WAF bypasses, sensitive parameters and auth endpoints. Payload memory snapshots can be written to workspace/<target>/payload_memory.json when session persistence runs. The behavioural effect is concrete: memory context is injected at session start, learned patterns and similar findings are re-injected every 8 iterations based on detected technology, tool ranking is reordered by historical success and failure, and payload memory skips payloads that repeatedly failed for the same target and parameter. This is retrieval and ranking, not model improvement. Calling it learning in the README invites over-reading, but the mechanism described is defensible.
The model floor is the real adoption barrier
AIRecon requires a model with extended thinking blocks and reliable native tool calling. Capabilities are auto-detected through ollama show metadata. The README warns in plain terms that a model without native function calling makes AIRecon completely non-functional, because nothing can execute http_observe, execute, browser actions or any other tool. The recommended minimum is 8B to 9B parameters, and the documentation is blunt that smaller models hallucinate tool output, invent CVEs, skip scope rules and produce unreliable calls. The stated error band for 8B to 14B models is 20 to 40 percent tool call errors and hallucinations. Qwen3.5 9B is labelled the minimum viable option at 6 GB of VRAM, with the caveat to expect frequent errors. The recommended pick for most users is Qwen3.5 35B at 20 GB, and the 35b-a3b MoE variant drops that to 16 GB. Best quality comes from Qwen3.5 122B at 48 GB or more. DeepSeek R1 is called out for producing incomplete function calls. Read that table as a hardware requirement, not a suggestion.
Getting it running, including the Colab escape hatch
The documented path starts with pulling a model: ollama pull qwen3.5:35b for the recommended configuration, or ollama pull qwen3.5:9b if you are testing the floor. Configuration lives in ~/.airecon/config.yaml, and the README shows the key that matters for remote inference, ollama_url, set to a tunnel address such as https://xxxx.trycloudflare. For hardware below the VRAM minimum, the project ships a Colab notebook at scripts/airecon_colab.ipynb. The flow is: open the notebook, set Runtime to a T4 GPU, run all cells top to bottom (roughly 5 to 10 minutes on the first run), then copy the config snippet printed in Cell 6 into ~/.airecon/config.yaml. The architecture is a cloudflared tunnel carrying HTTPS between the Colab-hosted Ollama instance and the local TUI. Note the tension: the privacy argument for AIRecon assumes the model runs locally, and routing inference through a Colab tunnel and a public cloudflared URL weakens that assumption considerably. The README presents the Colab route as a hardware workaround, which it is, but it is not the same privacy posture as a local GPU.
Caido, skills, and the optional dataset
Five Caido tools ship built in: list, replay, automate with the §FUZZ§ marker, findings, and scope. That is a tighter proxy integration than most agent projects manage, and it means the agent can drive a real intercepting proxy rather than shelling out to curl. Alongside that, 57 skill files and 289 keyword-to-skill mappings route the model toward relevant playbooks. A separate repository, airecon-skills, adds 57 more CLI-based playbooks for CTF, bug bounty and pentesting work. A third optional repository, airecon-dataset, indexes roughly 1.09 million security records (CVEs, red team techniques, CTF writeups, nuclei templates, bug bounty payloads) into local SQLite FTS5, exposing a dataset_search tool the model is documented to call before attempting unfamiliar techniques. Each of these is a separate install with its own maintenance surface, and the README does not describe a version-compatibility contract between them. Treat them as opt-in additions rather than part of the core.
Where it is the wrong tool, and what to use instead
The clearest failure mode is hardware. Below 16 GB of VRAM you are either on the 9B model with its documented error rate, or you are tunnelling to Colab and giving up the offline guarantee. A second failure mode is the soft phase enforcement: if you need a scan whose steps are deterministic and reproducible for a report or a compliance artefact, an agent that can leave EXPLOIT to go back to RECON is a liability, not a feature. For that job, a conventional pipeline such as a curated nuclei template set driven by a static scanner gives you fixed, versioned checks with output you can diff between runs. The difference in approach is fundamental: nuclei executes a declared list of checks and reports matches, while AIRecon asks a language model to decide what to do next and accepts that some of those decisions will be wrong. Neither replaces the other. Use AIRecon where exploration and unfamiliar targets matter; use template-driven scanning where you need the same answer twice.
Licence, release cadence and what you are signing up for
AIRecon is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is permissive, and it is worth noting that the MIT grant covers the AIRecon code itself, not the Kali tooling it invokes inside the sandbox or the models you pull through Ollama, each of which carries its own terms. This is a description of the licence text, not legal advice; if you plan to redistribute a modified build, read the full LICENSE file. On maintenance: the project is on a beta cadence, with 0.1.7-beta released 2026-04-03, v0.1.6-beta on 2026-03-17 and v0.1.5-beta on 2026-03-05. Three beta releases in roughly a month, all 0.1.x, tells you the interfaces and the config schema are still moving. Expect ~/.airecon/config.yaml keys and the memory database layout to change between minor versions, and budget for re-reading the release notes before each upgrade rather than assuming a drop-in replacement.
Editorial conclusion
Adopt AIRecon if you already have a GPU with roughly 16 to 20 GB of VRAM, you are comfortable running Kali tooling inside a container, and the target data you handle cannot leave your machine. Do not adopt it if your only hardware is a laptop with integrated graphics, or if you need a deterministic, auditable scan whose every step is reproducible; the README's own 20 to 40 percent tool-call error estimate for 8B to 14B models makes that use case a poor fit. Before committing, confirm three things against your own setup: that your chosen model reports native tool calling in ollama show output, that the sandbox can reach your targets without violating the rules of engagement, and that the RECON to REPORT phase transitions behave the way the documentation describes on a throwaway host.
Community notes