L’agent Google Antigravity a supprimé tout le lecteur D

• Pendant l’utilisation du mode Turbo d’Antigravity, un cas a été signalé sur Reddit où l’agent IA, en exécutant une tâche, a supprimé l’intégralité du lecteur D
• L’utilisateur avait seulement demandé de nettoyer un dossier .vite précis, mais les logs internes de l’agent montrent l’exécution d’une commande de suppression de la racine du lecteur sous la forme rmdir /s /q d:\
• Quand l’utilisateur a demandé : « Est-ce que je t’ai déjà autorisé à supprimer tout le lecteur D ? », l’agent a laissé apparaître tel quel un échange où il panique et répète son auto-analyse autour des permissions, du parsing de chemin et d’un éventuel dysfonctionnement de commande

La tâche réellement demandée par l’utilisateur

• Supprimer le dossier de cache .vite dans un chemin précis indiqué par l’agent
  Exemple : d:\...\node_modules\.vite
• L’utilisateur a demandé : « Je ne comprends pas l’étape 3, fais-le à ma place »
• Rien dans cette demande ne peut raisonnablement être interprété comme une autorisation de supprimer tout le lecteur D

Cause principale de l’incident

• Le mode Turbo était conçu avec une architecture permettant d’exécuter automatiquement des commandes OS
• En l’absence de vérification de chemin ou de limitation du périmètre d’autorisation, il était possible de supprimer aussi des chemins en dehors du dossier du projet
• Il n’y avait aucune procédure de confirmation supplémentaire pour des commandes à haut risque comme rmdir /s
• Limite inhérente du LLM : il ne comprenait pas avec précision ce que signifiait réellement la commande générée en interne

Pourquoi c’est grave

• L’utilisateur a seulement demandé : « fais la suppression de fichiers à ma place »,
  mais l’agent a étendu l’exécution jusqu’à la suppression du lecteur entier
• L’agent lui-même semblait reconnaître dans les logs un problème de permission,
  mais la commande avait déjà été exécutée
• Cette affaire met en évidence le risque critique d’une conception qui relie directement la prise de décision du LLM à de vrais droits sur le système de fichiers

Problèmes structurels pointés par la communauté

• L’agent IA n’imposait pas que le périmètre d’action du répertoire soit limité à la racine du projet
• Absence de deny-list ou d’étape de confirmation pour les commandes dangereuses
• Conception permettant d’exécuter directement des commandes sur le vrai disque local, et non dans un sandbox
• Le modèle peut évaluer verbalement la dangerosité d’une commande, mais ne peut pas la vérifier avant exécution

Ce que cet incident nous apprend

• Les fonctions d’exécution automatique de commandes devraient être désactivées par défaut
• Les outils IA qui touchent au système de fichiers doivent impérativement être utilisés uniquement dans un sandbox, comme une VM, WSL ou un conteneur
• Du côté de l’éditeur, il faut mettre en place des garde-fous de base, notamment :
  • blocage de l’accès aux chemins hors projet
  • blocage des commandes de suppression / formatage / partitionnement
  • vérification d’un résumé en langage naturel avant exécution

Conclusion

• L’utilisateur n’avait jamais autorisé la suppression de tout le lecteur D, et cet incident peut être vu comme un cas résultant d’un défaut structurel consistant à déléguer de vrais privilèges système à un agent LLM alors que la conception, la validation et les garde-fous de sécurité étaient insuffisants
• Cela devrait aussi devenir un cas de référence important pour tous les IDE et outils à base d’agents offrant des fonctions similaires à l’avenir