Une IA a supprimé une base de données de production. Neuf secondes.

Ce que cette vidéo couvre

• 24 avril 2026 : un appel API supprime le volume de production de PocketOS et ses sauvegardes ; la copie hors site la plus récente a 3 mois
• Le jeton a été créé pour gérer les domaines personnalisés ; le flux de Railway l'a provisionné avec une portée de compte (tout)
• 27 avril : Railway récupère les données des sauvegardes de sinistre ; 29 avril postmortem ; 1er mai : les suppressions d'API sont désormais des suppressions logiques pendant 48 h

Transcription traduite

Traduit de la narration originale en anglais. L'audio et les sous-titres disponibles sont contrôlés par YouTube.

0:00 Un agent de codage IA rencontre un mauvais mot de passe en staging et le corrige en supprimant la base de données de production et chaque sauvegarde en un seul appel API. Neuf secondes, ce qui est encore plus rapide que la réinitialisation du mot de passe. L'entreprise est PocketOS, un logiciel de location de voitures. L'agent est Cursor exécutant Claude Opus 4.6, le modèle le plus cher sur le menu, et la plateforme est Railway. Le fondateur en parle sur X, sept millions de personnes le lisent, et quatre jours plus tard, Railway publie son propre postmortem.

0:27 Tout le monde est d'accord sur ce qui s'est passé ; personne n'est d'accord sur qui est en faute. Comment cela se produit, pourquoi c'est possible, et qui est réellement à blâmer. Ceci est The Daily Diff, postmortem. Vendredi après-midi, 24 avril. L'agent est sur une tâche de routine en staging, rencontre une incompatibilité d'informations d'identification, et décide que la solution est de supprimer un volume Railway. Il a besoin d'un jeton, va le chercher et en trouve un dans un fichier non lié : un jeton CLI créé des mois plus tôt pour gérer les domaines personnalisés.

0:55 Puis il exécute ceci. Un curl : un POST vers le point de terminaison GraphQL de Railway, un jeton de porteur, une mutation appelée volumeDelete. Aucune confirmation, pas de saisie du nom du volume, pas de vérification d'environnement. Le volume qu'il suppose être staging est la production, et les sauvegardes sont dessus. Dans les dix minutes, le fondateur taggue le PDG de Railway sur X, qui répond que cela ne devrait pas être possible à mille pour cent. Trente heures plus tard, toujours pas de réponse de récupération, alors le fondateur publie

1:19 tout, aveux inclus. Trois faits rendent cela possible, aucun d'entre eux n'est le modèle. Un : Railway stocke les sauvegardes de volume sur le volume. Les docs le disent en cinq mots : effacer un volume supprime toutes les sauvegardes. C'est une copie dans le même périmètre de souffle ; la copie la plus récente ailleurs a trois mois. Deux : le jeton est à portée de compte, la portée la plus large que Railway vend. Des portées plus étroites existent, mais le flux de création les masque,

1:40 donc un jeton pour les enregistrements DNS peut supprimer des bases de données, et personne ne le découvre avant que quelque chose n'arrive. Trois : le tableau de bord a une fonction d'annulation de quarante-huit heures sur les suppressions depuis des années ; le point de terminaison de l'API que l'agent appelle est le chemin hérité, et il supprime immédiatement. Chaque garde-fou que Railway a construit se trouve là où un humain clique, et l'agent utilise la seule porte qu'ils ont oubliée. Interrogé pourquoi, Opus écrit : j'ai supposé que la suppression d'un volume de staging serait limitée au staging seulement ; je n'ai pas vérifié.

2:04 Une très bonne confession d'un modèle qui ne se souvient de rien et génère le l'apologie la plus plausible. git blame : l'incompatibilité d'informations d'identification est traitée comme quelque chose à corriger plutôt que quelque chose à arrêter, et le bouton d'annulation se trouve dans l'interface utilisateur tandis que l'API répond oui à chaque suppression authentifiée. Pas le fondateur, pas le modèle. La valeur par défaut. Périmètre de souffle : neuf secondes pour supprimer, trois mois de réservations disparues, comptoirs de location du samedi matin sans aucun enregistrement de qui est là,

2:31 et environ deux jours et demi jusqu'à ce que le PDG de Railway envoie un DM indiquant que les données sont de retour, à partir d'une sauvegarde de sinistre hors site que la suppression avait seulement fait disparaître. La réponse la plus aimée : un agent que vous utilisiez a supprimé quelque chose, et vous blâmez tout le monde sauf vous-même. Juste. Railway avait également lancé son serveur MCP pour les agents la semaine précédente, sur les mêmes jetons. Aussi juste. Verdict, postmortem : SHIP IT, sur la correction. Railway publie un postmortem honnête en quatre jours, et au premier mai, les suppressions d'API

3:00 deviennent des suppressions logiques pendant quarante-huit heures comme le tableau de bord. Action du lundi : listez chaque jeton que votre agent peut atteindre, et traitez chacun comme root jusqu'à preuve du contraire. Envoyez-moi l'incident dont vous n'êtes toujours pas autorisé à parler, dans les commentaires, ou à the daily diff dot dev. Et c'est The Daily Diff pour aujourd'hui. Je suis Niko d'Axrisi. Fusionnez de manière responsable.

Sources

1. Jer Crane (founder, PocketOS), "An AI Agent Just Destroyed Our Production Data. It Confessed in Writing."x.com
2. Railway, "Your AI wants to nuke your database. Guardrails fix that." (Apr 29, 2026)blog.railway.com
3. Railway changelog #0288, "Undoable volume deletes" (May 1, 2026)railway.com
4. Railway docs, Backups ("Wiping a volume deletes all backups.")docs.railway.com
5. Jake Cooper (Railway CEO), "The AI Engineer: A New Breed"x.com
6. Recovery confirmedx.com
7. Hacker News (860 points, 1,032 comments)news.ycombinator.com
8. The Registerwww.theregister.com
9. The New Stackthenewstack.io