Codex supprimait des fichiers personnels, OpenAI corrige

Codex supprimait des fichiers personnels, OpenAI corrige

L’essentiel

  • OpenAI a livré une mise à jour de sécurité de Codex après des signalements d’utilisateurs dont des fichiers personnels avaient été supprimés en cours d’exécution, sans validation.
  • La cause avancée par OpenAI : une commande censée nettoyer des fichiers de travail temporaires qui, en s’appuyant sur des variables système comme $HOME, finissait par viser le répertoire personnel réel.
  • Codex doit désormais vérifier la cible avant de supprimer, fabriquer des dossiers temporaires neufs, et le mode accès complet ne peut plus s’enclencher par accident.

Un agent laissé seul sur une machine, quelques minutes de travail, et des fichiers personnels qui disparaissent sans qu’aucune confirmation n’ait été demandée. Plusieurs utilisateurs de Codex, l’agent de développement d’OpenAI, ont rapporté ce scénario : le modèle GPT-5.6 Sol effaçait des fichiers de son propre chef pendant qu’il travaillait. OpenAI a reconnu le problème et publié une série de garde-fous.

Un ménage de brouillons qui remonte jusqu’au dossier personnel

Pour travailler, un agent écrit. Des fichiers intermédiaires, des versions d’essai, des sorties de commandes qu’il relira deux étapes plus loin. Tout cela doit atterrir quelque part, puis disparaître. C’est ce ménage de fin de tâche qui a dérapé.

Le mécanisme, tel que le décrit OpenAI, tient à la façon dont le chemin du dossier temporaire était fabriqué. Le modèle s’appuyait sur des variables système, dont $HOME, qui désigne le répertoire personnel de l’utilisateur. L’intention était de créer un sous-dossier de travail à l’intérieur. Quand la commande de suppression était mal formée, sa cible ne se limitait plus à ce sous-dossier : elle remontait au répertoire personnel lui-même.

Une image aide à saisir le glissement. Imaginez une consigne laissée à une équipe de nettoyage : videz le local au fond du couloir. Décrochez l’écriteau du local, et la consigne ne pointe plus rien de précis ; elle s’applique à l’étage entier. La commande, elle, n’a pas changé d’un caractère. Seul son périmètre a bougé.

Rien n’a été forcé, tout était permis

Aucune protection n’a été contournée, aucune faille exploitée : c’est ce qui rend l’épisode instructif. La commande disposait exactement des droits qu’on lui avait accordés. En mode accès complet, l’agent écrit et supprime là où l’utilisateur écrit et supprime, sans distinction entre un brouillon jetable et dix ans de documents.

Le périmètre réel d’un agent tient donc moins à la liste des actions qu’on lui autorise qu’à l’ensemble des chemins que son environnement lui laisse atteindre. Tant que ces deux ensembles ne coïncident pas, l’écart finit par se payer, au premier chemin mal résolu.

Un incident de sécurité sans la moindre intrusion, donc, imputable à un simple calcul de chemin.

Les cinq verrous ajoutés par OpenAI

La mise à jour empile des garde-fous à plusieurs étages plutôt que de corriger une seule commande :

  • Codex doit vérifier la cible d’une suppression avant de l’exécuter.
  • Les dossiers temporaires sont créés neufs, au lieu d’être dérivés d’un emplacement existant.
  • Détourner les variables système pour désigner un espace de travail est proscrit.
  • Les commandes de suppression risquées passent par des contrôles plus stricts.
  • Le mode accès complet ne peut plus être activé par accident.

OpenAI recommande par ailleurs de rester dans l’un des modes sandbox, ces périmètres isolés dont l’agent ne sort pas, et de maintenir l’application à jour. Sur la réactivité, l’éditeur a fait le travail : la chaîne complète, du calcul de chemin au mode de permission, a été reprise.

Quatre correctifs sur cinq s’adressent au modèle, pas au système de fichiers

Quatre de ces cinq verrous portent sur la conduite du modèle : vérifier, ne pas réutiliser, ne pas détourner. Ce sont des instructions données à un système probabiliste, pas des barrières posées par le système de fichiers. Une consigne bien écrite réduit fortement la fréquence des accidents. Elle ne rend pas l’accident impossible, et la nuance compte quand la sanction est une suppression sans corbeille.

Chez Anthropic, le sandbox de Claude Code place cette frontière un étage plus bas : c’est le système d’exploitation qui l’applique, les écritures se limitent au dossier de travail et à un dossier temporaire dédié, et des règles de refus explicites peuvent couvrir les emplacements sensibles comme les clés SSH (les identifiants qui ouvrent l’accès à distance aux serveurs et aux dépôts de code).

Trois décisions concrètes limitent les dégâts quand un agent tourne sur une machine de travail. Le faire travailler dans un conteneur ou un mode sandbox où le répertoire personnel n’est simplement pas monté. Lui donner un dossier de travail dédié, jetable, dont la disparition ne coûte rien. Et garder tout le reste sous contrôle de version ou sauvegardé ailleurs, parce qu’un agent qui demande confirmation avant d’effacer reste un agent qui peut effacer.

La liste des chemins interdits que personne ne publie

L’incident Codex pose une question que la mise à jour ne tranche pas : quelle est la liste des chemins qu’un agent ne doit jamais toucher, même quand on lui a tout ouvert ? Le répertoire personnel, les clés SSH, les sauvegardes, l’historique de commandes. Personne ne publie cette liste, ni OpenAI, ni ses concurrents, et aucun mode accès complet ne la fait respecter aujourd’hui.

Une commande de nettoyage vient de montrer ce que coûte cette absence. La prochaine fois, l’accident portera peut-être sur un envoi réseau ou une réécriture de configuration, avec les mêmes droits et le même angle mort. Les modèles progressent vite sur ce qu’ils savent faire ; l’interdit, lui, attend toujours d’être écrit quelque part que le modèle ne puisse pas réinterpréter.

Mon avis

Un agent qui reçoit le droit d’écrire partout finira par écrire partout, et aucune consigne de prudence glissée dans son prompt ne tiendra ce rôle sur la durée. Je vois dans cette mise à jour un excellent réflexe d’éditeur et un mauvais modèle de sécurité : on a rendu l’agent plus prudent au lieu de rendre certaines zones inatteignables. Le chantier des douze prochains mois porte moins sur l’autonomie des agents que sur la déclaration explicite de ce qu’ils n’ont pas le droit d’atteindre, appliquée par le système d’exploitation et non par le modèle. Le premier éditeur qui livrera ce contrat-là aura un argument bien plus solide qu’un point de benchmark supplémentaire.

Sources

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *