pentest-ai v1.4.0 — Open-source AI pentester that proves every finding. Machine oracles re-run each exploit; verified bugs ship a proof capsule you can replay yourself.

Site web · Démarrage rapide · Bug bounty · Vérification · Documentation · Issues

Pentest-AI est un outil open source de test d'intrusion et de bug bounty assisté par IA qui prouve chaque résultat. Il connecte un client ou un modèle d'IA à un véritable workflow de pentest — investigation d'applications web, découverte et reproduction de vulnérabilités, et utilisation d'oracles machine pour vérifier si un exploit fonctionne réellement. Pas de preuve, pas de résultat : les résultats vérifiés s'accompagnent de preuves que vous pouvez rejouer vous-même.

Utilisez-le via MCP (Claude Code, Codex, Cursor, VS Code), depuis la CLI, ou en CI/CD. Le modèle pilote l'investigation ; un oracle indépendant décide si un résultat mérite un verdict vérifié — la sortie est donc du signal, pas du bruit généré par IA.

Conçu pour le bug bounty autorisé : importez le périmètre d'un programme (HackerOne, Bugcrowd, Intigriti, YesWeHack), lancez une mission encadrée par le périmètre, et transformez chaque résultat vérifié en soumission prête pour la plateforme. Accéder au workflow bug bounty →

Ne testez que les systèmes que vous possédez ou pour lesquels vous disposez d'une autorisation explicite. Lisez la politique d'utilisation acceptable et les conditions avant de lancer une mission.

Démarrage rapide

Recommandé : Codex ou Claude Code

Utilisez Python 3.10–3.14 et installez d'abord pipx. Exécutez pipx ensurepath et rouvrez votre terminal si nécessaire. pipx isole les dépendances de Pentest-AI et rend ses commandes disponibles dans tous les dossiers.

pipx install ptai
ptai setup --mcp

Installez d'abord la CLI de votre client IA. La configuration demande confirmation avant de connecter tous les clients pris en charge détectés, y compris Codex et Claude Code lorsqu'ils sont installés. Elle préserve les enregistrements existants. Redémarrez votre client ensuite.

L'assistant utilise les paramètres à l'échelle de l'utilisateur. Il n'installe pas de clients, ne vous connecte pas, ne télécharge pas de modèles et ne configure pas Ollama. Votre client IA fournit le modèle ; aucune clé API de modèle distincte n'est requise par le serveur MCP. Utilisez ptai setup --mcp --dry-run pour prévisualiser les changements. Consultez la configuration mono-client et par dépôt pour les instructions Codex .codex/config.toml et Claude Code .mcp.json.

Pour les mises à niveau, utilisez pipx upgrade ptai. Dans un environnement virtuel activé existant, python -m pip install --upgrade ptai est également pris en charge ; gardez cet environnement disponible après l'avoir enregistré auprès de votre client IA.

Alternative : Ollama et modèles locaux

Installez Pentest-AI comme ci-dessus, mais ignorez la configuration MCP pour cette approche. Installez et démarrez Ollama, puis récupérez un modèle avec prise en charge du tool-calling. Utilisez ollama list pour trouver son nom exact installé.

export PENTEST_AI_LLM_PROVIDER=ollama
export PENTEST_AI_MODEL="your-installed-model"
ptai start https://your-authorized-target.example --no-sync

Dans PowerShell :

$env:PENTEST_AI_LLM_PROVIDER = "ollama"
$env:PENTEST_AI_MODEL = "your-installed-model"
ptai start https://your-authorized-target.example --no-sync

Remplacez les valeurs fictives avant d'exécuter. Un modèle local ne nécessite aucune clé API cloud. La qualité du modèle et la mémoire disponible influencent les résultats. Consultez le guide des modèles pour la configuration du point de terminaison.

Essayez la démo intégrée

Aucune clé API ni cible externe requise.

pipx install ptai
ptai demo

La démo teste une application vulnérable intégrée, rejoue un résultat depuis sa capsule de preuve et vérifie les routes durcies. Inspectez le workflow de preuve avant de configurer une véritable mission.

Autres fournisseurs de modèles

Pour les modèles cloud autonomes et les dépendances de scanners optionnelles, consultez le guide d'installation et le guide des fournisseurs. Gardez les clés API hors du contrôle de version.

Automatisation du bug bounty

Pentest-AI est conçu pour le travail de bug bounty autorisé, où rester dans le périmètre et ne soumettre que des résultats reproductibles sont ce qui compte.

# 1. Import the program's scope (HackerOne / Bugcrowd / Intigriti / YesWeHack)
ptai bounty import --platform hackerone --file scope.json --out program.scope

# 2. Run a scope-enforced engagement (a preflight shows exactly what will be
#    touched and asks you to confirm — nothing out of scope is ever hit)
ptai start acme.com --scope-file program.scope --intensity stealth

# 3. Turn verified findings into platform-ready submissions
ptai bounty report <engagement-id> --platform hackerone --out submissions/

Le périmètre est appliqué, pas indicatif : jokers, CIDRs et exclusions hors périmètre, en échec fermé, sur chaque agent et outil.
Les soumissions sont prêtes à être envoyées : chacune inclut un curl reproductible, CVSS/CWE, l'impact, la remédiation, et le verdict machine avec une capsule de preuve rejouable.
Ou exécutez le playbook de méthodologie intégré de bout en bout : ptai playbook run bug-bounty-web -i target=acme.com --execute.

Guide complet du bug bounty →

Comment fonctionne la vérification

Un candidat ne devient vérifié qu'après qu'un oracle répète l'exploit et vérifie un contrôle. La capsule de preuve résultante peut être rejouée.

Trouver un candidat. Une sonde ou un scanner identifie un comportement qui mérite investigation.
Le reproduire et vérifier un contrôle. Un oracle nommé répète l'exploit et le compare à un contrôle qui ne devrait pas démontrer la faiblesse.
Conserver les preuves. Un résultat vérifié enregistre l'oracle et ses résultats dans une capsule de preuve portable. Utilisez ptai replay pour le vérifier à nouveau.

Par exemple, un contournement par en-tête de confiance doit renvoyer du contenu privilégié avec l'en-tête d'attaque et refuser l'accès sans celui-ci. Un serveur qui répond à chaque requête par HTTP 200 ne constitue pas une preuve suffisante.

Le modèle ne peut pas attribuer un verdict vérifié. La sortie d'un scanner tiers reste non vérifiée jusqu'à ce qu'un oracle la prouve indépendamment. Les résultats sans recette de vérification prise en charge restent des candidats.

Un verdict vérifié s'applique aux conditions testées. Cela ne signifie pas que l'application entière est sécurisée. Les capsules de preuve ne sont pas signées ; rejouer la vérification est le mécanisme de confiance.

Lire la conception de la vérification