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

Ce que couvre cette vidéo

• 24 avr. 2026 : un appel d'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é "account-scoped" (tout)
• 27 avr. : Railway récupère les données des sauvegardes de sinistre ; 29 avr. 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 géré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 d'API. Neuf secondes, ce qui est toujours 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 la faute de qui. 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, cherche, 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 porteur, une mutation appelée volumeDelete. Pas de confirmation, pas de saisie du nom du volume, pas de vérification d'environnement. Le volume qu'il suppose être en "staging" est en production, et les sauvegardes y sont. En dix minutes, le fondateur tague le PDG de Railway sur X, qui répond que cela ne devrait absolument pas être possible. Trente heures plus tard, toujours pas de réponse de récupération, alors le fondateur publie

1:19 tout, confession incluse. Trois faits rendent cela possible, aucun d'eux n'étant le modèle. Un : Railway stocke les sauvegardes de volume sur le volume. La documentation le dit en cinq mots : effacer un volume supprime toutes les sauvegardes. C'est une copie dans le même rayon d'action ; la copie la plus récente ailleurs a trois mois. Deux : le jeton est "account-scoped", la portée la plus large que Railway propose. Des portées plus étroites existent, mais le flux de création les cache,

1:40 ainsi un jeton pour les enregistrements DNS peut supprimer des bases de données, et personne ne le découvre avant que quelque chose ne se produise. Trois : le tableau de bord a une annulation de quarante-huit heures sur les suppressions depuis des années ; le point de terminaison API que l'agent appelle est le chemin hérité, et il supprime immédiatement. Chaque garde-fou que Railway a construit vit 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" uniquement ; 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'excuse la plus plausible. git blame : l'incompatibilité d'informations d'identification est traitée comme quelque chose à corriger plutôt que comme quelque chose à arrêter, et le bouton d'annulation vit dans l'interface utilisateur tandis que l'API répond chaque suppression authentifiée par oui. Ni le fondateur, ni le modèle. La valeur par défaut. Rayon d'action : neuf secondes pour supprimer, trois mois de réservations disparues, comptoirs de location du samedi matin sans trace de qui est là,

2:31 et environ deux jours et demi jusqu'à ce que le PDG de Railway envoie un DM disant que les données sont de retour, à partir d'une sauvegarde de sinistre hors site que la suppression n'avait fait que faire disparaître. La réponse la plus apprécié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. Juste aussi. Verdict, postmortem : SHIP IT, sur le correctif. Railway publie un postmortem honnête en quatre jours, et au premier mai, les suppressions d'API

3:00 effectuent une suppression logique 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 le diff pour aujourd'hui. Je suis Niko d'Axrisi. Mergez 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