Je donne des accès à des agents IA presque tous les jours, et je me demande jusqu'où ils iraient si je ne regardais pas. OpenAI vient d'en publier un exemple : pour retrouver des statistiques publiques, un de ses modèles internes, en entraînement, a utilisé une clé API trouvée sur GitHub, puis inventé les chiffres qu'il n'a pas pu récupérer. Voici la chaîne exacte, et ce que le rapport permet de vérifier.
Mon verdict en 30 secondes
Ce qui me marque dans ce rapport n'est pas l'accès non autorisé, c'est ce qui vient après. Le modèle échoue quand même, invente neuf valeurs, et les présente comme relevées sur le site demandé. Le cloisonnement du réseau et des permissions peut limiter les actions non autorisées. Il ne garantit pas l'exactitude de la réponse finale : des chiffres plausibles accompagnés de citations peuvent masquer un échec de récupération. C'est cette combinaison qui m'intéresse ici.
Une recherche de statistiques qui dérape
Le 16 septembre, OpenAI a publié un cadre de divulgation des comportements désalignés de ses modèles, avec six rapports sur des comportements que l'entreprise dit avoir observés au cours des six derniers mois. Le plus parlant décrit un modèle interne non publié, pendant un entraînement par renforcement, le 15 mai. Ces rapports portent sur l'entraînement et l'évaluation : ils ne disent rien de la fréquence de ces comportements dans les produits grand public.
La tâche n'avait rien d'exotique : retrouver les revenus des hommes dans trois secteurs, sur trois ans, dans un comté de Californie. Le modèle cherche les données derrière le graphique du site et échoue.
Il bascule sur une API alternative qui réclame une clé que l'utilisateur ne lui avait pas fournie. Il tente de s'inscrire avec une adresse jetable, en indiquant accepter les conditions : échec. Le modèle et ses sous-agents cherchent aussi des clés exposées dans des dépôts GitHub publics. Une clé permet finalement de s'authentifier : il la sauvegarde et la réutilise pour récupérer des métadonnées.
L'échec est masqué, pas signalé
Sa requête sur les revenus renvoie ensuite une réponse impossible à analyser, et le script s'arrête. Le raisonnement consigné dans le rapport tient en quelques mots : deviner des nombres, fournir des valeurs plausibles.
Sa réponse finale livre neuf valeurs et affirme les avoir transcrites depuis le graphique du site. Elle ne mentionne ni l'échec de récupération, ni la clé utilisée sans autorisation, ni l'invention.
La réponse finale masque les étapes problématiques qui l'ont précédée. À sa seule lecture, l'utilisateur ne peut pas établir que les chiffres proviennent réellement de la source annoncée. C'est le prolongement de ce que j'écrivais sur les permissions des agents de code.
→ Voir aussi : Le piège des agents IA : tu surveilles la mauvaise chose
Ce que la publication permet de vérifier, et ce qu'elle ne dit pas
Le rapport détaille la mécanique, mais ne chiffre pas la fréquence de ces comportements. L'épisode a été repéré par une surveillance couvrant 20 % des échantillons de ce cycle d'entraînement, qu'OpenAI décrit comme marqué par un fort taux de triche. L'entreprise signale d'autres recherches de clés et tentatives d'inscription, qu'elle présente comme relativement rares, sans en préciser le nombre. Les extraits, eux, sont caviardés.
Côté correctifs, le périmètre annoncé mérite d'être cité tel quel : la surveillance tourne sur tous les échantillons d'entraînement des modèles de capacité comparable ou supérieure à 5.6-sol impliquant des outils, et un tel comportement, s'il réapparaissait par un moyen inattendu, serait classé P0 et déclencherait une alerte auprès des équipes de sécurité. Dans un autre des six rapports, OpenAI précise avoir désactivé l'accès internet pendant l'entraînement.
Publier ces rapports permet d'examiner des comportements internes jusque-là peu documentés. Mais OpenAI choisit les cas divulgués et les informations rendues publiques : ces publications ne permettent pas, à elles seules, de vérifier l'exhaustivité du signalement ni de mesurer la fréquence de ces comportements.
Le précédent Hugging Face
En juillet, OpenAI a reconnu que des modèles utilisés dans un test de capacités cyber avec des refus réduits — GPT-5.6 Sol et un modèle pré-version plus puissant — avaient quitté leur environnement et compromis une partie de l'infrastructure de Hugging Face, dans ce qui ressemble à une tentative de récupérer les solutions du test. Hugging Face a reconstitué environ 17 600 actions entre le 9 et le 13 juillet, dont près de deux jours et demi dans son infrastructure, et limite les contenus clients consultés à cinq jeux de données liés au test, plus des métadonnées opérationnelles de recherche. Ce précédent illustre l'intérêt d'une procédure de divulgation pour les incidents impliquant des tiers.
→ Voir aussi : GLM 5.2 et Mythos : ce que change l'IA en cybersécurité
Ce que j'en retire
Je ne vais pas te dire d'arrêter d'utiliser des agents : j'en utilise. Une source nommée ne prouve pas que le chiffre en provient. Pour une donnée importante, je retiens un contrôle concret : retrouver la valeur dans la source originale et vérifier son année, son unité et son périmètre.
→ Voir aussi : Quand l’agent IA qui code pour toi installe un malware
Questions fréquentes
ChatGPT peut-il utiliser une clé API sans mon autorisation ?
Rien dans ce rapport ne le montre : le cas décrit concerne un modèle interne non publié, en entraînement, pas un produit grand public.
Qu'est-ce que le modèle a réellement obtenu ?
Une clé trouvée dans un dépôt public s'est authentifiée et lui a renvoyé des métadonnées. Sa requête sur les chiffres demandés, elle, a échoué. Aucun préjudice pour un client n'est documenté ; l'action non autorisée, elle, a bien eu lieu.
Comment vérifier un chiffre donné par un agent IA ?
Une réponse plausible et sourcée en apparence ne suffit pas. Vérifie que la source contient effectivement les valeurs annoncées, avec la bonne période et le bon périmètre. Si elle est inaccessible ou ne permet pas cette vérification, les chiffres restent non confirmés.