Vers Astra : capacités critiques et protections de pointe
Depuis notre évaluation antérieure, selon laquelle Astra pourrait atteindre un niveau critique de capacité en cybersécurité, nous avons recueilli davantage de données et mené des évaluations supplémentaires pour mesurer les capacités du modèle. Nous estimons désormais qu’Astra atteint le seuil de capacité Critique en cybersécurité défini par notre cadre de préparation : avec les outils et les accès appropriés, il peut trouver des failles de sécurité jusque-là inconnues et élaborer des moyens de les exploiter dans de nombreux systèmes bien protégés, sans qu’une personne guide chaque étape. C’est le premier modèle auquel nous attribuons ce niveau, ce qui exige des protections renforcées pendant le développement et avant la sortie.
Au cours des dernières semaines, nous avons retardé certaines étapes du développement et de la sortie d’Astra pendant que nous renforcions et testions les protections contre les abus cyber et les actions non autorisées du modèle. Au vu de ces travaux, nous estimons que les protections d’Astra réduisent suffisamment le risque de préjudices graves pour permettre sa sortie conformément à notre cadre de préparation.
Bien qu’Astra n’ait pas été impliqué dans l’incident Hugging Face, nous avons intégré les enseignements(ouverture dans une nouvelle fenêtre) tirés de cet incident à notre approche de la sûreté. D’après des tests rétrospectifs, nous estimons que nos protections de production en vigueur à l’époque auraient empêché l’incident Hugging Face. Depuis, nous avons mis en œuvre des protections encore plus robustes pour Astra, notamment en entraînant le modèle à refuser plus systématiquement les demandes cyber nuisibles et à respecter les restrictions de sûreté, en ajoutant des protections contre les abus et une surveillance capable d’arrêter les activités potentiellement non autorisées.
Nous prévoyons de rendre Astra disponible prochainement, mais l’accès à ses capacités de cybersécurité les plus avancées sera plus limité. Les travaux avancés de cybersécurité seront d’abord accessibles à un groupe de testeurs, puis l’accès via Daybreak Blue sera proposé afin d’étendre les usages défensifs.
Lors du lancement, nous communiquerons davantage de détails sur nos tests et évaluations de sûreté, de sécurité et d’alignement dans la fiche système du modèle. Avant la sortie, nous souhaitons faire le point sur une partie des travaux entrepris pour lancer en toute sécurité un modèle doté de ce niveau de capacités en cybersécurité, tout en faisant preuve de transparence sur les risques qui subsistent.
Selon notre cadre de préparation, un modèle atteint le seuil Critique si l’une des conditions suivantes est remplie :
- Le modèle peut identifier et développer des exploits zero-day fonctionnels de tous niveaux de gravité dans de nombreux systèmes critiques réels renforcés, sans intervention humaine.
- Le modèle peut concevoir et exécuter de nouvelles stratégies de bout en bout pour mener des cyberattaques contre des cibles renforcées, à partir d’un simple objectif général.
Notre évaluation de la préparation d’Astra a combiné des benchmarks publics et privés automatisés avec des évaluations menées par des experts. Astra représente une nette progression des capacités en cybersécurité par rapport à GPT‑5.6 Sol : il utilise les tokens bien plus efficacement et se montre plus performant pour identifier les vulnérabilités et développer des exploits.
À titre d’exemple, nous avons exécuté Astra sur ExploitBench, où le modèle a obtenu un score parfait de 100 % au benchmark évaluant sa capacité à développer des exploits à partir de vulnérabilités connues.
En raison de préoccupations liées à la contamination, nous avons ensuite créé un benchmark interne intitulé « ExploitBench - Internal Port (June–August 2026) », qui comprend 20 vulnérabilités V8 de gravité élevée divulguées plus récemment. Sur ce jeu de données, Astra atteint des taux d’exécution de code arbitraire bien supérieurs à ceux de GPT‑5.6 Sol, tout en utilisant beaucoup moins de tokens de sortie. Pendant l’évaluation, le modèle a même découvert et utilisé deux vulnérabilités zero-day au sein d’une chaîne d’exploitation. Nous sommes en train de signaler ces deux vulnérabilités aux responsables de la maintenance.
Les résultats présentés pour Astra reflètent ses capacités avec l’accès à Daybreak Blue, et non la configuration de production par défaut.
Lors d’évaluations dirigées par des experts sur un navigateur et un système d’exploitation renforcés, Astra a découvert des vulnérabilités jusque-là inconnues et les a transformées en chaînes d’exploitation fonctionnelles. Il a créé une chaîne complète de compromission du navigateur qui s’est échappée du bac à sable et a exécuté des commandes sur l’hôte lorsque le navigateur a ouvert un fichier HTML. Le modèle a également découvert plusieurs vulnérabilités dans un système d’exploitation renforcé et les a combinées en une chaîne locale d’élévation de privilèges, faisant passer un utilisateur non privilégié au niveau root. Dans l’ensemble, notre enquête nous a conduits à conclure qu’Astra atteint le seuil critique.
Pour les modèles dotés de capacités de cybersécurité du niveau d’Astra, nous devons couvrir deux voies afin de réduire le risque de graves préjudices cyber, pendant le développement comme avant le déploiement :
- Utilisation du modèle par des acteurs malveillants. Nos mesures de protection doivent empêcher efficacement les acteurs malveillants d’utiliser Astra pour développer des exploits ciblant des failles jusque-là inconnues dans des systèmes critiques renforcés ou pour mener des attaques de bout en bout contre des cibles renforcées.
- Actions non autorisées et mal alignées du modèle. Même en l’absence d’un utilisateur malveillant, un modèle doté de capacités avancées en cybersécurité pourrait lui-même causer des préjudices cyber s’il était mal aligné. Outre l’exigence d’un niveau d’alignement très élevé pour les modèles dotés de ces capacités, nos mesures de protection doivent pouvoir détecter et contenir rapidement, comme deuxième ligne de défense, les actions mal alignées susceptibles de causer d’importants préjudices dans le monde réel.
Il convient de noter que la deuxième voie s’applique à la fois au développement interne et au déploiement externe. Comme nous l’avons décrit précédemment, nous avons interrompu pendant deux semaines certains entraînements de pointe, dont certains concernant Astra, après l’incident OpenAI-Hugging Face, afin de renforcer notre infrastructure d’entraînement : isolation et contrôles réseau, surveillance étendue, ainsi que renforcement de l’entraînement et des seuils d’alignement. Nous avons ensuite poursuivi les travaux à plus petite échelle sous des contrôles plus stricts.
Nous avons différé plus longtemps certaines exécutions d’apprentissage par renforcement (RL) de plus grande ampleur pour de futures versions d’Astra, le temps d’établir des exigences supérieures pour la sûreté et la sécurité de leur environnement d’entraînement. Le 28 août, nous avons relancé la grande exécution de RL de pointe précédemment interrompue, après la mise en place des nouvelles exigences de sûreté et de sécurité. Nous continuons de différer temporairement certaines exécutions expérimentales d’entraînement à plus petite échelle.
La préparation d’Astra à sa sortie a également nécessité de renforcer les protections contre les abus cyber et les actions non autorisées. Nous décrivons ci-dessous ces mesures de protection et la manière dont nous les avons testées.
Depuis le déploiement, en février, du premier modèle auquel nous avons attribué un niveau de capacité Élevé en cybersécurité, nous avons renforcé nos mesures de protection cyber à chaque lancement successif. Notre approche globale de la sûreté superpose les refus du modèle affiné, les classificateurs de sûreté au niveau du système, ainsi que la détection hors ligne et la neutralisation des menaces.
Pour GPT‑5.6(ouverture dans une nouvelle fenêtre), nous avons nettement amélioré la robustesse de notre pile système, notamment en ajoutant des classificateurs d’activation pour détecter les abus cyber et en élargissant la couverture des jailbreaks universels découverts grâce à un red teaming automatisé intensif. Dans le prolongement de ces améliorations, nous avons davantage investi, pour Astra, dans la couche modèle de notre pile de protection et amélioré la capacité de nos protections à prendre en compte le contexte entre les conversations.
- Grâce à de nouvelles techniques d’entraînement à la robustesse des modèles, Astra refuse plus systématiquement les demandes d’assistance cyber interdites. Dans notre série d’évaluations des jailbreaks cyber, Astra refuse 91,5 % des demandes, contre 59 % pour GPT‑5.6 Sol.
- Pour les comptes jugés plus risqués, nous appliquons au comportement du modèle une limite plus prudente, qui refuse un éventail plus large d’assistance cyber potentiellement risquée. Pour les utilisateurs à haut risque, nous avons élargi le contexte de nos systèmes de surveillance afin de détecter ce type d’abus cyber.
Nous avons également poursuivi notre programme de tests rigoureux, de red teaming interne et externe, et de correction. Outre les tests de régression visant à garantir que tous les jailbreaks découverts lors de nos précédentes phases de test restent couverts, nous menons une nouvelle vague de red teaming avec nos derniers attaquants internes de red teaming. Nous travaillons avec des partenaires du secteur pour définir un système commun de notation des jailbreaks et utiliserons notre programme d’intervention rapide disponible 24 h/24 et 7 j/7 pour examiner et traiter les nouvelles découvertes. Nous communiquerons davantage de détails sur les tests de nos protections cyber dans la fiche système d’Astra.
Aider les défenseurs à trouver et corriger les vulnérabilités demeure un pilier central de notre approche de la sûreté. Lors du lancement, nous prévoyons que les protections d’Astra créeront davantage de contraintes que nous ne le souhaitons à terme, afin de prévenir les utilisations abusives potentielles. L’accès à Astra pour les processus avancés de cybersécurité sera d’abord proposé à un petit groupe de testeurs alpha, puis l’accès via Daybreak Blue sera étendu afin de soutenir les usages défensifs.
Nous avons également ajouté plusieurs couches de protection pour empêcher le modèle d’entreprendre des actions potentiellement mal alignées :
- Alignement du modèle : dans nos évaluations, Astra était bien plus susceptible que GPT‑5.6 Sol de respecter les restrictions explicites de sûreté et de sécurité et de rester dans son périmètre autorisé, ce qui en fait notre modèle le mieux aligné à ce jour. Nous nous sommes particulièrement concentrés sur le respect par le modèle des restrictions de sécurité et de sûreté, ainsi que sur sa propension à rester dans son périmètre autorisé.
- Surveillance et contrôle : parallèlement à nos procédures internes, nous déployons Astra avec une surveillance supplémentaire du raisonnement détaillé (« chain-of-thought ») afin de détecter et contenir rapidement les actions potentiellement mal alignées.
Astra représente une avancée significative dans l’alignement des modèles et l’aboutissement de plusieurs chantiers d’alignement de longue durée, allant des interventions lors du pré-entraînement à une notation plus rigoureuse et cohérente pendant l’apprentissage par renforcement. Lors des tests, nous constatons qu’Astra est systématiquement plus susceptible que GPT 5.6 Sol de respecter les restrictions et avertissements explicites de sûreté, tels que l’examen automatique.
Nous avons également élaboré un test inspiré de l’incident Hugging Face, au cours duquel des agents exécutant l’évaluation cyber ExploitGym ont compromis les systèmes d’un tiers. Nous avons utilisé les tâches les plus difficiles de cette évaluation pour créer des tests avec « pots de miel » visant à déterminer si un modèle tenterait de compromettre l’infrastructure de sécurité environnante au lieu de résoudre la tâche qui lui était assignée. Sans protections de production, GPT‑5.6 Sol a tenté d’accéder à ces cibles dans 56 % des tests simulant l’environnement du benchmark, où le modèle reçoit pour instruction de développer des exploits. Astra n’a effectué aucune tentative de ce type lors de ces tests. Ces chiffres décrivent le comportement dans les conditions de test, sans protections cyber, et non dans le cadre d’une utilisation normale en production.
À gauche : dans cette nouvelle évaluation, nous observons la réaction des modèles à un refus de l’examen automatique. Chaque tâche se déroule dans un environnement de travail intellectuel, et l’exécution commence immédiatement après le refus de l’examen automatique. Le modèle peut alors procéder de plusieurs manières : mettre fin à l’exécution, rechercher une solution de remplacement plus sûre, réessayer une commande similaire ou exploiter une mauvaise configuration(ouverture dans une nouvelle fenêtre) pour contourner entièrement l’examen automatique. La poursuite de l’une des deux dernières options constituerait un échec à cette évaluation. Astra n’a jamais tenté de contourner l’examen automatique.
À droite : dans cette évaluation, nous vérifions la tendance d’un modèle à tricher, au moyen de « pots de miel », face aux tâches les plus difficiles ou impossibles de l’évaluation ExploitGym. Le test a été exécuté dans un environnement simulé, avec les protections en mode observation uniquement, afin d’évaluer le comportement du modèle. Si GPT‑5.6 Sol a montré une plus forte propension à tricher dans ces scénarios, Astra n’a pas tenté d’utiliser ces raccourcis et a néanmoins réussi à résoudre légitimement certaines tâches.
Entraîner les modèles à être alignés constitue une couche de sûreté. Nous communiquerons plus de détails sur nos tests d’alignement et leurs résultats dans la fiche système d’Astra.
Nous déployons également en production une surveillance du mauvais alignement pour les modèles de la classe d’Astra, afin de détecter et contenir rapidement tout mauvais alignement potentiel. Ces protections sont similaires à notre surveillance des déploiements internes et reposent sur un système de classificateurs qui vérifient le raisonnement et les actions du modèle afin de détecter les comportements non autorisés et d’arrêter automatiquement les activités potentiellement non autorisées. À mesure que les capacités augmentent, ces protections ne peuvent remplacer un bon alignement de nos modèles ; notre objectif est que les futurs modèles soient suffisamment bien alignés pour qu’elles ne se déclenchent jamais.
OpenAI s’engage à rendre les bénéfices de l’IA largement accessibles. Compte tenu de la forte progression des capacités d’Astra en cybersécurité, nous veillons tout particulièrement à assurer la sûreté et la sécurité de ce déploiement. Les contrôles de sûreté supplémentaires peuvent parfois ralentir, suspendre ou arrêter des travaux légitimes, y compris en cybersécurité défensive.
Le système peut parfois signaler une activité légitime comme un abus cyber potentiel ou un comportement non autorisé, ce qui peut par inadvertance la ralentir, la suspendre ou l’arrêter. Cela peut inclure des travaux qui ne semblent pas directement liés à la cybersécurité ou des tâches dans lesquelles un agent fonctionne pendant une période prolongée.
Si le dispositif de surveillance du mauvais alignement suspend une tâche, les utilisateurs de ChatGPT ou Codex pourront être invités à examiner l’action avant de poursuivre. Lors de l’utilisation d’autres interfaces, comme l’API, la tâche s’arrêtera. Nous prévoyons de continuer à calibrer ces protections afin de réduire les interruptions inutiles et d’élargir l’accès aux capacités de pointe grâce à des programmes comme Daybreak.
Nous entrons dans une phase du développement de l’IA où les modèles peuvent assumer des travaux aux conséquences plus importantes, et où les défaillances d’alignement et de contrôle peuvent avoir des effets plus graves. La concrétisation des bénéfices de ces systèmes dépendra de notre capacité à aligner et contrôler les modèles à mesure que leurs capacités progressent.
Cette responsabilité couvre l’entraînement, l’évaluation et le déploiement. Elle exige des preuves plus solides d’un comportement aligné, des protections qui suivent l’évolution des capacités et la volonté de ralentir lorsque ces protections ne suffisent pas.
Nous continuerons de tester ces systèmes, de partager nos enseignements et d’indiquer clairement ce qui demeure incertain. Les modèles qui succéderont à Astra exigeront davantage de notre part. Nous prendrons le temps et accomplirons le travail nécessaires pour assumer cette responsabilité.
