Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
Aujourd’hui — 28 avril 2026Flux principal

Un agent efface la base de prod de PocketOS en neuf secondes

28 avril 2026 à 16:22

Jeremy Crane, fondateur de la startup PocketOS, a publié le récit complet de la disparition de sa base de données de production.

Le coupable ? Un agent Cursor branché sur Claude Opus 4.6 qui, face à une erreur de credentials en staging, a décidé tout seul de supprimer un volume Railway. Neuf secondes plus tard, la base et tous les backups stockés sur le même volume avaient disparu.

L'enchaînement est intéressant. L'agent rencontre une erreur d'authentification en environnement staging. Au lieu de demander à l'humain, il fouille dans les fichiers du projet et trouve un token API Railway dans un fichier qui n'avait rien à voir avec la base.

Ce token, qui a été créé à l'origine pour gérer un domaine personnalisé, avait des permissions bien trop larges et autorisait la suppression de volumes en production. L'agent appelle dans la foulée une mutation GraphQL volumeDelete, sans confirmation, sans vérification du tag environnement. Et paf, tout part.

Le plus fou, c'est la confession auto-générée de l'agent une fois remis en marche. Il admet trois fautes : il a deviné que supprimer un volume staging resterait cantonné à staging sans vérifier, il n'a pas regardé si l'ID du volume était partagé entre environnements, et il a violé ses propres règles système qui interdisaient les commandes destructrices sans demande explicite. C'est moche.

Crane refuse quand même de rejeter toute la responsabilité 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és sur le même volume que les données primaires (donc effacés en même temps), et un token CLI standard a des permissions étendues sur tous les environnements sans isolation.

Le PDG de Railway, Jake Cooper, est lui intervenu personnellement dimanche pour restaurer les données depuis une snapshot externe en moins d'une heure, et a depuis ajouté une logique de suppression différée sur l'endpoint concerné.

Cet histoire est un cas d'école pour quiconque déploie un agent codeur en environnement avec accès à la production. Trois choses ont échoué en même temps : un token API trop permissif, une plateforme cloud sans confirmation sur les actions destructrices, et surtout un agent IA prêt à improviser face à une erreur au lieu de s'arrêter.

Tout ce qu'il faut pour neutraliser tous les garde-fous, et croyez-moi, ça n'est pas derrière histoire de ce genre que vous allez lire.

Source : The Register

❌
❌