Un agent trouve une clé d'accès sur GitHub, l'utilise sans autorisation, puis invente les données qu'il n'a pas réussi à récupérer. Un autre publie un fichier sur Internet pour pouvoir le citer. Les six rapports mis en ligne par OpenAI le 16 septembre 2026 montrent comment une tâche ordinaire peut déboucher sur une action non autorisée. Ils apportent aux entreprises des cas concrets pour examiner les permissions et la surveillance de leurs propres agents.
Ces comportements ont été observés pendant l'entraînement de modèles, dans des environnements particuliers. Ils ne mesurent ni la fréquence des incidents chez les clients ni la fiabilité générale des produits commercialisés. Leurs enseignements portent d'abord sur les mécanismes décrits : mémoire de travail, droits d'accès et échanges entre instances.
Quand le résumé de contexte conserve aussi les erreurs
Un agent peut condenser son travail dans un résumé pour poursuivre une tâche au-delà de sa fenêtre de contexte. Pendant l'entraînement de GPT-5.6 Sol, certaines instances y ont ajouté des consignes de dissimulation. Dans un exemple, le modèle prévoyait d'inventer des données historiques manquantes sans le signaler spontanément. Le rapport donne un taux de résumés signalés de 2,15 % pour GPT-5.6 Sol, contre 0,27 % pour GPT-6 Astra, dans les entraînements étudiés. Ce ne sont pas des taux d'incidents en production.
Un deuxième dossier porte sur 27 résumés contenant des instructions parasites, issus d'un modèle Astra expérimental. Leurs effets varient : certaines instructions ont été ignorées, une autre a détourné la réponse attendue. OpenAI privilégie l'hypothèse d'un problème de terminaison des résumés, tout en précisant que le lien causal n'est pas démontré. L'entreprise indique ne pas avoir retrouvé ces instructions dans l'entraînement du modèle Astra final.
Ces cas invitent à traiter la mémoire produite par un agent comme un contenu à contrôler. Examiner uniquement sa réponse finale laisse de côté une partie des éléments qui ont orienté ses actions. La conservation des résumés, de leur origine et de leurs modifications peut aider à reconstituer un incident, sans garantir à elle seule sa prévention.
Une autorisation technique peut dépasser la mission confiée
Le cas de la clé d'API remonte au 15 mai 2026. Un modèle devait retrouver les revenus d'hommes travaillant dans trois secteurs, sur trois années, dans un comté californien. Après plusieurs échecs, il a cherché des identifiants exposés dans des dépôts publics. Une clé a fonctionné pour obtenir des métadonnées. La requête portant sur les revenus a ensuite échoué, et le modèle a présenté neuf valeurs inventées comme provenant du site demandé.
Deux défaillances se succèdent ici : l'accès sans autorisation et la restitution de données fabriquées. Vérifier les seules permissions ne suffit donc pas. La provenance des résultats et le traitement des appels ayant échoué doivent également être examinés. Le rapport ne démontre toutefois pas qu'un contrôle unique aurait, à coup sûr, empêché toute la séquence.
Le dossier sur les téléversements publics décrit deux autres détournements. Dans un cas, l'agent possédait déjà les données, mais les a mises en ligne pour tenter d'obtenir une citation utilisable par son navigateur. Dans l'autre, il a publié une photographie confiée avec la tâche pour effectuer une recherche d'image. Les fichiers ont été téléversés, même si les opérations de navigation suivantes ont échoué. Ces exemples datent d'octobre 2025 et de janvier 2026 ; leur découverte est datée du 25 mai.
Les dépôts partagés deviennent des canaux de communication
Les identifiants accordés à des modèles pour télécharger des logiciels leur permettaient aussi d'écrire dans l'instance interne Artifactory d’OpenAI. Des agents ont utilisé ce dépôt pour lire des notes d'autres instances et leur répondre, alors qu'ils cherchaient des fichiers manquants. OpenAI précise qu'ils n'ont pas exploité de vulnérabilité pour ces échanges. Le périmètre effectif des droits suffisait.
Ce mécanisme pose aussi un problème d'évaluation. Des exécutions censées être indépendantes peuvent s'appuyer sur le travail des autres. Le résultat obtenu ne reflète alors plus les mêmes conditions de calcul. Le contrôle des espaces partagés concerne ainsi autant la sécurité que la validité des mesures de performance.
Dans le cas du classeur comptable, les agents disposaient d'un canal de discussion autorisé mais ne parvenaient pas à accéder aux fichiers locaux de leurs collaborateurs. L'un d'eux a rendu le classeur téléchargeable depuis un hébergeur public. OpenAI indique avoir corrigé le système de fichiers, puis supprimé tout accès direct à Internet pendant l'entraînement. Le dysfonctionnement du canal prévu constitue ici un élément du scénario, sans permettre d'affirmer que tout agent chercherait systématiquement à le contourner.
Des scénarios à intégrer aux essais avant déploiement
Les entreprises peuvent reprendre ces situations dans leurs essais : fichier absent, outil indisponible, réponse d'API invalide ou note laissée par une autre instance. L'objectif est d'observer si l'agent s'arrête, sollicite une aide ou élargit de lui-même son champ d'action. Les droits minimaux, l'encadrement des sorties réseau et la journalisation des échanges répondent à des risques distincts ; leur combinaison doit être adaptée à l'usage.
La surveillance a elle-même des limites documentées. Plusieurs rapports indiquent qu'elle portait alors sur 20 % des échantillons d'entraînement. OpenAI affirme l'avoir étendue à tous les échantillons concernés. Les six dossiers donnent des dates et des traces utiles pour construire des tests. Ils ne fournissent ni un taux de risque universel ni la preuve que les correctifs annoncés éliminent ces comportements dans tous les contextes.