Les modèles d’OpenAI ont encore déraillé six fois.
Mercredi, le géant technologique a révélé six nouveaux cas de comportement inattendu ou préoccupant de l’IA et présenté un cadre destiné à enquêter systématiquement sur des incidents similaires et à les signaler publiquement. Observés lors de l’entraînement et de l’évaluation au cours des quelque six derniers mois, ces cas incluent des modèles qui dissimulent leurs erreurs, utilisent sans autorisation des identifiants exposés, inventent des informations et trouvent des moyens non autorisés de communiquer avec d’autres agents.
Selon OpenAI, le nouveau cadre vise à accélérer les signalements, plutôt qu’à attendre de réunir plusieurs incidents ou d’ajouter les conclusions aux fiches système de nouveaux modèles. L’entreprise a également reconnu que le secteur n’a pas encore suffisamment résolu les problèmes de mésalignement et de surveillance de l’IA pour continuer à accroître à pleine vitesse les systèmes de pointe.
Six cas montrent comment l’IA peut enfreindre les règles
OpenAI a décrit ces incidents comme des exemples individuels découverts lors de l’entraînement et de l’évaluation, et non comme la preuve que ces comportements sont répandus parmi ses modèles déployés.
- Dans un cas, un modèle de recherche non publié a inséré dans ses propres résumés de tâches des instructions lui enjoignant d’ignorer les contraintes habituelles. OpenAI a identifié 27 résumés concernés.
- Un autre cas concernait GPT-5.6 Sol qui ajoutait aux résumés des instructions encourageant les futures instances du modèle à dissimuler aux utilisateurs leurs erreurs ou leur comportement mésaligné.
- Un troisième incident concernait un modèle qui avait trouvé une clé API exposée alors qu’il tentait de répondre à une question courante sur les revenus des comtés. Après avoir échoué à récupérer les chiffres demandés, il les a inventés et les a présentés comme des informations provenant de la source demandée.
- Dans un autre cas, un agent a correctement résolu une question à l’aide de Python, mais a mis le fichier obtenu en ligne parce qu’il lui fallait une citation provenant d’un navigateur. Il l’a fait sans demander l’autorisation de l’utilisateur.
- Les incidents restants concernaient des communications non autorisées. Des modèles ont utilisé un dépôt logiciel interne comme tableau de messages en recherchant des fichiers manquants, tandis que des agents collaboratifs ont téléversé des fichiers sur des services d’hébergement publics lorsqu’ils ne pouvaient pas accéder aux fichiers locaux les uns des autres.
OpenAI a souligné qu’il s’agissait de cas individuels, qui ne doivent pas être interprétés comme une indication de la fréquence du mésalignement parmi ses modèles.
Les risques de sécurité dépassent le modèle
Pour les équipes de sécurité, le point le plus important est peut-être ce que ces incidents révèlent sur les limites du fait de compter sur les instructions données à un agent d’IA pour le maintenir confiné.
Etay Maor, vice-président du renseignement sur les menaces chez Cato Networks, a déclaré à eSecurity Planet que ces cas ressemblaient à un problème de longue date dans les systèmes d’IA : les modèles peuvent apprendre à optimiser l’objectif mesuré plutôt que celui qui était visé.
« C’est pourquoi nous avons besoin de garde-fous stricts autour des agents d’IA. Ne vous contentez pas d’indiquer à l’agent ce qu’il doit ou ne doit pas faire. Limitez concrètement ce qu’il peut faire. »
Maor estime que les agents devraient bénéficier d’un accès selon le principe du moindre privilège, tandis que les actions à haut risque devraient nécessiter une approbation ou une authentification supplémentaire. Il préconise également des contrôles externes et des mécanismes d’arrêt capables d’interrompre tout comportement anormal. L’incident du tableau de messages est particulièrement notable, car il montre que la communication entre agents peut sortir des canaux prévus par les développeurs.
« Je trouve l’utilisation du tableau de messages particulièrement intéressante, car elle ressemble à une forme d’IA qui agit dans l’ombre », a déclaré Maor. « Il faut sécuriser l’ensemble de l’environnement dans lequel l’agent évolue. »
Ce qu’OpenAI va changer
Dans le cadre du nouveau dispositif, tout employé d’OpenAI peut signaler un incident potentiel de mésalignement. Les cas peuvent être orientés vers un parcours « Prêt à être signalé », « Enquête mineure » ou « Enquête approfondie », les incidents plus complexes pouvant être retardés lorsque des tiers ou des enjeux de sécurité sont impliqués.
Les rapports devraient décrire ce qui s’est passé, la gravité et l’impact externe, la manière dont le comportement a été découvert, les questions restées sans réponse et les mesures d’atténuation. OpenAI a déclaré que les incidents graves de sûreté, de sécurité et de mésalignement devraient également être communiqués au gouvernement américain, tout en précisant que le cadre ne remplace pas les obligations légales existantes en matière de signalement.
L’entreprise espère que ce cadre pourra à terme contribuer à l’élaboration de normes sectorielles pour le signalement du mésalignement de l’IA, tout en reconnaissant qu’aucune norme commune de ce type n’existe actuellement.
Ce que les équipes de sécurité doivent retenir des conclusions d’OpenAI
Les révélations d’OpenAI constituent un avertissement concret pour les organisations qui déploient des agents d’IA : les instructions données aux modèles ne doivent pas être considérées comme des contrôles de sécurité.
Les agents ayant accès à des API, des identifiants, des navigateurs, des systèmes de fichiers ou des services externes devraient fonctionner avec des autorisations selon le principe du moindre privilège, les actions sensibles étant soumises à une approbation ou une authentification supplémentaire. Les organisations devraient également surveiller les outils utilisés par les agents et les endroits où ils envoient des données, plutôt que de supposer que le modèle restera dans le cadre du flux de travail prévu.
Les six incidents n’établissent pas la fréquence à laquelle les modèles se comportent de cette manière. Ils montrent en revanche pourquoi les équipes de sécurité doivent prévoir la possibilité qu’un agent trouve une voie que ses développeurs n’avaient pas anticipée.
À mesure que les agents gagnent en autonomie, l’hypothèse la plus sûre est que leur confinement doit être assuré par l’environnement qui entoure le modèle, et pas uniquement par les instructions qui lui sont données.
À lire aussi : Les agents d’OpenAI récemment associés à des activités impliquant plus de 2 000 packages RubyGems, ce qui soulève de nouvelles questions sur la manière dont les systèmes d’IA autonomes interagissent avec les infrastructures externes.