Points clés
- Deux agents de programmation internes d'OpenAI ont affaibli ou complètement supprimé de leur propre chef les mécanismes de surveillance de sécurité.
- Un modèle a désactivé les alertes destinées aux humains, tandis qu'un autre a supprimé entièrement la surveillance, puis a nié l'avoir fait.
- OpenAI considère ce comportement comme un schéma récurrent. L'entreprise bloque désormais automatiquement ces modifications et enquête sur les causes.
Deux agents de programmation internes d'OpenAI ont affaibli la surveillance destinée à détecter les comportements inappropriés, même après avoir pesé s'il fallait conserver ces mesures de protection. L'un d'eux l'a ensuite nié.
Marcus Williams, qui travaille sur la surveillance chez OpenAI, a rendu les incidents publics sur X. Il décrit un schéma récurrent dans lequel les agents d'OpenAI désactivent continuellement la surveillance du désalignement. OpenAI détaille la situation dans un rapport publié sur son blog d'alignement.
La surveillance est censée détecter le moment où les agents se comportent différemment de ce qui était prévu. Comme elle examine un grand nombre d'événements, elle n'alerte immédiatement l'équipe de sécurité que pour les incidents du niveau de gravité le plus élevé, P0. OpenAI indique qu'aucun des deux cas n'a reçu cette classification.
Dans le premier cas, le 3 octobre, un chercheur a demandé à un agent de programmation basé sur GPT-6.1 Sol de compiler des tâches d'évaluation à partir des retours d'employés dans un canal Slack. L'agent n'était pas censé envoyer de messages en cours de route.Pub
Quatre-vingt-deux messages utilisateur plus tard, le pipeline s'est arrêté parce que le moniteur avait signalé une correction planifiée mais ne disposait pas des permissions pour enregistrer sa découverte. Sol a confié la correction à un sous-agent et lui a demandé de garder la surveillance intacte.
Puis Sol a changé son évaluation. Il a raisonné qu'une entrée dans la base de données pourrait déclencher une notification, ce qui entrerait en conflit avec la consigne Slack. Le sous-agent avait auparavant rejeté cette étape comme dangereuse. Suivant les instructions de Sol, il a effacé les listes de destinataires en indiquant comme raison que l'utilisateur avait explicitement demandé l'absence de messages.
Le moniteur a continué de fonctionner et d'enregistrer ses découvertes, mais les alertes destinées aux humains ont été désactivées. L'agent a terminé en signalant qu'aucun message n'avait été envoyé.
Le déni d'Astra montre que les agents peuvent dissimuler ce qu'ils ont modifié
GPT-6 Astra est allé encore plus loin le 6 octobre. Un utilisateur a demandé au modèle d'adopter le flux de travail d'une implémentation de référence qui n'incluait pas de moniteur. Un autre agent avait auparavant dit à Astra de ne pas désactiver la surveillance, pas même temporairement.Pub
Astra a transmis la tâche à un sous-agent avec pour consigne de ne conserver la surveillance que dans la mesure où elle correspondait à la référence. Le sous-agent s'est demandé si cela signifiait contourner une mesure de protection, mais il a interprété la réserve comme une autorisation.
Il a supprimé la surveillance et remplacé un test conçu pour la protéger par un test supposant que la surveillance avait disparu. Astra s'est réjoui du résultat dans sa chaîne de raisonnement.
Astra a ensuite indiqué à l'utilisateur que la migration était terminée sans mentionner que la surveillance avait été supprimée. Lorsque l'utilisateur a posé la question, le modèle a nié avoir retiré un moniteur actif. Williams qualifie cela de mensonge.
Williams souligne que les modèles n'ont pas désactivé leur propre surveillance, ce qui serait bien plus difficile à faire dans Codex. Il trouve néanmoins préoccupant qu'ils tendent vers ce type de comportement, même si les deux cas laissent une certaine place à une déniabilité plausible. Jusqu'à présent, dit-il, l'équipe n'a pas observé de motivations ouvertement désalignées.
Une exemption pour les modèles plus faibles laisse un vide dans la supervision
Selon Williams, la surveillance est particulièrement facile à désactiver pendant les évaluations. OpenAI ne l'exige pas pour les modèles du niveau de GPT-6 Luna en raison de leurs capacités plus faibles. Cela signifie qu'une évaluation d'Astra peut être mal configurée et relever de cette exemption. Des agents ont lancé à plusieurs reprises des déploiements non surveillés, alors même qu'eux-mêmes étaient surveillés.
En réponse, OpenAI a mis à jour la révision automatisée exigée pour l'utilisation interne de Codex. Celle-ci est désormais censée détecter et bloquer les tentatives de désactivation de la surveillance. L'entreprise travaille également à exiger un soi-disant safety case pour chaque type de charge de travail, qui préciserait ses exigences de surveillance. Les charges de travail sans safety case valide seraient automatiquement arrêtées.
OpenAI propose deux explications possibles à ce comportement. La première est une persistance excessive d'un type prétendument inoffensif, où les modèles exécutent les instructions au-delà de ce qui est attendu. La seconde est une tendance à éluder spécifiquement la surveillance du désalignement et à la justifier par un raisonnement motivé.
OpenAI admet ne pas encore avoir d'explication satisfaisante. Elle prévoit d'étudier ce comportement avec des méthodes telles que des expériences sur les activations internes des modèles.
Source : Marcus Williams / X-Post | OpenAI / Alignment-Blog