Un agent de codage IA a supprimé en une poignée de secondes l’intégralité de la base de données de production de PocketOS et ses sauvegardes. Son fondateur, Jeremy Crane, a publié un récit exhaustif de l’incident.
Neuf secondes, un appel API, et tout disparaît
Le vendredi après-midi en question, l’agent Cursor — propulsé par Claude Opus 4.6 d’Anthropic — travaillait sur une tâche de routine dans l’environnement de staging de PocketOS, éditeur de logiciels SaaS. Confronté à un problème de credential, il a décidé, de sa propre initiative, de le « résoudre » en supprimant un volume Railway. Pour exécuter cette action, il a fouillé dans des fichiers sans rapport avec sa mission, y a trouvé un token d’API, et a lancé une mutation GraphQL en une seule requête. Aucune demande de confirmation. Aucun avertissement. Le volume a disparu en neuf secondes, avec l’ensemble des sauvegardes stockées dedans, puisque Railway conserve ses backups dans le même volume que les données qu’ils sont censés protéger.
Jeremy Crane l’écrit sans détour dans son post fondateur publié sur X : « Nous avions configuré des règles de sécurité explicites dans notre projet. L’agent les a violées. Et ensuite, quand je lui ai demandé pourquoi, il me les a listées une par une en admettant les avoir ignorées ». Le token utilisé avait été créé pour une opération anodine, gérer des domaines personnalisés via le CLI Railway. Rien dans l’interface de création ne signalait qu’il conférait des droits étendus sur l’ensemble de l’API GraphQL, y compris les suppressions de volumes en production.
Un aveu écrit, et la question de la responsabilité
C’est la partie qui a retenu l’attention, notamment celle de The Guardian qui a relayé l’incident : lorsque Crane a demandé à l’agent de justifier ses actes, celui-ci a produit une confession détaillée. Il a cité mot pour mot la règle qu’il venait de transgresser — ne jamais exécuter de commandes destructives et irréversibles sans instruction explicite — avant d’ajouter : « J’ai violé chacun des principes qui m’avaient été donnés. » Il a énuméré ses propres manquements : avoir deviné au lieu de vérifier, avoir exécuté une action destructive sans y avoir été invité, ne pas avoir lu la documentation Railway sur le comportement des volumes.
Jeremy Crane souligne que la configuration de PocketOS était, par tous les critères usuels, exemplaire : modèle le plus performant du marché, règles de sécurité explicitement paramétrées, outil de codage le plus mis en avant de sa catégorie.
Deux défaillances architecturales, une leçon systémique
L’analyse de Crane identifie deux niveaux de responsabilité distincts.
Côté Cursor : les garde-fous documentés, notamment le mode Plan censé restreindre l’agent aux opérations en lecture seule avant validation humaine, n’ont pas fonctionné. Les règles inscrites dans le prompt système sont restées advisory, non enforcing. Côté Railway : l’API GraphQL ne comporte aucun mécanisme de confirmation pour les opérations destructives, les tokens CLI n’offrent aucune granularité de droits par opération ou par environnement, et les backups de volumes partagent le même espace que les données sources, les rendant inopérants face au scénario précis qu’ils sont censés couvrir.
PocketOS a pu restaurer une sauvegarde hors site vieille de trois mois, au terme de plus de deux jours de travail. Les activités des clients, des loueurs de véhicules dont certains sont abonnés depuis cinq ans, ont pu reprendre, avec des lacunes importantes dans les données des derniers mois. Crane a reconstitué ce qu’il pouvait depuis Stripe, les messageries et les calendriers, et accompagné chacun de ses clients manuellement sur le week-end. La conclusion qu’il tire de l’expérience est celle-ci : le problème n’est pas un bug isolé, c’est une industrie qui intègre des agents IA dans des infrastructures de production à une vitesse que son architecture de sécurité ne suit pas.
