AI-Native Pentest (AI-PTaaS)

Oui, et on l'assume. Distinguons deux choses. La découverte et le scan EASM sont non-intrusifs par conception : aucune exploitation, pas de payload destructeur, redirections désactivées, débit plafonné par hôte, garde anti-SSRF à trois couches. La validation IA, elle, est du test actif : elle lance de l'outillage réel (sqlmap, nuclei et autres) contre l'actif live, ce qui peut modifier son état. La sandbox isole l'outillage (conteneur éphémère, egress filtré aux seules IP publiques de la cible), pas votre actif. C'est pour ça qu'elle est manuelle, réservée aux findings critiques sur un domaine que vous avez vérifié, et quotaée. On préfère le dire que le cacher.

Une différence de nature. L'agent est de l'IA : il confirme, ou non, qu'un finding High ou Critical est exploitable avec de l'outillage standard, sous garde-fous stricts (20 étapes, 300 secondes, 150 000 tokens). Il ne fait pas de logique métier tordue, pas de chaîne d'exploitation créative, pas de jugement humain sur le contexte de votre application. Un pentester certifié OSWE, lui, enchaîne des vulnérabilités faibles en compromission complète, comprend votre métier et pense comme un attaquant déterminé. Les deux sont complémentaires : la validation IA baisse le bruit à l'échelle, le pentest apporte la vérification humaine approfondie. Ce sont deux offres séparées, et on ne prétend pas que l'une remplace l'autre.

La validation appelle les modèles Claude d'Anthropic via Google Cloud Vertex AI, en région européenne, sous clauses contractuelles types. Aucun entraînement sur vos données, aucune rétention pour améliorer un modèle tiers. Vos findings, les preuves d'exploitabilité et le reste de votre inventaire restent sous droit européen, isolés par compte, avec masquage des secrets avant écriture. Confier une preuve d'exploitabilité à un éditeur américain expose à des demandes d'accès extraterritoriales, en tension avec le RGPD et NIS2 : nous gardons l'hébergement dans l'UE.

Non, et méfiez-vous de qui le promet. La validation confirme un finding quand l'agent parvient à l'exploiter réellement : ce cas-là, vous pouvez le croire, preuve à l'appui. Mais un échec de validation ne veut pas dire que le finding est un faux positif : l'agent n'a pas prouvé l'exploitabilité avec son outillage et dans ses bornes, c'est tout. On ne surinterprète pas l'échec, on ne transforme pas l'absence de preuve en certitude. Ce que la validation vous fait gagner, c'est le tri le plus coûteux : distinguer ce qui est prouvé exploitable de ce qui reste à investiguer.

Le même outillage offensif qu'un opérateur humain : sqlmap pour l'injection SQL, nuclei pour les templates d'exploitation, et le reste de la panoplie selon le type de finding. L'agent choisit ses outils en fonction de la vulnérabilité et les exécute pour de vrai dans la sandbox. Ce n'est pas une nouvelle passe de scan ni une corrélation CVE plus fine : c'est une tentative d'exploitation, avec de vrais outils, contre l'actif concerné.

Manuellement, depuis l'interface, uniquement sur un finding High ou Critical d'un domaine dont vous avez prouvé la propriété. Rien ne part automatiquement, parce que c'est du test actif. Chaque validation consomme un crédit de votre quota mensuel, affiché en temps réel. Vous choisissez le finding et le moment ; le périmètre reste strictement le vôtre.

2 validations par mois en Découverte, 30 en Pro, 100 en Business, illimité en Enterprise. Les crédits sont comptés par mois calendaire et remis à zéro le 1er. La validation IA-native est incluse dans chaque palier de l'offre EASM, quotas croissants : ce n'est pas un module vendu à part, c'est une facette de la plateforme.

Il s'arrête, proprement. Les garde-fous sont durs : 20 étapes, 300 secondes ou 150 000 tokens, la première borne atteinte met fin à la validation. Le conteneur éphémère est détruit, et le finding reste au statut détecté si l'exploitation n'a pas abouti dans le cadre imparti. Un agent autonome sans limite serait un risque ; ici la borne prime sur la démonstration.