Autonomous multi-agent AI penetration-testing engine: a governed tool sandbox, an immutable evidence-and-validation gate, and a reproducible security-agent evaluation environment.
OIHK-pentesting is an autonomous multi-agent engine for authorized security assessments. A root planner delegates to recon, discovery, attack (Privesc), validation, and reporting agents — and the engine itself enforces scope, egress, evidence, and resource policy no matter which model drives it. Findings require real execution evidence plus independent validation; a convincing story proves nothing.
It scores against its own vulnerable-scenario benchmark — the deterministic mock solver holds 24/24 at 100/100 — and runs fully offline against any OpenAI-compatible local model.
Early beta, under active development. Behavior can change without notice; some capabilities are partial or deliberately left out. Verify before you rely on it — see the status matrix.
Most offensive tooling trusts the model's good behavior. OIHK doesn't: the safety boundary lives in the engine and holds regardless of what the model is willing to say.
example.com does not authorize its
subdomains; declared hosts are DNS-pinned for the whole run.| OS | Windows 10/11 and Linux (Kali tested). macOS is untested. |
| Python | 3.12+ with uv |
| Docker | Required for scan sandboxing. Baron's passive OSINT works without it. |
| RAM | 8 GB minimum, 16 GB recommended |
| GPU | Not required by OIHK. A local model runs on CPU or GPU — its own requirements are the model's. |
| Model | Any OpenAI-compatible endpoint (LM Studio by default), or a cloud key via /apimodel//models: Claude, ChatGPT, Gemini, Grok, DeepSeek, NVIDIA NIM |
git clone https://github.com/Broskigx/Oihk-pentesting.git
cd Oihk-pentesting
uv sync
uv run oihk --help
uv run oihk run -t https://example.test --mode passive --scan-mode standard
On Kali Linux, make sure Docker is running first (sudo systemctl start docker).
Or open Baron, the interactive copilot — you talk, it drives the governed engine (defaults to passive unless you authorize a deep assessment):
uv run oihk start
Baron runs real assessments, answers with exact tool recipes from a 164-tool
RAG corpus, pivots through OSINT (page_osint, username_osint,
domain_osint, breach_osint, phone_osint), and remembers every session in
Redis. It never gets a raw shell — only the governed engine — and everything
is menu-driven: /models, /apimodel, /adaptador, and /instancia open
interactive Textual pickers. /power <0-100> sets the parallelism budget — how many extra
sandbox containers may live at once — so Docker and the operator's machine
never get choked automatically; 0 keeps a single on-demand instance.
The TUI paints instantly (the heavy model stack loads behind the first
"pensando…" line) and is fully keyboard-driven: mouse reporting is
deliberately off — some terminals leak raw mouse bytes into the input — so
Ctrl+G stops the generation, PageUp/PageDown page the history, Ctrl+L
clears the log and Ctrl+/ opens the command menu.
There are no attack shortcuts to memorize: just type a target — a web app,
a host, an IP — and Baron detects it, plans the assessment, and delegates the
attack steps to the subagent fleet below. He also self-improves from his own
failures: every miss becomes a weighted, decaying lesson in AdapterOne
(ledger under oihk_runs/adapterone/), injected into his future prompts
automatically, with adapterone_review / adapterone_confirm to consult and
reinforce the rules mid-run.
While oihk start runs, you can hand Baron real shells on your terms. In any
terminal of the project, uv run oihk bashai finds Baron's LAN beacon,
re-validates a handshake secret, shows an explicit full-control warning and
connects only on your acceptance (queue numbers bashai-1, bashai-2, …;
no persistent identity, only position). Baron dispatches commands to those
terminals — in parallel — and every command and result lands in a persistent
audit log (oihk_runs/bashai/audit.jsonl) that feeds the evidence gate.
With OIHK_CONFIRM_COMMANDS=1 (or /confirmar on in the TUI), each command
waits for your explicit confirmation in that terminal before executing; the
default is direct execution with a reinforced warning recorded in the audit
log. The client heartbeats constantly and shuts down immediately if Baron
stops responding.
Every command Baron runs executes inside the Kali sandbox container, and
the live terminal block shows that real output as it happens — including
host-side read-only run_terminal probes (docker ps, netstat, ipconfig, ss,
arp, git status, redis-cli…), whose stdout streams into the chat line by line.