pentest-ai

Il ne signale pas. Il prouve.

Site web · Installation · Pourquoi la vérification · Benchmarks · Limites · Discord

⚠️ 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

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

pip install ptai
ptai mcp install          # auto-detects your MCP clients and writes their configs

pip install ptai
export ANTHROPIC_API_KEY=sk-...        # or OPENAI_API_KEY
ptai start https://target.example.com

# fully local, no cloud:
export PENTEST_AI_LLM_PROVIDER=ollama

# or deterministic, no LLM at all:
ptai start https://target.example.com --no-llm

ptai tools install --tier core     # or recommended / full
ptai tools install nmap nuclei     # or by name
ptai serve                         # HTTP REST + WebSocket for dashboards
ptai menu                          # interactive launcher, no LLM

Benchmarks

Reproductibles, dans git, avec des artefacts bruts. Pas de « taux de détection de 98,7 % » que vous ne pouvez pas auditer.

n=1, évaluateur unique, tir unique sur OWASP Juice Shop. Méthodologie et sortie brute dans benchmarks/ ; analyse complète dans docs/benchmarks/juice-shop.md.

La lecture honnête : ptai est solide sur les cibles web SPA avec une couverture de sondes soignée. HexStrike est plus large (cloud, binaire, CTF) et bat probablement ptai sur les surfaces explorables traditionnelles comme WordPress. Juice Shop est aussi l'application vulnérable la plus documentée d'internet, donc le LLM et les auteurs de sondes ont tous deux une longueur d'avance — ce qui est exactement pourquoi le chiffre du honeypot privé est plus bas, et pourquoi les deux sont publiés.

Intégrez-le dans la CI

- run: pip install ptai
- run: ptai start ${{ vars.STAGING_URL }} --ci --fail-on verified --sarif pentest.sarif
- uses: github/codeql-action/upload-sarif@v3
  with: { sarif_file: pentest.sarif }

--fail-on verified casse le build uniquement sur un finding qu'un oracle a réellement prouvé, donc la barrière ne peut pas être déclenchée par le bruit du scanner. SARIF est téléversé vers GitHub Code Scanning, les findings sont publiés comme commentaire de PR. Modèles GitLab et Jenkins dans docs/ci-cd.md.

Comment ça marche

recon ──▶ auth ──▶ web ──┬──▶ ad
                         ├──▶ cloud          ┌──────────────────┐
                         └──▶ api ──────────▶│  findings DB     │
                                             │  scope-guarded   │
                                             └────────┬─────────┘
                                                      ▼
                                          verify (oracles, N/N)
                                                      ▼
                                   chain ─▶ validate ─▶ detect ─▶ report
                                          md · html · pdf · SARIF · JUnit

18 agents spécialisés exécutent les phases. Avec une clé API, chacun utilise un LLM pour raisonner sur les résultats ; sans, il s'exécute comme une boucle d'outils déterministe. L'ordre des phases et la détection sont identiques dans les deux cas — les sondes trouvent les bugs, le LLM ne fait que coordonner.

Pour qui c'est

Les équipes AppSec qui intègrent un scan authentifié dans chaque PR, avec une barrière qui ne se déclenche que sur des findings prouvés. Les consultants qui veulent que le rapport s'écrive tout seul et une capsule que les propres ingénieurs du client peuvent rejouer. Les chasseurs de bug bounty qui préfèrent trier 12 findings prouvés plutôt que 600 peut-être. Les utilisateurs de Claude Code / Cursor / Codex qui veulent un véritable outillage derrière leur assistant sans une autre facture d'API.

Travaillez avec moi

L'outil est MIT et gratuit pour toujours — cela ne changera pas.

Si vous voulez un pentest livré plutôt que de l'exécuter vous-même, ou un espace de travail hébergé avec historique et accès d'équipe, les deux sont sur pentestai.xyz. Chaque finding d'un engagement livré est accompagné d'une capsule de preuve que vos ingénieurs peuvent rejouer eux-mêmes, ce qui est un artefact matériellement différent d'un PDF plein de notes de sévérité.

Questions : [email protected]

Utilisation responsable

ptai exécute de vraies opérations réseau et hôte contre les cibles que vous spécifiez. Vous êtes seul responsable de disposer d'une autorisation écrite explicite pour chaque cible. Tester des systèmes que vous ne possédez pas peut violer le Computer Fraud and Abuse Act, le Computer Misuse Act 1990, l'article 32 du RGPD, et les équivalents ailleurs.

La première exécution demande l'acceptation de l'AUP et la persiste. Définissez PENTEST_AI_AUP_ACCEPTED=1 en CI. Les hôtes hors périmètre sont refusés au moment de l'invocation de l'outil. Trois garde-fous sont désactivés par défaut et méritent d'être activés : intensity=safe saute les sondes qui modifient l'état, respect_rate_limits honore 429/Retry-After, et strict_scope refuse les requêtes hors hôte.

ptai start http://target --oast-server https://oast.example.com --oast-token <T>
ptai start http://target --no-oast          # or disable entirely

FAQ

Ai-je besoin d'une clé API ? Pas sur la voie MCP — votre abonnement Claude Code / Cursor / Codex est le LLM. Seule la CLI autonome en a besoin, et même là Ollama s'exécute entièrement en local.

Est-ce autonome ? Non, et il ne prétend pas l'être. Les sondes détectent, le LLM coordonne, vous décidez. Ctrl+C deux fois prend la main en cours d'exécution.

Sûr contre la production ? Uniquement avec une autorisation écrite et les trois garde-fous ci-dessus activés.

Est-ce qu'il téléphone à la maison ? Pas par défaut. Les findings restent sur votre disque. Vous pouvez opter pour des compteurs d'usage anonymes avec ptai telemetry enable (pas de cibles, pas de findings ; schéma dans engine/telemetry.py). Les callbacks OAST passent par défaut par le oast.fun de ProjectDiscovery sauf si vous passez --oast-server ou --no-oast.

En quoi est-ce différent de demander à Claude de hacker quelque chose ? Une bibliothèque de sondes déterministe et soignée trouve les bugs et un oracle machine les prouve. Un LLM seul vous donne une supposition plausible sans moyen de savoir si elle est réelle.

Écosystème

Communauté : Discord · Discussions · Issues

Historique des étoiles

L'ancien graphique en ligne (api.star-history.com) est vide : GitHub a restreint l'API publique des stargazers dont ces SVG dépendaient. La série live est sur star-history.com. Le README ne fait pas de lien direct vers un hôte de remplacement — le navigateur de chaque visiteur aurait récupéré ce SVG.

Licence

MIT. Faites-en ce que vous voulez.