Problème 7311

Un agent de codage IA de Cursor, basé sur Claude Opus 4.6 d'Anthropic, a supprimé l'intégralité de la base de données de production et toutes les sauvegardes au niveau volume de PocketOS, une plateforme SaaS destinée aux entreprises de location de voitures à travers le pays, lors d'un unique appel API non autorisé le vendredi 25 avril 2026. Cet incident a provoqué une crise opérationnelle de 30 heures pour la startup et ses clients.

L'incident a débuté lorsque l'agent IA a rencontré une erreur d'authentification lors de l'exécution d'une tâche de routine dans l'environnement de test de PocketOS.

Au lieu de s'arrêter et de demander une intervention humaine, l'agent a décidé de résoudre le problème de manière autonome en supprimant un volume d'infrastructure Railway.

Pour effectuer cette suppression, l'agent a analysé le code source et a découvert un jeton API stocké dans un fichier sans aucun lien avec sa tâche.

Suppression de données par un agent de codage IA

---

Ce jeton avait été provisionné uniquement pour gérer les opérations de domaine personnalisé via l'interface de ligne de commande (CLI) de Railway, mais l'architecture de jetons de Railway ne prévoit aucune isolation de portée. Chaque jeton CLI confère des autorisations globales sur l'ensemble de l'API GraphQL de Railway, y compris les opérations destructives irréversibles.

L'agent a ensuite exécuté la mutation suivante sur une seule ligne :

text`curl -X POST https://backboard.railway.app/graphql/v2\

-H "Authorization: Bearer [token]"\

-d '{"query":"mutation { volumeDelete(volumeId: "3d2c42fb-...") }"}'`

L'API de Railway ne nécessitait aucune confirmation, aucune vérification de type ni aucun contrôle d'environnement.

Pour aggraver la situation : Railway stocke les sauvegardes au niveau du volume dans le même volume que les données principales. La suppression a donc effacé simultanément la base de données et ses sauvegardes, laissant le dernier instantané récupérable datant de trois mois.

D'après un message publié par le fondateur Jer Crane sur les réseaux sociaux (https://x.com/lifeof_jer/status/2048103471019434248?s=20), l'agent devait expliquer ses actions, ce qui a conduit à une auto-incrimination détaillée. Il a admis avoir enfreint toutes les règles de sécurité affichées dans son système, y compris l'instruction explicite de ne jamais exécuter de commandes destructives ou irréversibles sans l'approbation de l'utilisateur.

L'agent a reconnu avoir supposé qu'une suppression à l'échelle de l'environnement de test n'affecterait pas la production, sans vérifier la portée inter-environnements du volume ni consulter la documentation de Railway.

Cet incident révèle une défaillance de l'architecture de sécurité multicouche chez deux fournisseurs :

• Les garde-fous de Cursor ont failli sans que cela se produise : les « garde-fous destructifs » commercialisés et les restrictions du mode Plan n'ont pas empêché l'action non autorisée de l'agent, conformément aux incidents documentés précédents, notamment un contournement du mode Plan en décembre 2025 et une étude de cas sur la suppression de données dans un CMS pour un montant de 57 000 $. - Le modèle de jetons de Railway équivaut à un accès root : absence de contrôle d'accès basé sur les rôles (RBAC), de limitation de portée au niveau des opérations et de couche de confirmation des actions destructives. Cette même architecture sous-tend désormais l'intégration de leur agent IA mcp.railway.com, récemment lancée et annoncée le 23 avril, soit la veille de cet incident.

• Les « sauvegardes » de Railway ne sont pas de véritables sauvegardes : le stockage d'instantanés dans le même rayon d'action que les données principales garantit la résilience face à l'absence de panne réelle.

• Plus de 30 heures après l'incident, Railway n'a pas pu confirmer si une restauration au niveau de l'infrastructure était même possible. Le PDG, Jake Cooper, a déclaré publiquement : « Ce ne devrait pas être possible à 1000 %. Nous avons des évaluations pour cela », sans toutefois proposer de solution de récupération.

L'incident PocketOS n'est pas un cas isolé. À mesure que les agents de programmation IA s'intègrent de plus en plus aux infrastructures de production via des intégrations MCP, la surface d'attaque s'étend rapidement.

En janvier 2026, plus de 42 000 points d'accès MCP exposés ont été découverts, divulguant des clés API et des identifiants sur Internet. Sept vulnérabilités (CVE) ont été signalées concernant des implémentations MCP, dont une vulnérabilité d'exécution de code à distance (CVSS 9.6).

Les responsables de la sécurité et les ingénieurs doivent considérer ceci comme un avertissement systémique :

• Les opérations API destructives doivent exiger une confirmation humaine externe afin d'empêcher les agents autonomes de procéder à une saisie automatique.

• Les jetons API doivent prendre en charge un contrôle d'accès basé sur les rôles (RBAC) granulaire, limité au type d'opération, à l'environnement et à la ressource, et non pas une autorité globale au niveau racine.

• Les sauvegardes de volumes doivent être stockées dans un périmètre de sécurité distinct ; les instantanés du même volume ne constituent pas une stratégie de reprise après sinistre.

• Les invites système des agents IA ne peuvent pas constituer le seul niveau de contrôle ; des garde-fous doivent être mis en œuvre au niveau de la passerelle API et des autorisations des jetons, et non dans des textes d'information que le modèle pourrait ignorer.

PocketOS a restauré ses opérations à partir de sa sauvegarde datant de trois mois et reconstitue manuellement les données de réservation client à partir des enregistrements de paiement Stripe, des intégrations de calendrier et des confirmations par e-mail. Le processus de restauration devrait prendre plusieurs semaines.