Moteur autonome de test d'intrusion par IA multi-agents : un bac à sable d'outils gouverné, une porte immuable de preuve et de validation, et un environnement reproductible d'évaluation d'agents de sécurité.
OIHK-pentesting est un moteur multi-agents autonome pour les évaluations de sécurité autorisées. Un planificateur racine délègue à des agents de reconnaissance, de découverte, d'attaque (Privesc), de validation et de reporting — et le moteur lui-même applique les politiques de périmètre, d'egress, de preuves et de ressources, quel que soit le modèle qui le pilote. Les findings exigent une preuve d'exécution réelle plus une validation indépendante ; une histoire convaincante ne prouve rien.
Il s'évalue sur son propre benchmark de scénarios vulnérables — le solveur mock déterministe obtient 24/24 à 100/100 — et fonctionne entièrement hors ligne avec n'importe quel modèle local compatible OpenAI.
Bêta précoce, en développement actif. Le comportement peut changer sans préavis ; certaines capacités sont partielles ou délibérément absentes. Vérifiez avant de vous y fier — voir la matrice de statut.
La plupart des outils offensifs font confiance au bon comportement du modèle. OIHK non : la frontière de sécurité réside dans le moteur et tient quel que soit ce que le modèle est prêt à dire.
example.com n'autorise pas ses sous-domaines ; les hôtes déclarés sont épinglés DNS pour toute la durée de l'exécution.| OS | Windows 10/11 et Linux (Kali testé). macOS non testé. |
| Python | 3.12+ avec uv |
| Docker | Requis pour le bac à sable des scans. L'OSINT passif de Baron fonctionne sans. |
| RAM | 8 Go minimum, 16 Go recommandé |
| GPU | Non requis par OIHK. Un modèle local tourne sur CPU ou GPU — ses propres prérequis sont ceux du modèle. |
| Modèle | N'importe quel endpoint compatible OpenAI (LM Studio par défaut), ou une clé cloud 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
Sur Kali Linux, assurez-vous d'abord que Docker est démarré (sudo systemctl start docker).
Ou ouvrez Baron, le copilote interactif — vous parlez, il pilote le moteur gouverné (par défaut en passif sauf si vous autorisez une évaluation approfondie) :
uv run oihk start
Baron exécute de vraies évaluations, répond avec des recettes d'outils exactes issues d'un corpus RAG de 164 outils, pivote via l'OSINT (page_osint, username_osint, domain_osint, breach_osint, phone_osint), et mémorise chaque session dans Redis. Il n'obtient jamais de shell brut — uniquement le moteur gouverné — et tout est piloté par menus : /models, /apimodel, /adaptador et /instancia ouvrent des sélecteurs interactifs Textual. /power <0-100> définit le budget de parallélisme — combien de conteneurs de bac à sable supplémentaires peuvent vivre simultanément — afin que Docker et la machine de l'opérateur ne soient jamais saturés automatiquement ; 0 conserve une seule instance à la demande.
La TUI s'affiche instantanément (la pile lourde du modèle se charge derrière la première ligne « pensando… ») et est entièrement pilotée au clavier : le reporting souris est délibérément désactivé — certains terminaux laissent fuiter des octets bruts de souris dans l'entrée — donc Ctrl+G arrête la génération, PageUp/PageDown paginent l'historique, Ctrl+L efface le journal et Ctrl+/ ouvre le menu de commandes.
Il n'y a aucun raccourci d'attaque à mémoriser : tapez simplement une cible — une application web, un hôte, une IP — et Baron la détecte, planifie l'évaluation et délègue les étapes d'attaque à la flotte de sous-agents ci-dessous. Il s'améliore aussi à partir de ses propres échecs : chaque raté devient une leçon pondérée et décroissante dans AdapterOne (registre sous oihk_runs/adapterone/), injectée automatiquement dans ses prompts futurs, avec adapterone_review / adapterone_confirm pour consulter et renforcer les règles en cours d'exécution.