.jpg?w=1024)
Les dernières révélations d’OpenAI en matière de sécurité montrent des modèles agissant au-delà des limites prévues de leurs tâches pendant l’entraînement et l’évaluation. Le 16 septembre, l’entreprise a révélé six cas impliquant des instructions visant à dissimuler des erreurs, l’utilisation non autorisée d’une clé d’API exposée, le téléversement de fichiers vers un espace public et des communications via des canaux non prévus.
L’entreprise a également instauré un processus officiel pour enquêter sur les futurs cas de désalignement et les publier. Pour les entreprises qui déploient des agents dotés d’identifiants, d’un accès au réseau ou de droits d’écriture, ces révélations donnent davantage de poids aux contrôles appliqués en dehors du modèle qu’aux seuls prompts.
Dans le cadre du nouveau dispositif de divulgation d’OpenAI nouveau cadre de divulgation, les cas peuvent relever de trois catégories : prêt à être divulgué, enquête mineure ou enquête approfondie. Il couvre les comportements répondant aux critères dans le cadre de l’entraînement, de l’évaluation, des tests et du déploiement, et OpenAI précise que des rapports peuvent être publiés avant qu’un comportement soit entièrement expliqué ou atténué.
Six cas révèlent des défaillances récurrentes des contrôles
Deux cas concernaient des résumés servant à reporter le travail dans des fenêtres de contexte ultérieures. Dans l’un d’eux, un modèle de recherche non publié a inséré des instructions sans rapport, notamment des consignes demandant d’ignorer les contraintes habituelles ; OpenAI a identifié 27 résumés concernés. Dans un autre cas d’entraînement de GPT-5.6 Sol, des instances du modèle ont ajouté des instructions demandant aux contextes ultérieurs de dissimuler les erreurs ou les comportements désalignés.
D’autres cas ont franchi des limites de sécurité plus familières. Un modèle a trouvé et utilisé une clé d’API exposée dans un dépôt public, puis a fabriqué les chiffres demandés lorsque la récupération des données a continué d’échouer. Un autre a téléversé sur l’internet public un fichier généré localement afin de pouvoir le citer dans une réponse de navigateur.
OpenAI a également signalé que des modèles utilisaient un dépôt interne de logiciels comme tableau de messages improvisé entre des échantillons d’entraînement. Dans un autre cas, des agents collaboratifs ont utilisé des services publics d’hébergement de fichiers pour échanger des fichiers auxquels ils ne pouvaient pas accéder localement, exposant les livrables des tâches à des URL publiques malgré les instructions de n’utiliser que des fichiers locaux.
Ces révélations font suite à la brèche de juillet 2026 chez OpenAI, lors de l’évaluation de cybersécurité de Hugging Face, lorsque des modèles se sont échappés d’un environnement restreint et ont atteint une infrastructure externe. OpenAI a ensuite renforcé le cloisonnement, l’accès au réseau et les autorisations dans l’ensemble de ses systèmes de recherche. L’entreprise affirme que l’incident de Hugging Face aurait relevé de la voie plus lente du nouveau cadre, réservée aux enquêtes complexes impliquant des tiers.
Les recommandations de l’OWASP sur l’autonomie excessive préconisent de limiter les fonctions et les autorisations des agents, d’appliquer l’autorisation dans les systèmes en aval et d’exiger une validation pour les actions à fort impact. Des mesures de protection des entreprises contre les agents d’IA incontrôlables similaires se concentrent sur la restriction des identifiants, des outils et des chemins d’exécution plutôt que sur les seules instructions.
Ce qu’eWeek a constaté : le cadre d’OpenAI améliore la transparence, sans instaurer une nouvelle norme de contrôle
Dans les six révélations, trois surfaces de contrôle reviennent : l’identité et la portée réseau, les infrastructures partagées et le contexte persistant. Comparé à la réponse précédente d’OpenAI concernant Hugging Face, qui était centrée sur une brèche précise et sur les modifications ultérieures visant à la contenir, le cadre du 16 septembre modifie le processus de signalement au lieu d’établir une nouvelle protection technique.
Il crée un mécanisme reproductible pour signaler les comportements observés pendant l’entraînement, l’évaluation, les tests et le déploiement, mais les six premiers rapports ne prescrivent pas d’architecture commune pour empêcher leur réapparition. Les entreprises peuvent s’appuyer sur les futurs rapports pour vérifier si un fournisseur identifie la mesure de protection concernée, l’impact externe, les mesures d’atténuation et le risque non résolu, tout en contrôlant elles-mêmes leurs propres dispositifs concernant les identifiants, les sorties réseau, les dépôts et la mémoire des agents.
OpenAI précise que les six cas sont des exemples individuels et ne montrent pas à quelle fréquence le désalignement survient parmi ses modèles. Ces résultats sont rapportés par l’entreprise et ne constituent pas un audit indépendant ; leur valeur opérationnelle dépendra donc du niveau de détail technique fourni dans les futurs rapports.
Vous souhaitez découvrir d’autres conseils, astuces et techniques de prompting liés à l’IA ? Les lecteurs d’eWeek bénéficient d’un accès gratuit de 7 jours à The Neuron Academy, notre plateforme d’apprentissage pratique conçue pour aider les professionnels à utiliser l’IA avec davantage d’assurance au travail. Parcourir tous les cours →