⚠️ Outillage offensif, tests autorisés uniquement. En installant, vous acceptez l'AUP et les Conditions. Voir Utilisation responsable ↓

Deux minutes, pas de clé API, pas de cible à vous

pip install ptai && ptai demo

ptai demo scanne une application vulnérable intégrée et affiche 4 findings, 3 oracle-VERIFIED. Il en rejoue un en direct depuis une capsule de preuve (replay 3/3), puis exécute les mêmes routes durcies et affiche 0 findings.

Deux choses à remarquer. Les findings apparaissent et disparaissent avec la vulnérabilité plutôt que parce que l'outil s'est tu — la seule chose qui a changé entre les deux exécutions est le correctif. Et l'un des quatre reste un candidat : le contournement d'authentification par SQLi est réel, mais aucun oracle n'a pu le re-prouver sur cette route, il n'obtient donc pas de badge. Cet écart est le produit qui fonctionne, pas un bug dans la démo.

Ce que VERIFIED signifie réellement ici

La plupart des scanners vous disent qu'une chose pourrait être exploitable et vous laissent le triage. ptai traite un finding comme un candidat jusqu'à ce qu'un oracle machine nommé réexécute l'exploit et le reproduise N fois sur N. C'est seulement alors qu'il obtient VERIFIED.

Trois propriétés font que ce n'est pas qu'un slogan :

Aucun LLM ne produit jamais de verdict. La règle est appliquée dans le code, pas par politique : un verdict qui ne peut pas nommer l'oracle qui l'a obtenu est rejeté. Un LLM coordonne l'exécution et raisonne sur les résultats. Il ne décide jamais si un bug est réel.

Chaque oracle a un contrôle qui doit échouer. Un contournement par en-tête de confiance doit retourner du contenu privilégié avec l'en-tête et un refus sans lui. Une vérification d'identifiants fuités doit être acceptée pour le vrai secret et rejetée pour un jumeau délibérément corrompu. Un endpoint qui répond 200 à tout n'obtient rien. C'est ce qui empêche que « il a retourné 200 » soit pris pour une preuve.

La sortie des scanners tiers est retenue. Les résultats de nuclei, nikto et zap ne deviennent pas des findings de leur propre autorité. Ils restent non vérifiés jusqu'à ce que l'un des oracles propres à ptai les re-prouve indépendamment.

Chaque finding VERIFIED est livré sous forme de capsule de preuve portable — le finding, la recette pour le re-prouver, et le reçu. N'importe qui peut le ptai replay contre la cible live et regarder l'oracle re-confirmer, sans faire confiance à ptai. Les capsules sont délibérément non signées : le replay est le mécanisme de confiance, pas une signature que vous devez prendre sur parole.

Des chiffres honnêtes

Classes de vulnérabilité avec un oracle fonctionnel	14
Sondes dans la bibliothèque	64
Sondes pouvant obtenir VERIFIED	30
Types d'oracles	24
Wrappers d'outils	203
…qui transforment la sortie en findings aujourd'hui	18
Outils MCP	52
Agents spécialisés	18
Tests	2 729 sur Python 3.10 / 3.12 / 3.14

Sur un honeypot délibérément vulnérable, 23 findings se vérifient à travers ces 14 classes avec 100 % de précision et zéro faux positif. Sur un OWASP Juice Shop standard, 17 findings ont été vérifiés lors du balayage du 2026-08-23 — rapportez HTTP dans le périmètre / vérifiés / précision, pas 17/116. Une session MCP Path 1 du 2026-08-25 (client MCP pilotant run_probe, cible morte avant la vérification de l'orchestrateur) a obtenu 12 preuves vérifiées avec 100 % de précision contre 64 défis HTTP dans le périmètre (20 non poursuivis). Les clés OSINT, Web3 et UI-only de Juice Shop sont hors du tableau de score d'automatisation par conception.

Lisez ces chiffres attentivement, car les écarts sont le point essentiel. 64 sondes existent mais seulement 30 peuvent obtenir un verdict ; les 34 autres rapportent d'honnêtes candidats. 203 wrappers sont enregistrés mais seulement 18 transforment la sortie d'outil en findings — le reste s'exécute et rend du texte brut. La barrière de l'oracle achète la précision, pas le taux de détection : elle élimine les faux positifs, elle ne trouve pas plus de bugs.

Le harnais honeypot (tests/honeypot/) et une barrière zéro-faux-positif sur application propre (tests/cleanapp/) sont tous deux livrés dans ce dépôt et s'exécutent en CI, donc ce sont des résultats reproductibles plutôt que des captures d'écran.

Ce qu'il ne fait pas

Dit clairement, parce qu'un outil de sécurité qui se survend est pire qu'inutile.

• C'est un scanner d'applications web. Les 64 sondes et les 24 types d'oracles ciblent HTTP. AD, cloud, mobile et sans fil ont des agents et des wrappers d'outils, mais pas de bibliothèque de sondes ni d'oracles derrière eux.
• Il ne peut pas faire d'élévation de privilèges locale. Cela nécessite une exécution de code sur un hôte que vous possédez déjà. ptai teste à distance et n'a pas un tel canal, donc l'agent privesc rapporte unsupported plutôt qu'un zéro trompeur.
• Ce n'est pas un scanner de CVE. Il n'y a pas de base de données version-vers-CVE ni de bibliothèque d'exploits. Le travail CVE se limite aux recherches osv.dev sur les manifestes fuités.
• Les playbooks planifient, ils n'exécutent pas. ptai playbook run résout les dépendances et affiche le plan. L'exécuter contre une cible n'est pas encore câblé.
• Il n'est pas autonome. Les agents pentest LLM entièrement autonomes terminent 21–31 % des tâches de bout en bout ; les configurations assistées par humain atteignent 64 %. ptai est conçu pour le second régime. Appuyez deux fois sur Ctrl+C pour prendre la main en cours d'exécution.

La liste complète des défauts internes, y compris tout ce qui précède, est suivie ouvertement plutôt que discrètement. Si quelque chose ici est faux, ouvrez une issue et ce sera corrigé.

Installation

Voie 1 — Pilotez-le depuis Claude Code, Cursor ou Codex (pas de clé API)

Votre abonnement IA existant est le LLM. ptai fournit les outils.