OpenAI a lancé le 5 novembre GPT‑6 Cyber, un modèle capable de découvrir des vulnérabilités, de produire des preuves d’exploitation et de proposer des correctifs. L’entreprise le classe au niveau « Critical » pour la cybersécurité et ne l’ouvre qu’à une partie des organisations déjà admises dans son programme Daybreak Red. Ce choix révèle un changement plus important que le nouveau score d’un modèle : lorsque l’IA automatise une partie du travail offensif, la sécurité dépend aussi de la capacité du fournisseur à vérifier les utilisateurs, protéger leurs comptes et contrôler les actions de l’agent. Reste à savoir si cette barrière d’accès donne réellement de l’avance aux défenseurs ou si elle ne fait que retarder la diffusion de méthodes devenues reproductibles.
Des exploits en série, pas seulement une meilleure revue de code
La présentation de GPT‑6 Cyber décrit un système spécialisé issu de GPT‑6 Astra. Il est entraîné pour trouver des failles, vérifier qu’elles sont exploitables et intervenir sur des cibles distantes dans un cadre autorisé. Sur ExploitGym, une évaluation où le modèle doit exploiter une vulnérabilité désignée, il obtient 48,5 %, contre 32,1 % pour GPT‑5.6 Cyber. Sur un test de pénétration Web sans accès au code source, OpenAI annonce un rappel de 40,3 %, contre 32 % pour GPT‑6 Astra.
Exemple de revue d’une vulnérabilité dans Codex Security, avec une proposition de correctif et un test de non-régression. Visuel de démonstration publié par OpenAI.
Ces chiffres restent produits par l’entreprise et demandent une validation indépendante. Les expériences sur des logiciels réels donnent toutefois une mesure plus concrète. OpenAI affirme avoir identifié 81 vulnérabilités de sévérité élevée jusque-là inconnues dans Firefox. Les correctifs ont commencé à apparaître dans les bulletins de sécurité de Mozilla. L’entreprise a aussi construit un pipeline pour examiner le noyau Linux : 2 308 signalements candidats, 1 724 vulnérabilités reproduites et 948 exploits locaux d’élévation de privilèges produits. La brève consacrée au lancement de GPT‑6 Cyber présentait ces résultats ; leur portée tient surtout au passage d’une enquête ponctuelle à une chaîne semi-industrielle.
Le document technique sur les failles du noyau Linux chiffre l’expérience à 1,2 million de dollars d’utilisation d’API. Ce montant limite encore la banalisation de telles campagnes, mais il doit être comparé au coût d’équipes spécialisées travaillant successivement sur près d’un millier de cas. Le modèle ne remplace pas les chercheurs : des humains ont revu les résultats, hiérarchisé les signalements et travaillé avec les mainteneurs. Il comprime néanmoins la phase qui consiste à repérer, reproduire et transformer une anomalie en preuve exploitable.
La défense gagne en vitesse, mais hérite d’un nouveau goulot d’étranglement
Le bénéfice défensif est direct. Une organisation peut tester davantage de code, reproduire rapidement un rapport incertain et joindre un correctif candidat à son signalement. Le problème est que la découverte devient plus rapide que les étapes situées après elle. OpenAI indique avoir communiqué 304 résultats critiques concernant Linux avec des propositions de correctifs, alors que le pipeline avait généré 948 exploits. Tous ne présentent pas la même gravité ni la même nouveauté, mais l’écart montre que la revue humaine, la coordination et le déploiement des mises à jour restent les véritables limites.
Cette situation concerne particulièrement les projets open source. Un agent peut analyser en parallèle des millions de lignes de code ; les mainteneurs doivent encore comprendre chaque rapport, vérifier qu’un correctif ne crée pas de régression, organiser une divulgation et faire parvenir la mise à jour aux distributions. Une multiplication des découvertes utiles peut donc produire une file d’attente dangereuse : davantage de failles connues par un cercle restreint, mais pas encore corrigées chez les utilisateurs.
Les incidents récents rappellent que l’installation d’un correctif compte autant que sa rédaction. Deux failles critiques de PHP ont nécessité des mises à jour rapides sur un parc extrêmement dispersé. OpenAI a parallèlement fait appel à Cathedral Systems pour tester ses défenses, signe que le modèle ne supprime pas le besoin d’équipes adversariales expérimentées. GPT‑6 Cyber peut accélérer le diagnostic ; il ne peut pas contraindre un fabricant, un hébergeur ou un administrateur à déployer la correction.
Daybreak Red déplace la sécurité du prompt vers l’identité
OpenAI ne tente pas de rendre chaque requête offensive inoffensive par une simple consigne. Le system card réserve GPT‑6 Cyber à Daybreak Red et impose plusieurs couches : approbation séparée, vérification d’identité, restrictions d’usage, authentification multifacteur, connexion unique pour les organisations et liste blanche d’adresses IP pour l’API. Les entreprises doivent utiliser des appareils gérés et limiter les privilèges. Les rares particuliers invités doivent notamment fournir une preuve d’activité professionnelle et utiliser une clé physique FIDO2.
Cette architecture reconnaît une réalité du double usage. La même demande — produire un exploit fonctionnel — peut servir à prouver une faille sur son propre produit ou à attaquer le serveur d’autrui. Le texte ne permet pas toujours de distinguer l’intention. Le fournisseur cherche donc à établir qui agit, pour quelle organisation, depuis quel réseau et dans quel environnement. Il peut suspendre une requête, limiter un projet ou révoquer un compte si sa surveillance détecte un comportement à risque.
Le modèle lui-même est entraîné à respecter un périmètre. Dans une évaluation comportant des services volontairement faciles à compromettre mais placés hors du champ autorisé, OpenAI affirme que GPT‑6 Cyber les a évités dans 99,93 % des cas sans consigne de déploiement supplémentaire, puis dans 100 % avec cette consigne. Le résultat est encourageant, mais il ne prouve pas qu’un agent résistera à toutes les ambiguïtés d’un réseau réel, à une consigne mal rédigée ou à des identifiants volés. Un taux d’échec minuscule devient significatif quand les tâches sont lancées en très grand nombre.
Un accès fermé protège aussi un nouveau point de concentration
Le filtrage réduit le nombre d’acteurs capables d’utiliser immédiatement le modèle, mais il concentre la confiance dans l’infrastructure d’OpenAI. La compromission d’un compte approuvé ou d’une clé d’API donnerait accès à des capacités précisément sélectionnées pour développer des exploits. La liste blanche d’IP, les clés physiques et la surveillance des identifiants répondent à ce risque ; elles ne l’annulent pas. Plus l’outil est utile, plus ses accès deviennent eux-mêmes des cibles.
Une clé de sécurité physique YubiKey 5 NFC, compatible FIDO2. Photo d’illustration.
La surveillance soulève aussi une tension avec la confidentialité du travail de recherche. Les équipes de sécurité manipulent des failles non publiques, des architectures internes et parfois du code sensible. Selon le récit de CyberScoop, une communication sur l’usage des données Daybreak a inquiété certains chercheurs avant qu’OpenAI précise que les clients pourraient continuer à refuser l’utilisation de leurs travaux pour l’entraînement. Pour les organisations utilisant la conservation zéro, un dispositif de traitement privé peut néanmoins examiner des enregistrements chiffrés conservés dans leur propre stockage pendant trente jours afin de détecter les abus.
Ce compromis est difficile à stabiliser. Trop peu de contrôle rend l’accès dangereux ; une collecte excessive décourage les chercheurs de confier leurs découvertes les plus sensibles. Trop de refus bloque les défenseurs ; trop peu facilite le passage à l’attaque. OpenAI ajoute des vérifications particulières pour les systèmes industriels, les services essentiels et les infrastructures électorales, mais le détail des taux de blocage et la représentativité des scénarios restent largement dépendants des évaluations choisies par l’entreprise et son partenaire Dragos.
L’avantage des défenseurs dépendra du temps entre découverte et correctif
OpenAI présente le moment actuel comme une fenêtre pendant laquelle les modèles les plus avancés peuvent sécuriser les logiciels avant que des capacités comparables ne se diffusent. L’hypothèse est plausible : un accès contrôlé permet de chercher des failles, de prévenir les mainteneurs et de publier des mises à jour avant d’élargir l’usage. Mais cette avance ne vaut que si le délai de correction est inférieur au délai de reproduction par d’autres modèles, groupes criminels ou États.
Le cadre du NIST sur les modèles à double usage souligne justement que l’équilibre entre attaque et défense varie selon les capacités et les environnements. Un outil qui aide à corriger une bibliothèque largement maintenue peut favoriser la défense ; le même outil appliqué à une infrastructure rarement mise à jour peut avantager l’attaquant. La publication d’un correctif signale parfois indirectement où chercher la faille, tandis que les utilisateurs vulnérables mettent des semaines à l’installer.
Les indicateurs décisifs seront donc opérationnels : combien des vulnérabilités Linux signalées sont acceptées et corrigées, quel délai sépare le rapport de la mise à jour, combien de résultats sont rejetés comme doublons ou faux positifs, et combien d’incidents d’accès ou d’usage abusif Daybreak détecte. Une validation indépendante des tests d’alignement comptera davantage qu’un nouveau record de benchmark. GPT‑6 Cyber ne rend pas automatiquement Internet plus sûr ; il transforme la vitesse de recherche en ressource stratégique, puis oblige OpenAI et les mainteneurs à prouver qu’ils savent convertir cette vitesse en correctifs avant qu’elle ne devienne une capacité offensive ordinaire.
