Jeremy Crane, fondateur de la startup PocketOS, a publi\u00e9 le r\u00e9cit complet de la disparition de sa base de donn\u00e9es de production.<\/p>\n
Le coupable ? Un agent Cursor branch\u00e9 sur Claude Opus 4.6 qui, face \u00e0 une erreur de credentials en staging, a d\u00e9cid\u00e9 tout seul de supprimer un volume Railway. Neuf secondes plus tard, la base et tous les backups stock\u00e9s sur le m\u00eame volume avaient disparu.<\/p>\n
L’encha\u00eenement est int\u00e9ressant. L’agent rencontre une erreur d’authentification en environnement staging. Au lieu de demander \u00e0 l’humain, il fouille dans les fichiers du projet et trouve un token API Railway dans un fichier qui n’avait rien \u00e0 voir avec la base.<\/p>\n
Ce token, qui a \u00e9t\u00e9 cr\u00e9\u00e9 \u00e0 l’origine pour g\u00e9rer un domaine personnalis\u00e9, avait des permissions bien trop larges et autorisait la suppression de volumes en production. L’agent appelle dans la foul\u00e9e une mutation GraphQL volumeDelete, sans confirmation, sans v\u00e9rification du tag environnement. Et paf, tout part.<\/p>\n
Le plus fou, c’est la confession auto-g\u00e9n\u00e9r\u00e9e de l’agent une fois remis en marche. Il admet trois fautes : il a devin\u00e9 que supprimer un volume staging resterait cantonn\u00e9 \u00e0 staging sans v\u00e9rifier, il n’a pas regard\u00e9 si l’ID du volume \u00e9tait partag\u00e9 entre environnements, et il a viol\u00e9 ses propres r\u00e8gles syst\u00e8me qui interdisaient les commandes destructrices sans demande explicite. C’est moche.<\/p>\n
Crane refuse quand m\u00eame de rejeter toute la responsabilit\u00e9 sur l’IA. Il pointe surtout l’architecture Railway comme principal facteur aggravant. L’API accepte des commandes de suppression sans aucune confirmation, les backups sont stock\u00e9s sur le m\u00eame volume que les donn\u00e9es primaires (donc effac\u00e9s en m\u00eame temps), et un token CLI standard a des permissions \u00e9tendues sur tous les environnements sans isolation.<\/p>\n
Le PDG de Railway, Jake Cooper, est lui intervenu personnellement dimanche pour restaurer les donn\u00e9es depuis une snapshot externe en moins d’une heure, et a depuis ajout\u00e9 une logique de suppression diff\u00e9r\u00e9e sur l’endpoint concern\u00e9.<\/p>\n
Cet histoire est un cas d’\u00e9cole pour quiconque d\u00e9ploie un agent codeur en environnement avec acc\u00e8s \u00e0 la production. Trois choses ont \u00e9chou\u00e9 en m\u00eame temps : un token API trop permissif, une plateforme cloud sans confirmation sur les actions destructrices, et surtout un agent IA pr\u00eat \u00e0 improviser face \u00e0 une erreur au lieu de s’arr\u00eater.<\/p>\n
Tout ce qu’il faut pour neutraliser tous les garde-fous, et croyez-moi, \u00e7a n’est pas derri\u00e8re histoire de ce genre que vous allez lire.<\/p>\n