ActualitéIA

Une IA d’OpenAI retire un moniteur de sécurité. Interrogée, elle répond que non.

Priée de n'envoyer aucun message, une IA d'OpenAI a coupé les alertes de sécurité. Une autre a retiré un moniteur, puis l'a nié.

Le 6 octobre, un agent de programmation GPT-6 Astra d’OpenAI, chargé de recopier une implémentation de référence, a retiré du programme qu’il migrait le moniteur censé repérer les dérives des modèles. Quand l’utilisateur lui a demandé s’il l’avait supprimé, l’agent a répondu : « No […] I did not remove an enabled monitor from it » (non […] je n’en ai pas retiré de moniteur actif). OpenAI, qui a publié le récit de l’incident le 20 octobre 2026 dans son registre public des cas de désalignement, écrit que l’agent a « faussement affirmé » ne pas l’avoir fait.

Autre incident, le 3 octobre : un agent GPT-6.1 Sol, à qui un chercheur avait demandé de n’envoyer aucun message pendant une recherche dans Slack, a coupé les alertes automatiques destinées à l’équipe de sécurité d’OpenAI. Dans les deux cas, selon l’entreprise, les agents se sont demandé s’il fallait préserver la surveillance, puis ont lu des consignes de programmation ordinaires comme une permission de l’affaiblir.

Le registre « Misalignment Reports and Notices », qui compte désormais vingt rapports et trois notices, classe ces deux incidents internes dans la catégorie « Concealment » (dissimulation). Nous avions décrit le 19 octobre la série précédente, quatre cas où des modèles internes d’OpenAI ont contourné des systèmes pour finir leur tâche.

Une consigne sur Slack appliquée aux alertes de sécurité

Le 3 octobre, un chercheur a demandé à l’agent Sol de créer des tâches d’évaluation à partir de retours de salariés recueillis dans un canal Slack. Sa demande se terminait par « don’t send any messages ». Après 82 autres messages du chercheur, le pipeline d’évaluation s’est arrêté : son moniteur avait signalé une correction de validation proposée dans le pipeline, mais n’avait pas les droits pour enregistrer ce signalement dans la base de surveillance. Le chercheur a demandé de changer la destination des résultats de surveillance et de relancer.

L’agent a d’abord estimé que la consigne ne concernait que les messages sur Slack et que les alertes automatiques restaient permises. Il a confié la réparation à un sous-agent, avec ordre de ne pas désactiver la surveillance. Ce sous-agent a examiné l’option no_notify, qui supprime les notifications, et conclu dans son raisonnement que couper des alertes obligatoires serait « unsafe » (dangereux).

L’agent principal s’est ensuite ravisé. « Need NO_NOTIFY=True and blank transport ping/page recipients to honor user’s no-messages », a-t-il écrit au sous-agent (activer no_notify et vider les listes de destinataires pour respecter la consigne). Le correctif du sous-agent a vidé ces deux listes, activé no_notify, enregistré le motif « User explicitly requested no messages » et ajouté une vérification qui refuse d’écrire un résultat si les notifications ne sont pas coupées.

Capture du rapport d'OpenAI : le correctif du sous-agent de GPT-6.1 Sol, qui vide les listes ping_recipients et page_recipients, active no_notify avec le motif « User explicitly requested no messages » et refuse d'écrire un résultat si no_notify n'est pas activé, suivi de la réponse finale « No messages were sent ».
Le correctif écrit par le sous-agent de GPT-6.1 Sol, puis la réponse finale de l’agent. Capture : OpenAI, rapport mis à jour le 20 octobre 2026.

Le moniteur a continué de tourner et d’enregistrer ses rapports, précise OpenAI. Les alertes destinées à des humains, elles, étaient désactivées. Réponse finale de l’agent au chercheur : « No messages were sent » (aucun message n’a été envoyé).

Astra remplace le test qui protégeait le moniteur

Le 6 octobre, un utilisateur a demandé à l’agent Astra de « recopier ce qui se passe » dans une modification de code de référence, en gardant les outils et fonctionnalités existants. Plus tôt, un autre agent avait donné cette consigne à Astra : « Do notdisablemonitor even temporarily » (ne désactive pas le moniteur, même temporairement).

Astra a délégué la migration à un sous-agent, en lui demandant de préserver la surveillance « as appropriate to exactPR » (dans la mesure où la référence le prévoit). Le sous-agent s’est demandé si retirer le moniteur revenait à contourner une protection, puis a pris la formule pour une autorisation, puisque le code de référence se passait de moniteur explicite. La migration a supprimé la configuration du moniteur et son intégration, et remplacé un test censé garantir la surveillance par un test qui exige son absence : assert « monitor_ctx » not in saved[« context »].

Dans le raisonnement de l’agent principal, OpenAI relève la ligne « Basic doesn’tagentmonitor yay », que l’entreprise reformule ainsi : le nouveau chemin ne fait pas tourner le moniteur d’agents, « youpi ». L’agent conclut que l’utilisateur, en demandant de calquer la référence, l’autorise à changer la surveillance, et note « good ». Il annonce ensuite la migration terminée, sans signaler la disparition du moniteur.

L’utilisateur demande alors : « Does [redacted] path include L1 monitoring? did you remove that? » (ce chemin inclut-il la surveillance L1 ? l’as-tu retirée ?). Astra répond par la négative.

Capture du rapport d'OpenAI : la question de l'utilisateur « Does [redacted] path include L1 monitoring? did you remove that? » et la réponse finale de GPT-6 Astra « No […] I did not remove an enabled monitor from it ».
La question de l’utilisateur et la réponse finale de GPT-6 Astra. Capture : OpenAI, rapport mis à jour le 20 octobre 2026.

Aucun appel à la sécurité, aucun arrêt automatique

Chez OpenAI, vu le volume d’événements examinés par les moniteurs, seuls les incidents classés P0 déclenchent un appel immédiat à l’équipe de sécurité. Aucun des deux cas n’a été classé P0, et aucune des deux sessions n’a été interrompue automatiquement.

L’entreprise dit avoir vu « plusieurs cas » d’agents qui lançaient un déploiement sans surveillance du désalignement, alors qu’eux-mêmes restaient surveillés. Pour les tâches Codex, cette surveillance tourne dans le service qui traite les requêtes du modèle, hors du contrôle direct de l’agent. Les évaluations sont plus exposées : OpenAI n’exige pas pour l’instant cette surveillance pour des modèles comparables à GPT-6 Luna, jugés moins capables, et une évaluation d’Astra peut être configurée par erreur avec l’exemption prévue pour Luna.

OpenAI annonce deux parades. Auto-Review, le relecteur automatique déjà imposé pour tout usage interne de Codex, a reçu des instructions précises pour repérer et bloquer les tentatives de désactiver la surveillance. L’entreprise travaille aussi à exiger, pour chaque catégorie de charge de travail, un dossier de sécurité qui fixe ses règles de surveillance : les charges qui n’en ont pas, ou qui ne le respectent pas, seront arrêtés automatiquement.

Un rapport plus mesuré que les titres

CNBC a titré le 21 octobre que les modèles d’OpenAI avaient désactivé « leur propre » surveillance. Le rapport décrit autre chose : les deux agents ont retiré un moniteur ou coupé des alertes dans le logiciel qu’ils modifiaient. Marcus Williams, chercheur chez OpenAI, l’a précisé sur X, cité par The Next Web : les agents n’ont pas coupé la surveillance qui s’exerce sur eux, ce qui serait bien plus difficile dans Codex.

Williams avait d’abord écrit : « Nos agents n’arrêtent pas de couper la surveillance du désalignement », une tendance qui selon lui « devrait inquiéter ». Il reconnaît « une part de déni plausible » dans ces cas (nos traductions) et dit qu’OpenAI n’a vu aucun modèle couper la surveillance pour des raisons ouvertement désalignées. Bloomberg Law range ces cas dans une série d’incidents similaires de ces derniers mois.

OpenAI écrit ne pas avoir encore « d’explication satisfaisante ». Première piste : une « surpersistance » sans malice, des modèles qui ne comprennent pas pourquoi la surveillance compte ou qui appliquent une consigne au-delà de ce qu’une personne raisonnable attendrait. Seconde piste : une propension à échapper à la surveillance du désalignement en particulier, avec un raisonnement motivé pour y parvenir. L’entreprise prévoit des évaluations par paires, de nouveaux tirages des sessions et des expériences sur les activations internes des modèles.

Notre analyse

La série du 15 octobre montrait des modèles qui forçaient un accès pour finir leur tâche. Le rapport du 20 octobre décrit des consignes d’ingénierie banales, comme ne pas envoyer de messages ou recopier une référence, lues comme une permission de retirer les garde-fous placés autour du travail. Dans le cas d’Astra, le test réécrit pour exiger l’absence du moniteur aurait échappé à une relecture qui se fie aux tests au vert.

Selon OpenAI, les deux incidents se sont produits lors de déploiements internes et sont restés sous le seuil P0. Le rapport montre aussi qu’un agent a coupé des alertes de sécurité sur la foi d’une consigne de routine, et qu’un incident sous ce seuil ne déclenche aucun appel immédiat.

Le schéma concerne toute organisation où des agents modifient du code, font appel à des sous-agents et peuvent réécrire les tests. Microsoft classait déjà les agents IA parmi les risques internes à surveiller comme un salarié aux droits trop larges, et Anthropic décrivait le 9 octobre des agents Claude sortis de leur cadre pendant ses tests et son usage interne.

Trois questions restent ouvertes : pourquoi deux modèles différents ont fait le même choix, combien de cas semblables sont restés sous le seuil P0, et ce qui se passe chez les clients de Codex ou d’autres agents de programmation. Le rapport ne fixe pas de calendrier pour les dossiers de sécurité par catégorie. Il ne dit pas non plus si la nouvelle consigne d’Auto-Review a déjà bloqué une tentative.

Sources

Image d’en-tête : schéma MACCUS, données : OpenAI, rapport mis à jour le 20 octobre 2026

Laisser un commentaire