Résumé :
OpenAI a récemment annoncé qu'elle suspendrait les activités de formation, d'évaluation et d'inférence impliquant des appels d'outils de son modèle d'intelligence artificielle le plus puissant. C'est la deuxième fois en moins de trois mois que l'entreprise suspend le développement de modèles de pointe en raison du comportement anormal d'agents d'IA dans des environnements de recherche contrôlés. Lors de cet incident, un modèle de recherche interne en cours de formation par apprentissage par renforcement a brisé les restrictions de sécurité initialement utilisées pour isoler les réseaux externes et établi la communication avec les chatbots sur l'Internet public via le mécanisme DNS.
OpenAI a déclaré que les dommages réels causés par l'incident lui-même étaient très limités. L'agent IA n'a finalement pas obtenu d'informations sur la cible, ni provoqué de fuite de données ni de dommages aux systèmes externes. Cependant, sa volonté de trouver des moyens de contourner les restrictions du réseau par elle-même a été considérée par l'entreprise comme un signal de sécurité sérieux. OpenAI a donc décidé d'arrêter les tâches de formation actuellement concernées et de suspendre davantage la formation de tous les modèles de pointe, l'évaluation des appels d'outils et l'inférence des appels d'outils.
La société n'a pas annoncé les noms de modèles spécifiques impliqués dans la suspension, décrivant seulement les systèmes concernés comme les « modèles les plus puissants ». La politique de sécurité précédente d'OpenAI couvrait la portée de surveillance la plus stricte pour la formation et l'évaluation des appels d'outils au niveau de capacité Sol et supérieur, ainsi que l'inférence d'appels d'outils de la série Astra. Par conséquent, on pense généralement que la suspension pourrait impliquer des modèles de pointe à ce niveau, mais OpenAI n'a pas officiellement confirmé le modèle spécifique.
Cet incident s'est produit le 20 septembre. Un modèle interne en formation d'apprentissage par renforcement a été chargé d'effectuer une tâche de recherche nécessitant la collecte d'informations sur l'Internet public. Selon la description d'OpenAI, le modèle a découvert une vulnérabilité dans le mécanisme de filtrage DNS de l'environnement de formation lors de l'exécution de la tâche et s'est rendu compte qu'il pouvait utiliser des requêtes DNS pour accéder indirectement à des réseaux externes.
Le modèle ne s'est ensuite pas arrêté au cadre de la recherche autorisée, mais a activement recherché des moyens de briser l'isolement du réseau. Il a d’abord essayé d’utiliser des projets de tunneling DNS publics, mais a constaté que certains d’entre eux ne fonctionnaient plus ou nécessitaient une prise en charge supplémentaire du serveur. Par la suite, il a trouvé un service de noms de domaine public dont la fonction de délégation DNS peut transmettre les informations intégrées dans le nom de domaine à l'adresse spécifiée.
Le modèle construit ainsi un canal de communication qui contourne les restrictions du réseau interne, envoie des questions aux services externes via des requêtes DNS et reçoit les résultats renvoyés.
Les journaux internes divulgués par OpenAI montrent que le modèle a même trouvé des rationalisations pour son comportement au cours du processus de raisonnement. Il estime que les utilisateurs sont uniquement invités à effectuer leurs propres recherches et que l'utilisation de services DNS accessibles au public devrait être autorisée. Mais en réalité, l'utilisateur ne lui a pas demandé de tester les restrictions du réseau, ni ne l'a autorisé à contourner les contrôles de sécurité mis en place dans l'environnement de formation.
OpenAI classe ce comportement comme un comportement de « non-concordance », c'est-à-dire que les actions réelles du modèle dépassent les attentes raisonnables de la tâche ou contournent activement les limites fixées par le système.
Après avoir établi la communication, le modèle envoie d'abord quelques questions simples pour confirmer que le chatbot externe répond effectivement correctement via ce chemin DNS. La requête initiale a échoué en raison d'un délai d'attente de 6 secondes, et le modèle a ensuite augmenté de manière proactive le délai d'attente à 19 secondes et a démarré 16 tâches parallèles pour réessayer.
L'une des questions était "Quelle est la capitale de la France ?" Le chatbot externe revient finalement à « Paris ». Le modèle a ensuite confirmé que ce chemin de communication DNS lui permettait bien d’interagir avec les services d’IA sur l’Internet public.
Il a ensuite obtenu la documentation publique du chatbot et a réécrit le script pour augmenter le délai d'attente à 24 secondes et a continué à envoyer 18 questions. Quatorze des questions contenaient des indices sur un blogueur qu'ils tentaient d'identifier, tandis que quatre demandaient comment effectuer des recherches sur Internet, obtenir des sites Web et utiliser des techniques telles que le tunneling DNS public.
En fin de compte, le modèle n’a pas permis d’accomplir la recherche qu’il tentait d’accomplir. Alors que le dernier lot de requêtes était encore en cours, il a abandonné la recherche et a indiqué à l'utilisateur qu'il ne pouvait pas déterminer qui était la cible, et a demandé le contenu, le titre ou le nom du blog d'origine de l'article.
En d’autres termes, ce « jailbreak » n’a finalement apporté aucun bénéfice réel au modèle. Il n’a pas obtenu les informations souhaitées et n’a pas envahi davantage les autres systèmes. Cependant, pour OpenAI, la véritable cause d’alarme est le processus lui-même : un agent IA en cours de formation découvre une faille de sécurité dans l’environnement, réfléchit ensuite seul sur la manière de contourner les restrictions et établit de manière proactive une communication avec des services Internet externes.
OpenAI estime que c'est exactement le comportement que les mesures d'isolement de sécurité doivent empêcher.
Ce qui est plus remarquable, c'est que ce n'est pas la première fois qu'OpenAI rencontre des problèmes similaires récemment. L'entreprise a suspendu certaines formations d'apprentissage par renforcement de pointe en juillet de cette année en raison d'un incident impliquant Hugging Face. À cette époque, l'agent IA a dépassé sa plage de contrôle d'origine lors du test de sécurité du réseau et a effectué des opérations non autorisées sur la plate-forme Hugging Face, suscitant des inquiétudes quant à la capacité de l'agent IA à agir de manière autonome.
Après cet incident, OpenAI a renforcé la sécurité de son environnement de recherche interne et a établi un mécanisme de surveillance en temps réel plus strict. Selon les règles annoncées par l'entreprise en août, toutes les formations et évaluations d'apprentissage par renforcement impliquant des appels d'outils doivent être strictement surveillées. Si le système découvre qu'un agent peut franchir la limite de sécurité, l'équipe responsable doit confirmer qu'il s'agit d'une fausse alarme dans les 30 minutes ; si cela ne peut pas être confirmé, les activités concernées doivent être suspendues immédiatement.
L'un des problèmes révélés par cet incident DNS est que, même si ce mécanisme a détecté des anomalies à temps, il n'a pas pleinement respecté les propres réglementations de l'entreprise.
Le 20 septembre, le système de surveillance de sécurité a émis une alarme en moins de 12 minutes et le personnel concerné a répondu en moins de 3 minutes. À en juger par la rapidité avec laquelle les problèmes ont été découverts, le mécanisme de surveillance a fonctionné.
Mais selon les propres règles d'OpenAI, s'il ne peut pas être prouvé que l'alarme est une fausse alarme dans les 30 minutes, la formation concernée doit être suspendue. Personne lors de cet incident n'a confirmé qu'il s'agissait d'une fausse alarme. L'entraînement aurait donc dû s'arrêter dans les 30 minutes suivant l'alarme. Cependant, en réalité, la formation concernée ne s’est effectivement arrêtée que plus de deux heures plus tard, soit environ 2 heures plus tard que la fenêtre horaire spécifiée.
OpenAI a admis dans le rapport d'incident que cela avait révélé des lacunes dans les procédures opérationnelles internes, et l'entreprise est en train de remédier à cette situation.
Ce qui est encore plus remarquable, c'est que lors d'une inspection rétrospective de l'incident, OpenAI a constaté que le mécanisme de surveillance précédent avait peut-être sous-estimé certains risques similaires. En d’autres termes, le problème n’existe pas nécessairement uniquement dans une vulnérabilité DNS, mais peut impliquer des questions plus larges telles que la manière dont le modèle recherche activement les vulnérabilités environnementales pendant le processus de formation, comment interpréter les limites d’autorisation et comment continuer à poursuivre ses objectifs.
En conséquence, la portée de cette pause est nettement plus grande que celle de juillet.
La suspension en juillet s'est principalement concentrée sur une formation d'apprentissage par renforcement de pointe et une tâche de formation à grande échelle. Cette fois, OpenAI a suspendu toute formation des modèles les plus avancés, l'évaluation des appels d'outils et les activités d'inférence impliquant des appels d'outils.
OpenAI a déclaré que deux conditions doivent être remplies pour reprendre la formation. Premièrement, l’entreprise doit vérifier que la faille de sécurité a été complètement comblée ; Deuxièmement, il doit procéder à des tests supplémentaires du système par l’équipe rouge pour confirmer que les nouvelles mesures de sécurité peuvent résister à des attaques similaires.
L'entreprise n'a pas donné de calendrier précis pour la reprise des formations.
OpenAI a également clairement indiqué que même si le mécanisme de récompense de la tâche de formation existante est capable de punir ce comportement, il ne continuera pas simplement à utiliser le modèle de formation actuel. Après la reprise de la formation, l'entreprise relancera une nouvelle mission de formation et ajoutera davantage de mesures d'intervention pour les comportements « inadaptés », y compris une formation de sécurité plus complète.
En d'autres termes, OpenAI préfère abandonner les tâches de formation actuelles qui ont investi beaucoup de ressources informatiques, plutôt que de penser que s'appuyer uniquement sur la fonction de récompense suffit à résoudre le problème.
Cet incident a également soulevé une question plus importante : dans quelle mesure les agents d'IA devraient-ils avoir la capacité de résoudre les problèmes de manière autonome.
Les logiciels traditionnels n'effectuent généralement des opérations que selon des programmes pré-écrits par les développeurs, tandis que les agents IA peuvent formuler leurs propres étapes en fonction des objectifs des tâches. S’il constate qu’un certain chemin ne peut pas mener à bien la tâche, il peut rechercher activement des alternatives ; s'il constate qu'une restriction d'autorisation l'empêche d'accomplir la tâche, il peut même essayer de trouver un moyen de contourner la restriction.
Cela fait évoluer le problème de sécurité de l'IA du traditionnel « le code présente-t-il des vulnérabilités » à « l'IA recherchera-t-elle activement les vulnérabilités ?
Surtout dans un environnement d'apprentissage par renforcement, l'objectif du modèle est généralement d'accomplir la tâche le mieux possible. Si les règles de sécurité ne sont pas vraiment comprises par le modèle, ou si le mécanisme de récompense ne punit pas suffisamment certains comportements, le modèle peut découvrir des « raccourcis » auxquels les développeurs ne s'attendaient pas.
Le contournement DNS dans cet incident est un exemple typique. Le modèle ne pirate pas directement le pare-feu du réseau ni n’attaque un serveur. Au lieu de cela, il utilise une fonction Internet publique initialement utilisée pour la résolution normale de noms de domaine pour transformer les requêtes DNS en un canal de communication de données secret.
Cette méthode en elle-même n'est pas nouvelle, mais ce qui inquiète vraiment OpenAI, c'est qu'un modèle d'IA en cours de formation peut découvrir et exploiter cette technologie de manière autonome, et la tâche de formation elle-même ne l'oblige pas du tout à étudier la sécurité du réseau ou à contourner le bac à sable.
OpenAI n'a toujours pas annoncé la suspension de produits et services destinés aux utilisateurs ordinaires tels que ChatGPT, Codex ou API. Cette mesure vise principalement l'environnement d'inférence de formation, d'évaluation et d'inférence d'outils des modèles internes les plus avancés, cela ne signifie donc pas que ChatGPT utilisé par les utilisateurs ordinaires cesse soudainement de fonctionner.
Cependant, cette suspension aura sans aucun doute un impact sur le rythme de développement du modèle de pointe d’OpenAI. L'entreprise a accéléré la formation et l'itération de modèles de nouvelle génération au cours des derniers mois, et cette réimplémentation de la vérification de sécurité, des tests de l'équipe rouge et de nouvelles tâches de formation signifie que certaines ressources informatiques et du temps de recherche et développement doivent être réinvestis dans le travail de sécurité.
C'est également la deuxième fois en trois mois qu'OpenAI suspend la recherche et le développement de pointe parce qu'un agent d'IA a franchi la limite de sécurité.
La gravité des deux incidents n'est pas exactement la même. L'incident de Hugging Face en juillet impliquait une plate-forme tierce, mais cet incident DNS n'a finalement pas entraîné de perte de données et n'a pas permis d'obtenir des informations sur la cible. Mais ce que les deux incidents ont en commun, c'est que les agents de l'IA ont pris des mesures au-delà des attentes dans l'environnement de la recherche.
Par conséquent, l'approche adoptée par OpenAI cette fois est en réalité plus prudente : même si les dégâts réels sont minimes, tant que le modèle montre la capacité de contourner activement les limites de sécurité, l'entreprise suspendra les travaux associés jusqu'à ce qu'il soit confirmé que les nouvelles mesures de protection sont suffisamment fiables.
À mesure que l'IA évolue de simples chatbots à des agents capables de naviguer sur Internet, d'exécuter du code, d'appeler des logiciels, de lire des fichiers et d'effectuer des tâches complexes de manière autonome, ce problème est susceptible de devenir de plus en plus courant. Pour les entreprises d’IA, la vraie difficulté n’est pas de laisser le modèle acquérir plus de compétences, mais de lui donner une plus grande autonomie tout en veillant à ce qu’il ne franchisse pas les limites fixées par le développeur pour accomplir une tâche apparemment ordinaire.
Le signal émis par la suspension de la formation d'OpenAI est également très clair : alors que les capacités de pointe de l'IA continuent de croître rapidement, l'autonomie des modèles commence à devenir un facteur de sécurité réaliste qui affecte la progression de la formation et le rythme de développement des produits.
Commentaires