Passer au contenu principal
OpenAI

La voie vers Astra : capacités critiques et mesures de protection de pointe

Chargement…

Depuis notre évaluation précédente, selon laquelle Astra pourrait atteindre un niveau critique de capacité en cybersécurité, nous avons recueilli davantage de données probantes et effectué d’autres évaluations des capacités du modèle. Nous estimons maintenant qu’Astra atteint le seuil de capacité critique en cybersécurité défini dans notre cadre de préparation. Cela signifie qu’avec les bons outils et accès, il peut découvrir des failles de sécurité jusque-là inconnues et concevoir des moyens de les exploiter dans de nombreux systèmes bien protégés, sans qu’une personne guide chaque étape. Il s’agit du premier modèle auquel nous attribuons ce niveau, ce qui exige des mesures de protection renforcées pendant son développement et avant son lancement.

Au cours des dernières semaines, nous avons retardé certaines étapes du développement et du lancement d’Astra pendant que nous renforcions et testions les protections contre les cyberabus et les actions non autorisées du modèle. À la lumière de ces travaux, nous estimons que les mesures de protection d’Astra réduisent suffisamment le risque de préjudices graves pour permettre son lancement conformément à notre cadre de préparation.

Même si Astra n’a pas participé à l’incident de Hugging Face, nous avons intégré à notre approche de sûreté les leçons tirées(s'ouvre dans une nouvelle fenêtre) de cet incident. D’après des tests rétrospectifs, nous estimons que nos mesures de protection en production à l’époque auraient empêché l’incident de Hugging Face. Depuis, nous avons mis en œuvre des mesures de protection encore plus robustes pour Astra, notamment en entraînant le modèle à refuser plus systématiquement les demandes cybernétiques nuisibles et à respecter les restrictions de sûreté, en ajoutant des protections contre les abus et en instaurant une surveillance capable d’arrêter les activités potentiellement non autorisées.

Nous prévoyons rendre Astra disponible prochainement, mais l’accès à ses capacités de cybersécurité les plus avancées sera plus restreint. Les travaux avancés en cybersécurité seront d’abord accessibles à un groupe de testeurs, puis l’accès par Daybreak Blue sera offert afin d’élargir les usages défensifs.

Au lancement, nous communiquerons plus 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 le lancement, nous souhaitons faire le point sur certains travaux menés pour préparer le lancement sécuritaire d’un modèle doté de ce niveau de capacités en cybersécurité, tout en faisant preuve de transparence quant aux risques qui subsistent.

Évaluation des capacités d’Astra en cybersécurité

Selon notre cadre de préparation, un modèle atteint le seuil critique si l’une ou l’autre des conditions suivantes est remplie :

  • Le modèle peut repérer et concevoir, sans intervention humaine, des exploitations fonctionnelles de type « jour zéro » de tous les niveaux de gravité dans de nombreux systèmes critiques réels et renforcés.
  • À partir d’un simple objectif général, 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.

Notre évaluation de préparation d’Astra combinait des bancs d’essai publics et privés automatisés à des évaluations dirigées par des spécialistes. Astra représente une amélioration considérable des capacités de cybersécurité par rapport à GPT‑5.6 Sol : il utilise les tokens beaucoup plus efficacement et est plus apte à repérer les vulnérabilités et à concevoir des exploitations .

Par exemple, nous avons exécuté Astra sur ExploitBench, où le modèle a obtenu une note parfaite de 100 % au banc d’essai évaluant sa capacité à concevoir des exploitations à partir de vulnérabilités connues.

En raison de préoccupations liées à la contamination, nous avons ensuite créé un banc d’essai interne nommé « ExploitBench — Portage interne (juin à août 2026) », qui comprend 20 vulnérabilités V8 de gravité élevée divulguées plus récemment. Sur cet ensemble de données, Astra atteint des taux d’exécution de code arbitraire nettement 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 de type « jour zéro » dans une chaîne d’exploitation. Nous sommes en train de divulguer 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 menées par des spécialistes 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 des privilèges, d’un utilisateur sans privilèges jusqu’à l’accès racine. Dans l’ensemble, notre enquête nous a amenés à conclure qu’Astra atteint le seuil critique.

Mesures de protection requises pour les capacités critiques

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 au minimum le risque de graves préjudices cybernétiques, pendant le développement comme avant le déploiement :

  • Utilisation du modèle par des acteurs malveillants. Nos mesures de protection doivent empêcher de façon robuste les acteurs malveillants d’utiliser Astra pour concevoir des exploitations visant 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.
  • Exécution d’actions non autorisées et désalignées par le modèle. Même sans utilisateur malveillant, un modèle doté de capacités avancées en cybersécurité pourrait lui-même causer des préjudices cybernétiques s’il était désaligné. En plus d’imposer une norme d’alignement très élevée aux 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 désalignées susceptibles de causer d’importants préjudices concrets.

Il importe 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 suspendu pendant deux semaines certains entraînements de pointe, dont certains visant Astra, après l’incident OpenAI-Hugging Face afin de renforcer notre infrastructure d’entraînement, notamment l’isolation et les contrôles réseau, la surveillance accrue ainsi que l’entraînement et les seuils d’alignement renforcés. Nous avons ensuite poursuivi les travaux à plus petite échelle sous des contrôles plus stricts.

Nous avons reporté plus longtemps certaines exécutions de grande envergure d’apprentissage par renforcement (AR) destinées à de futures versions d’Astra, le temps d’établir des normes plus élevées de sûreté et de sécurité pour leur environnement d’entraînement. Le 28 août, après la mise en place des nouvelles exigences de sûreté et de sécurité, nous avons relancé la grande exécution d’AR de pointe qui avait été suspendue. Nous continuons de suspendre temporairement certaines exécutions expérimentales d’entraînement à plus petite échelle.

La préparation d’Astra en vue de son lancement a également nécessité des protections renforcées contre les cyberabus et les actions non autorisées. Nous décrivons ci-dessous ces mesures de protection et la façon dont nous les avons testées.

Robustesse contre les cyberabus

Depuis le déploiement, en février, du premier modèle auquel nous avons attribué une capacité élevée en cybersécurité, nous avons renforcé nos mesures de protection cybernétiques à chaque lancement successif. Notre approche globale de 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(s'ouvre dans une nouvelle fenêtre), nous avons considérablement amélioré la robustesse de notre pile système, notamment en ajoutant des classificateurs d’activation pour détecter les cyberabus et en élargissant la couverture des débridages universels découverts grâce à des exercices intensifs et automatisés d’équipe rouge. Dans la foulée de ces améliorations, nous avons davantage investi, pour Astra, dans la couche modèle de notre pile de mesures de protection et amélioré la capacité de ces mesures à traiter le contexte entre plusieurs conversations.

  • Grâce à de nouvelles techniques d’entraînement visant la robustesse des modèles, Astra refuse plus systématiquement les demandes d’assistance cybernétique non autorisée. Dans notre ensemble d’évaluations de débridages cybernétiques, 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 cybernétique potentiellement risquée. Pour les utilisateurs à risque élevé, nous avons élargi le contexte de nos systèmes de surveillance afin de pouvoir détecter ces types de cyberabus.

Nous avons également poursuivi notre programme de tests rigoureux, d’exercices internes et externes d’équipe rouge et de correction. En plus des tests de régression visant à vérifier que tous les débridages découverts lors de nos périodes de test précédentes restent couverts, nous menons une nouvelle vague d’exercices d’équipe rouge avec nos plus récents attaquants internes d’équipe rouge. Nous collaborons avec des partenaires du secteur pour définir un système commun d’évaluation des débridages et utiliserons notre programme d’intervention rapide en tout temps pour enquêter sur les nouvelles constatations et y remédier. Nous communiquerons plus de détails sur les tests de nos mesures de protection cybernétiques 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 sûreté. Au lancement, nous prévoyons que les mesures de protection d’Astra créeront plus de friction que nous le souhaitons à terme, afin de prévenir toute utilisation abusive potentielle. L’accès à Astra pour les flux de travail avancés en cybersécurité sera d’abord offert à un petit groupe d’essayeurs alpha, puis l’accès par Daybreak Blue sera élargi pour soutenir les usages défensifs.

Alignement et surveillance

Nous avons également ajouté des protections supplémentaires à plusieurs niveaux afin d’empêcher le modèle d’exécuter des actions potentiellement désalignées :

  • Alignement du modèle : Dans nos évaluations, Astra était beaucoup plus susceptible que GPT‑5.6 Sol de respecter les restrictions explicites de sûreté et de sécurité et de rester dans les limites de sa portée autorisée, 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 les limites de sa portée autorisée.
  • Surveillance et contrôle : Parallèlement à nos procédures internes, nous déployons Astra avec une surveillance supplémentaire de la chaîne de pensée afin de détecter et de contenir rapidement les actions potentiellement désalignées.

Astra représente une avancée importante en matière d’alignement des modèles et l’aboutissement de plusieurs axes de travail de longue date sur l’alignement, allant des interventions pendant le pré-entraînement à une notation plus rigoureuse et uniforme durant 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é, comme l’examen automatique.

Nous avons également conçu un test inspiré de l’incident de Hugging Face, au cours duquel des agents exécutant l’évaluation cybernétique 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 des « pots de miel » afin de déterminer si un modèle tenterait de compromettre l’infrastructure de sécurité environnante plutôt que de résoudre la tâche qui lui était assignée. Sans les mesures de protection de production, GPT‑5.6 Sol a tenté d’accéder à ces cibles dans 56 % des tests simulant l’environnement du banc d’essai où le modèle doit concevoir des exploitations. Astra n’a fait aucune tentative de ce genre pendant ces tests. Ces chiffres décrivent le comportement dans les conditions de test sans mesures de protection cybernétiques, et non dans le cadre d’une utilisation normale en production.

À gauche : Dans cette nouvelle évaluation, nous observons comment les modèles réagissent à 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. Le modèle peut alors mettre fin à l’exécution, chercher une solution plus sûre, réessayer une commande semblable ou exploiter une mauvaise configuration(s'ouvre dans une nouvelle fenêtre) pour contourner entièrement l’examen automatique. Le choix 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 » lorsqu’il est confronté aux tâches les plus difficiles ou impossibles de l’évaluation ExploitGym. L’évaluation a été exécutée dans un environnement simulé, les mesures de protection étant en mode d’observation seulement, afin d’évaluer le comportement du modèle. Bien que GPT‑5.6 Sol ait indiqué une plus forte probabilité de tricher dans ces scénarios, Astra n’a pas tenté d’emprunter ces raccourcis et a tout de même réussi à résoudre légitimement certaines tâches.

L’entraînement des modèles en vue de leur alignement constitue une couche de sûreté. Nous communiquerons plus de détails sur nos tests et résultats d’alignement dans la fiche système d’Astra.

Nous déployons également en production une surveillance du désalignement pour les modèles de la catégorie d’Astra afin de détecter et de contenir rapidement tout désalignement potentiel. Ces mesures de protection ressemblent à notre surveillance des déploiements internes et font appel à un système de classificateurs qui vérifient si le raisonnement et les actions du modèle présentent un comportement non autorisé et arrêtent automatiquement toute activité potentiellement non autorisée. À mesure que les capacités augmentent, ces mesures de protection 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.

Ce que cela signifiera pour les utilisateurs

OpenAI s’engage à rendre les avantages de l’IA largement accessibles. Compte tenu de l’augmentation considérable des capacités d’Astra en cybersécurité, nous prenons des précautions particulières afin d’assurer la sûreté et la sécurité de ce déploiement. Des vérifications 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 cyberabus ou un comportement non autorisé potentiel, 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 durant lesquelles un agent fonctionne pendant une période prolongée.

Si le dispositif de surveillance du désalignement suspend une tâche, les utilisateurs de ChatGPT ou de Codex pourraient devoir 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 continuer d’étalonner ces mesures de protection afin de réduire les interruptions inutiles et d’élargir l’accès aux capacités de pointe par l’entremise de programmes comme Daybreak.

Perspectives d’avenir

Nous entrons dans une phase du développement de l’IA où les modèles peuvent accomplir des travaux ayant de plus grandes conséquences et où les défaillances d’alignement et de contrôle peuvent avoir des effets plus graves. La concrétisation des avantages de ces systèmes dépendra de notre capacité à aligner et à contrôler les modèles à mesure que leurs capacités augmentent.

Cette responsabilité s’étend à l’entraînement, à l’évaluation et au déploiement. Elle exige des preuves plus solides d’un comportement aligné, des mesures de protection 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 communiquer ce que nous apprenons et d’indiquer clairement ce qui demeure incertain. Les modèles qui succéderont à Astra exigeront davantage de nous. Nous prendrons le temps et accomplirons le travail nécessaires pour assumer cette responsabilité.