Tests de sécurité par IA · Phase pilote
Un attaquant cherche une entrée, teste ce qui fonctionne et poursuit son chemin vers des données précieuses ou davantage de contrôle. Nous développons EverBreach pour utiliser l’IA de la même façon, avec votre autorisation, des limites convenues et des résultats qui permettent d’agir.
Pour les organisations avec ou sans équipe de sécurité dédiée. Périmètre, accès, prix et calendrier convenus avant les tests.
Demander une analyse piloteExplorer la démonstration du scannerApplications, API, comptes, services cloud et infrastructure peuvent former un même parcours d’attaque. Une équipe qui utilise l’IA adapte la suite à ce qu’elle découvre. C’est le principe de nos simulations.
Explorer le périmètre convenu depuis l’extérieur ou avec un compte utilisateur ordinaire. Repérer les services exposés, les données accessibles et les contrôles d’accès susceptibles de céder.
Vérifier si une faiblesse supposée donne réellement accès aux dossiers d’autres candidats, à un fichier payant avant l’achat ou à une fonction réservée aux administrateurs.
Examiner si une faille mène plus loin : d’un dossier à ses documents, d’identifiants exposés à un autre service ou d’un compte à des droits supplémentaires. Toujours dans les limites convenues.
Expliquer l’accès démontré, ses conséquences pour l’activité et la correction précise. Après le correctif, reprendre les étapes concernées pour vérifier que le passage est fermé.
Démonstration contrôlée du scanner
Explorez un test enregistré sur un serveur de démonstration local avec des données fictives. Il utilise la même détection de fichiers exposés que le scanner EverBreach actuel.
# Synthetic demo values; no account or database exists.
DB_HOST=database.example.invalid
DB_USER=demo_only
DB_PASSWORD=NOT_A_REAL_PASSWORD
Critique · Fichier de configuration accessible publiquement
Un fichier de configuration peut révéler des adresses de bases de données et des identifiants. Si ces valeurs étaient réelles et valides, un attaquant pourrait tenter de les utiliser pour accéder à un autre service. Ce test démontre que le fichier est lisible, sans établir un accès à une base de données.
Conservez les fichiers de configuration hors du déploiement public et bloquez leur accès direct. Si de vrais secrets ont été exposés, révoquez-les ou remplacez-les et examinez les journaux d’accès. Dans cette démonstration, nous avons modifié le serveur pour refuser la requête.
Forbidden
La même requête reçoit désormais le statut 403. La règle de détection ne produit plus de constat pour ce chemin. Cela vérifie uniquement la correction montrée, sans établir la sécurité de l’ensemble du système.
Il s’agit d’une seule vérification déterministe du scanner. Aucun modèle d’IA n’a été appelé, aucun identifiant réel utilisé et aucun accès à un autre service tenté. Le nom d’hôte a été remplacé pour l’affichage ; les réponses ont été enregistrées sur un serveur accessible uniquement en local.
Ce que montrent les faits
Des attaquants utilisent l’IA pour examiner des systèmes, tester des failles et obtenir des accès. Les défenseurs s’en servent aussi pour découvrir des vulnérabilités inconnues. Ces rapports publiés montrent concrètement cette évolution.
Attaque rapportée
C’est la part estimée par Anthropic dans une campagne d’espionnage visant une trentaine d’organisations. Quelques intrusions ont abouti. Des humains choisissaient les cibles et prenaient les décisions clés ; l’IA a aussi commis des erreurs.
Anthropic · novembre 2025 ↗Failles découvertes et corrigées
Mozilla a signalé ces découvertes lors d’une première évaluation de Claude Mythos Preview. Ces recherches sur Firefox ont été suivies de correctifs distribués aux utilisateurs : un exemple concret d’IA au service de la défense.
Mozilla · avril 2026 ↗Simulation d’attaque contrôlée
Selon l’AI Security Institute britannique, GPT-5.5 a accompli toute la chaîne dans 2 essais sur 10, depuis un premier accès au réseau jusqu’à une base de données protégée. Chaque essai disposait de 100 millions de tokens. Aucun défenseur actif n’était présent.
UK AI Security Institute · GPT-5.5 · 2026 ↗Nous en tirons une raison de mettre ces capacités au service de votre défense et de refaire les tests quand les systèmes ou les modèles changent. Ces résultats externes proviennent de contextes différents. Ils ne mesurent ni les performances d’EverBreach ni votre probabilité de subir une intrusion.
Haute · Limiter immédiatement l’accès
Commençons par un système ou un processus métier convenu ensemble. Le choix dépend des données, des accès ou de l’activité que vous souhaitez protéger.
Ce qui a été testé et démontré, les conséquences possibles et les corrections à apporter. Le périmètre et les limites sont documentés même si aucun problème n’est confirmé.
Examinons ensemble les preuves et les priorités. Invitez la personne qui apportera les corrections : développeur, équipe de sécurité ou prestataire informatique.
Les vérifications convenues sont répétées pour contrôler les corrections. La proposition précise le périmètre et la période de ce nouveau test.
Avant votre engagement, la proposition fixe le périmètre, le prix forfaitaire, la date de livraison et la période du nouveau test. Votre demande est gratuite et ne lance aucun test.
Avant d’accorder un accès, vous saurez qui est responsable de l’analyse, quel fournisseur de modèle intervient et comment les preuves seront traitées.
Les décisions d’accès se répartissent entre applications, API, stockage et infrastructure. Une page peut sembler normale alors que les systèmes derrière exposent des données ou contournent une règle métier.
Une simulation exige une autorisation, un périmètre défini et un point d’arrêt clair. Nous les convenons avant les tests.
Définir les systèmes, comptes et actions permis. Les services tiers peuvent nécessiter leur propre autorisation.
Convenir des comptes de test, données fictives et critères d’arrêt. Une preuve limitée doit démontrer la faille sans devenir une collecte massive de données personnelles.
Avant les tests, nous expliquons le fournisseur du modèle, les informations transmises, le stockage et la durée de conservation. Le traitement des preuves sensibles est convenu explicitement.
Séparer l’accès démontré de l’impact plus large possible. Le rapport doit expliquer le raisonnement et permettre de reproduire le résultat dans le périmètre autorisé.
Non. Le projet vise les applications, API et systèmes connectés des organisations de différentes tailles. Le scanner actuellement implémenté ici a un périmètre plus restreint : la configuration des sites publics. Nous distinguons ce point de départ des simulations plus larges en développement.
Un test assisté par IA suit un parcours possible dans des limites convenues : ce qu’un compte peut consulter, les informations révélées et ce qu’elles permettent ensuite. Les scénarios illustrent la profondeur visée. Ce ne sont pas des résultats du scanner actuel.
Une modification logicielle peut introduire une faille. Un meilleur modèle peut découvrir un défaut ancien passé inaperçu. Ce sont deux raisons distinctes de recommencer. Toute découverte n’est pas une faille zero-day et ne prouve pas que l’IA seule a été décisive.
Oui. Le rapport s’adresse aux personnes qui décident des corrections et à celles qui les réalisent : sécurité interne, développement ou prestataire. Chaque résultat doit avoir un responsable et une correction vérifiable.
Périmètre, disponibilités, prix et délai sont convenus avant votre engagement. La demande est gratuite ; elle ne lance pas de scan, ne réserve pas de créneau et ne vous oblige à aucun achat.
Les tests continus et les nouvelles vérifications automatiques après la sortie de modèles sont encore en développement. Les analyses actuelles et leurs suivis sont convenus individuellement.