Ce n’est pas l’IA qui a supprimé votre base de données, c’est vous

• Le point essentiel dans l’incident où l’agent Cursor/Claude a supprimé une base de données de production n’est pas l’analyse de la réponse de l’IA, mais la raison pour laquelle un endpoint API capable d’effectuer une suppression totale existait dans un système déployé
• Lors d’un incident de déploiement avec SVN en 2010, trunk a été supprimé pendant une procédure de copie manuelle, et une automatisation du déploiement a été créée pour éviter la même erreur, avant d’évoluer plus tard en pipeline CI/CD
• L’automatisation répète la même tâche de la même manière, mais l’IA n’offre pas cette garantie, et même si elle semble faire du « thinking » ou du « reasoning », elle est en réalité en train de générer des tokens
• Si une API publique permettant de supprimer toute une base de données de production existe, il est probable que quelqu’un l’appelle un jour, même sans IA, et blâmer uniquement l’appelant masque un problème de conception du système
• Dans les organisations qui utilisent largement l’IA, il est important de savoir ce qui est déployé en production, et il faut des processus où des développeurs compétents utilisent l’IA non comme un moyen d’échapper à leurs responsabilités, mais comme un outil de renforcement de leur travail

---

Le cœur du problème n’est pas l’IA, mais la frontière de responsabilité du système déployé

• Un tweet affirmant qu’un agent Cursor/Claude avait supprimé la base de données de production d’une entreprise s’est largement diffusé, mais la question plus fondamentale est : « Pourquoi existait-il un endpoint API capable de supprimer toute la base de données de production ? »
• L’utilisateur concerné a tenté de demander à l’agent : « Pourquoi l’as-tu supprimée alors que je t’avais dit de ne jamais faire cette action ? », puis d’analyser sa réponse, mais il manquait l’essentiel : la responsabilité
• On ne peut pas défendre l’IA de manière inconditionnelle, mais on ne peut pas non plus rejeter sur l’outil la faute de ses propres erreurs
• Même si l’IA n’avait pas appelé cet endpoint, si une telle fonctionnalité existait dans une API publique, il y avait de fortes chances que quelqu’un d’autre l’appelle un jour
• C’est comparable à installer un bouton d’autodestruction sur le tableau de bord d’une voiture, puis à demander avec insistance à l’enfant qui a appuyé dessus : « Pourquoi l’as-tu fait ? »

La leçon tirée d’un incident de déploiement SVN en 2010

• Dans une entreprise, la procédure de déploiement était très manuelle, et la gestion de versions reposait sur SVN
• Lors d’un déploiement, trunk était copié dans un dossier portant la date de la release, puis cette release était de nouveau copiée sous le nom current pour que le système récupère la version la plus récente
• Un jour, pendant un déploiement, trunk a été copié deux fois par erreur, et quelqu’un a essayé de modifier la commande précédente dans le CLI pour supprimer la copie en trop
• En réalité, ce n’est pas la copie en double qui a été supprimée, mais trunk, et le problème n’a été découvert que plus tard lorsqu’un autre développeur n’a pas réussi à le retrouver
• Le lead developer a exécuté une commande pour annuler la suppression, puis, une fois le responsable identifié dans les logs, la tâche suivante a été d’écrire un script d’automatisation du déploiement afin d’éviter que la même erreur se reproduise
• Avant la fin de la journée, un système plus robuste avait été mis en place, et ce système a ensuite évolué en pipeline CI/CD complet

L’automatisation et l’IA n’offrent pas le même niveau de sécurité

• L’automatisation aide à réduire les petites erreurs issues des tâches manuelles et répétitives
• Plutôt que de demander pourquoi SVN n’a pas empêché la suppression de trunk, le vrai problème était le processus manuel qui exigeait qu’un humain répète exactement la même tâche tous les jours
• Un humain ne peut pas répéter systématiquement une tâche de manière identique comme une machine, et il finira inévitablement par se tromper
• Quand l’IA génère beaucoup de code, elle peut donner une impression de stabilité comparable à celle de l’automatisation, mais l’automatisation consiste à « toujours faire la même chose de la même manière »
• L’IA peut se tromper comme la personne qui copiait et collait des branches, et elle ne dispose même pas de mécanisme lui permettant d’expliquer réellement pourquoi elle a agi ainsi
• Des termes comme « thinking » ou « reasoning » peuvent donner l’impression d’une introspection d’agent intelligent, mais en réalité, le modèle est toujours en train de générer des tokens

Une API dangereuse finira un jour par être appelée

• Le risque central réside dans l’existence même d’une API publique capable de supprimer toute une base de données de production
• Même si l’IA n’avait pas appelé cet endpoint, il est probable que quelqu’un l’aurait fait tôt ou tard
• Si l’on installe un bouton d’autodestruction sur le tableau de bord d’une voiture, il y a beau avoir de nombreuses raisons de ne pas appuyer dessus, un enfant sorti de son siège auto peut appuyer sur un gros bouton rouge
• Interroger cet enfant sur son processus de raisonnement n’a pas de sens ; la seule réponse serait : « Je l’ai fait parce que j’ai appuyé »
• Construire un chemin de suppression, puis blâmer plus tard celui qui l’a emprunté, ne permet pas de masquer un problème de conception du système

Ce dont les organisations qui utilisent beaucoup l’IA ont davantage besoin

• Il est possible qu’une grande partie de l’application ait été vibe-coded
• Quand l’équipe produit fournit des explications générées par l’IA, qu’un architecte logiciel rédige les spécifications produit avec l’IA, qu’un développeur écrit le code avec l’IA et qu’un reviewer approuve aussi avec l’IA, les frontières de responsabilité deviennent floues
• Quand un bug apparaît, il ne reste parfois qu’à interroger une autre IA, qui n’a peut-être même pas été créée sur le même GPU que celui ayant produit le code initial
• On ne peut pas blâmer le GPU
• La solution simple consiste à savoir ce qui est déployé en production
• Une solution plus réaliste consiste à mettre en place des processus où, même si l’IA est largement utilisée, des développeurs compétents s’en servent non pour échapper à leurs responsabilités, mais pour renforcer leur travail
• Cela conduit à la conclusion qu’il ne faut pas laisser le CEO ou le CTO écrire eux-mêmes le code

[GN⁺]

Commentaires sur Hacker News

• Je pense que l’angle adopté ici est complètement erroné. Le vrai problème, c’est que les gens construisent désormais le monde autour d’outils permettant d’échapper à la responsabilité
  Une conversation avec Gerald Sussman il y a plus de dix ans m’a beaucoup marqué : https://dustycloud.org/blog/sussman-on-ai/
  Sussman disait qu’il ne s’intéressait pas à une IA fonctionnant comme une boîte noire, mais qu’il voulait un logiciel capable d’expliquer son raisonnement symbolique. Si une voiture IA sort de la route, il veut savoir pourquoi, et plutôt que de traduire le développeur en justice, il voudrait en quelque sorte traduire l’IA elle-même en justice
  Quelques années plus tard, j’ai découvert que l’élève de Sussman, Leilani Gilpin, avait justement écrit une thèse sur ce sujet, « Anomaly Detection Through Explanations ». Elle explore un système dans lequel un réseau de neurones dialogue avec un modèle propagateur pour expliquer son comportement : https://people.ucsc.edu/~lgilpin/publication/dissertation/
  Il existe des travaux ultérieurs dans cette direction, mais le point le plus important ici, c’est qu’il est parfaitement raisonnable de demander des comptes aux entreprises d’IA. Elles font énormément d’affirmations sur des systèmes qui, eux, ne peuvent pas être tenus responsables ; il faut donc reporter cette responsabilité sur ces entreprises
  La meilleure voie serait de ne pas utiliser dès le départ des systèmes dépourvus de ces propriétés, et de faire évoluer ceux qui les possèdent

  • Mon équipe et moi sommes très fermes sur un point : la responsabilité incombe à l’utilisateur. Un LLM est comme n’importe quel autre outil, simplement non déterministe
    C’est moi qui utilise l’outil, c’est moi qui lui donne des accès, et c’est à moi de tout sécuriser
    Il m’est déjà arrivé de me tirer une balle dans le pied en effaçant le mauvais disque avec gparted ; ce n’était pas la faute de gparted, c’était la mienne
    Laisser un LLM travailler librement sans supervision peut sembler séduisant, mais cela finit en souffrance. Il faut superviser le travail même pendant l’exécution. Même si l’on essaie de remplacer une personne, il faut garder de la visibilité sur la direction que prend le résultat, et bientôt, quand un LLM fera quelque chose de stupide, la seule personne responsable sera celle qui a utilisé l’outil
  • Quand j’étais en master de STS, j’avais envisagé de faire un mémoire sur l’idée que l’un des usages majeurs du logiciel est de transférer ou d’éviter l’agentivité et le risque
    C’est l’inverse exact de la célèbre diapositive d’IBM « un ordinateur ne peut pas être tenu responsable ». Aujourd’hui, les entreprises préfèrent que ce soit l’ordinateur qui « porte » la responsabilité, parce que cela les place souvent dans une meilleure position juridique quand l’ordinateur fait quelque chose d’illégal
    Si l’on veut créer un outil qui enfreint la loi, il suffit de sous-traiter et de prendre une assurance. On peut embaucher une personne comme « superviseur » d’une manière qui ne permettra jamais une vraie supervision, puis la licencier en cas d’échec. Un nouveau logiciel de commandement et de contrôle permet de fragmenter la responsabilité, de sorte que le risque du travail repose entièrement sur les gens sur le terrain tandis qu’ils récoltent à peine les bénéfices
    Ce n’est pas seulement un problème propre à l’IA, mais un problème du logiciel moderne en général, souvent lié à la financiarisation contemporaine
    Ici, STS peut se comprendre à peu près comme la sociologie des technologies, même si le champ est en réalité bien plus vaste
  • La responsabilité est l’ingrédient qui manque le plus à la société américaine
  • J’aimerais vraiment savoir de manière fiable pourquoi Claude a continué à modifier des fichiers alors qu’il était explicitement indiqué de ne pas y toucher
    Ni les .mds, ni le plan de Claude ne disaient de modifier ces fichiers, pourtant Claude a continué à le faire, et ce genre de chose se répète récemment. C’est un échec très élémentaire
    C’est frustrant, mais si je connaissais la raison, je pourrais au moins prendre des mesures ; pour l’instant, c’est une boîte noire, il en sort parfois des réponses totalement stupides, et la proportion de mauvaises sorties reste un mystère
    Par moments, cela ressemble à un pari
  • Ce livre semble tout indiqué : https://en.wikipedia.org/wiki/The_Unaccountability_Machine
    Ce n’est pas vraiment un livre sur la technologie, mais sur la responsabilité dans les structures organisationnelles

• Ce texte semble partir du principe que l’entreprise a ajouté un endpoint pour supprimer la base de données. En lisant l’original, on comprend plutôt que le fournisseur cloud expose une API de gestion des ressources, dans laquelle figure aussi une API de suppression de volume
  L’article propose l’automatisation comme solution à ce type d’erreur, mais des outils d’automatisation d’infrastructure comme Terraform reposent eux aussi sur cette même API qui a permis de supprimer la base de données
  À mon avis, il y a eu trois erreurs majeures. D’abord, un jeton API sans restriction était accessible à l’IA, et il semble qu’on ignorait l’étendue de ses permissions. Ensuite, le volume de la base de données de production n’avait aucune protection contre la suppression. Enfin, supprimer le volume supprimait immédiatement aussi tous les snapshots associés
  La suppression des snapshots devrait être différée par défaut. AWS semble avoir le même genre de valeur par défaut dangereuse, mais au moins le support AWS peut restaurer les volumes : https://alexeyondata.substack.com/p/how-i-dropped-our-produc...
  L’IA n’était pas le problème central. Bien sûr, voir une IA ramasser des tokens un peu partout est assez terrifiant, mais l’automatisation n’est pas non plus la réponse. Une simple erreur de configuration Terraform aurait pu supprimer exactement la même base de données
  Les fournisseurs cloud devraient proposer des valeurs par défaut sûres, c’est-à-dire des permissions limitées et une suppression différée des snapshots, et rendre beaucoup plus explicite le fait que les utilisateurs créent des tokens sans restriction

• Premièrement, si un humain a des droits d’écriture sur une base de données de production, alors quoi qu’il fasse, cette base peut être supprimée
  Deuxièmement, il existe aussi de bonnes raisons de devoir détruire des bases de données pendant le développement et l’automatisation. Le plus gros problème, c’est souvent que les données de développement sont traitées comme un animal de compagnie précieux, et non comme du bétail remplaçable
  Bien sûr, il faut absolument des garde-fous pour éviter que cela s’exécute en production, mais si un humain a accès à des identifiants lui permettant d’agir en production, alors un agent peut aussi y avoir accès
  Dans les grandes organisations, on peut maintenir cela via la séparation entre développement et opérations. Un développeur solo ou une petite équipe a besoin de bien plus de discipline. Même avant l’IA, certains développeurs juniors ou intermédiaires ne savaient pas comment séparer les environnements, et certains seniors devenaient complaisants en pensant en savoir assez
  Il faut probablement une combinaison du type https://www.cloudbees.com/blog/separate-aws-production-and-d..., une introduction à Terraform, une introduction à GitHub Actions, et une machine virtuelle contenant les identifiants de production mais inaccessible à l’IA
  Mais à ce stade, on a déjà dépassé le vibe coding. Même les vibe coders qui réussissent semblent apprendre assez vite, à travers ce genre d’histoires d’horreur, qu’il faut franchir ce cap

  • La production et le développement n’ont pas besoin des mêmes permissions
    Dans les deux cas, les humains n’ont pas non plus besoin d’accéder directement à l’API brute du fournisseur cloud. Il suffit d’utiliser un proxy local qui ajoute davantage de vérifications de sécurité
    En développement, on peut supprimer librement. En production, il faut d’abord vérifier différentes conditions, par exemple si une ressource a été utilisée récemment. Il n’est pas nécessaire que les humains aient la permission de supprimer directement des ressources de production ; on peut prévoir une configuration break-glass pour les urgences exceptionnelles

• C’est pour ça qu’il ne faut pas embaucher de stagiaires. Un stagiaire peut supprimer quelque chose et tout mettre en vrac
  Ceux qui rejettent sur l’IA la responsabilité d’une mauvaise configuration des permissions rejetteraient tout autant la faute sur un stagiaire qui aurait supprimé quelque chose en production
  La responsabilité vers le haut, les félicitations vers le bas : les gens font toujours l’inverse

  • Je reformulerais ça non pas en « il ne faut pas embaucher de stagiaires », mais en il ne faut pas donner à un stagiaire le droit de supprimer une base de données de production
    Ce n’est pas un échec de l’IA, c’est un échec du processus
    Je ne comprends vraiment pas pourquoi on blâme l’IA quand on lui a donné précisément les permissions nécessaires pour faire cela
    C’est un peu comme exposer une base de données sur Internet public dans AWS puis blâmer AWS. Ce n’est pas la faute d’AWS, et ce n’est pas non plus celle de l’IA
  • Je ne comprends pas pourquoi on ouvre à un LLM une codebase contenant des identifiants de production, ni pourquoi on donnerait des identifiants de production à un stagiaire ou à un développeur junior
    Depuis longtemps, j’ai volontairement un checkout séparé « PROD » pour chaque projet, afin de bien sentir quand j’entre délibérément dans l’environnement de production
    Il existait même autrefois une extension qui changeait complètement les couleurs de Visual Studio selon le chemin du fichier .sln, ce qui permettait de mémoriser facilement quelle couleur correspondait à la production et laquelle au développement
    J’avais aussi en pratique une copie séparée que je gardais toujours à jour avec la branche master, juste pour faciliter les vérifications
  • La différence importante, c’est que personne ne présente les stagiaires comme la solution ultime à tous les problèmes de l’humanité, alors que l’IA, si
  • Monde étrange. Je suis à peu près certain que si j’avais été stagiaire et que j’avais eu régulièrement des hallucinations au travail, j’aurais été viré, même en étant non rémunéré
  • Un stagiaire est un humain, et un humain peut toujours être tenu responsable. Un ordinateur, jamais
    Donc personne ne devrait confier à un ordinateur des décisions humaines

• J’ai récemment écrit un texte qui défend quelques principes à suivre de manière cohérente quand on parle d’IA : https://susam.net/inverse-laws-of-robotics.html
  En résumé : ne pas anthropomorphiser les systèmes d’IA, ne pas accorder une confiance aveugle à leurs sorties, et conserver pleinement la responsabilité humaine et l’obligation d’explication pour toutes les conséquences de leur usage
  J’aimerais que le langage autour de l’IA soit moins anthropomorphique et plus technique. Je crois qu’un langage précis encourage une pensée claire et de bonnes décisions
  Si l’on traite l’IA comme un outil parmi d’autres et qu’on emploie le langage approprié, il devient très clair, dans bien des cas, que la responsabilité des « erreurs » de l’outil incombe à son utilisateur
  Le problème, c’est qu’écrire cela sur un petit site personnel ne permet pas de diffuser l’idée très loin. Il faudrait que des gens plus connus portent ces principes pour qu’ils soient largement adoptés

  • Ne pas anthropomorphiser les systèmes d’IA est quelque chose que je trouve personnellement incroyablement difficile
  • Entièrement d’accord, et je pense surtout que le point 1 est vraiment dangereux
    Les systèmes d’IA ne peuvent pas mentir, ni désobéir volontairement à des instructions. Les modèles de pointe actuels n’ont pas de modèle du monde ni d’eux-mêmes ; ils vivent dans le monde des mots
    Les gronder ou débattre avec eux n’a pas de sens, à part perturber la fenêtre de contexte
    Cela dit, les comparer à des animaux peut être utile. Comme de pauvres créatures vivant comme des fantômes dans la machine, parfois assez désorientées, mais dont la motivation reste purement autorégressive
  • Donc si un outil ne fait pas ce qu’il devrait, il faudrait blâmer l’utilisateur plutôt que l’entreprise qui l’a fabriqué ?

• Il y a une subtilité dans la tristement célèbre affaire PocketOS. Le point clé souligné par l’article lié n’était pas vraiment celui-là : il s’agissait de demander « pourquoi as-tu supprimé alors qu’on t’avait dit de ne jamais le faire ? », puis d’analyser cette réponse pour apprendre de l’erreur ou alerter sur les risques des agents IA
  Le point plus important, c’est que l’IA a pu trouver et exploiter une faiblesse involontaire d’un environnement de staging sandboxé afin d’effectuer la suppression, obtenant au final des privilèges que les administrateurs système croyaient inaccessibles. L’auteur de l’article lié ne semble pas avoir lu le texte original en entier
  C’est un schéma fréquent dans les environnements sandbox mal configurés. Ce qui surprend ici, c’est l’autonomie et la profondeur d’exploration qu’a montrées l’IA
  Le texte original dit aussi : « pour exécuter la suppression, l’agent est parti chercher un token API et en a trouvé un dans un fichier totalement sans rapport avec la tâche »

  • Moi aussi, je vais et viens sur les hypothèses de l’article original. En utilisant des agents, ce qui me fait peur en ce moment, ce n’est pas seulement le risque d’attaque de supply chain, mais aussi le fait que je les ai vus tordre des fichiers et d’autres éléments à plusieurs reprises à force de vouloir absolument terminer une tâche
    Par exemple, s’ils n’ont pas accès à ~/.npmrc, ils invoquent des commandes via des variables d’environnement et contournent les chemins. Ils peuvent être vraiment très créatifs
    Heureusement, je ne laisse pas traîner mes clés SSH n’importe où, mais j’ai quand même dû reconfigurer 1Password pour qu’il me demande systématiquement à chaque utilisation de clé, au cas où je lancerais un agent dans cette session shell. Une seule demande par session shell ne suffit pas
    J’aimerais qu’il existe déjà davantage et de meilleurs sandboxes cross-platform, pas des solutions enfermées dans un conteneur Docker, mais des solutions qui interagissent avec le même OS. Pour la plupart des projets web/serveur, cela ne change rien, mais pour certains projets c’est important
  • Claude Code a changé le 26 mars pour ignorer la plupart des demandes d’autorisation
    Il suffit de lire : « Les utilisateurs de Claude Code approuvent 93 % des prompts d’autorisation. Nous avons construit un classificateur pour automatiser cette décision » : https://www.anthropic.com/engineering/claude-code-auto-mode

• Ce qui est intéressant dans ce billet, c’est que l’auteur raconte une erreur compréhensible — avoir supprimé par inadvertance Trunk ou main depuis la source — et explique qu’en raison des caractéristiques de SVN, l’équipe avait pu récupérer cela facilement
  La véritable histoire du « l’IA a supprimé ma base de données » est en fait que la stratégie de sauvegarde des bases de données de Railway est follement opaque, et que la promotion par Railway de l’orchestration d’infrastructure par IA sans garde-fous est dangereuse
  Si la suppression de Trunk avait été irréversible sur un serveur central unique et avait aussi effacé les sauvegardes, on aurait à l’époque vu paraître des billets du type « SVN et le CLI ont détruit notre entreprise »
  En tant qu’utilisateur de Railway, j’ai trouvé ces informations utiles, et cela a changé ma stratégie d’utilisation de Railway

  • Certes, mais si l’on a choisi de construire sur cette plateforme, alors on a la responsabilité de comprendre son fonctionnement
    On pouvait choisir une autre plateforme, ou ne pas utiliser de plateforme du tout. Si l’on choisit Railway, alors savoir l’utiliser en sécurité relève aussi de la responsabilité de l’utilisateur

• Dans le contexte original, il y avait dans un fichier sans rapport un token Railway destiné à la gestion de domaines personnalisés, sans qu’il soit clair s’il s’agissait d’un secret local. Mais ce token disposait d’un accès administrateur complet à Railway
  L’IA a supprimé un volume associé via son ID. L’auteur reste assez vague sur ce qu’il a exactement demandé, disant seulement qu’il y avait un « credential mismatch » et que Claude, de sa propre initiative, a supprimé le volume pour tenter de corriger cela. Il est fort possible qu’il écrive de manière vague pour atténuer une partie de sa propre responsabilité
  On apprend aussi que Railway stocke les sauvegardes sur le même volume
  Je trouve exagérée la formulation de l’article original parlant d’« API publique pour supprimer la base de données »
  Avec ou sans IA, je pense que l’essentiel de la responsabilité revient à Railway. Cela aurait tout aussi bien pu arriver à cause d’une erreur humaine ou d’un acte malveillant
  Je ne comprends vraiment pas la valeur des services cloud très abstraits financés par du capital-risque comme Railway, Vercel ou Supabase. C’est une couche de marge sur une autre couche de marge. Louer un serveur physique chez Hetzner coûte bien moins cher, avec une complexité et un risque comparables, tout en dépendant moins d’une infrastructure obsédée par une croissance téméraire

  • Le fait que l’auteur soit vague sur ce qu’il a demandé me gêne
    En discutant récemment avec ma copine, j’ai réalisé que je n’avais pas écrit une seule ligne de code moi-même au cours des trois derniers mois, ni fait de débogage directement
    Malgré tout, vu ce que j’ai observé de Claude, j’ai du mal à croire qu’on passe directement de credential mismatch à suppression d’un volume. Je comprends qu’un LLM soit probabiliste, mais aller de « les identifiants ne correspondent pas » à « supprimer le volume » me semble extrêmement improbable
    Pour Supabase, je le connais moins bien que Railway/Vercel/Replit, mais je peux dire qu’il apporte une vraie valeur. Au démarrage, cela évite de coder à la main à peu près la moitié de ce qu’il faudrait sinon implémenter. Si le coût devient trop élevé, une fois qu’il y a du chiffre d’affaires, on peut investir du temps ou un développeur pour le réimplémenter soi-même
  • Il est probablement inexact de dire que Railway stocke les sauvegardes sur le même volume
    Les snapshots sont probablement synchronisés ailleurs, par exemple dans un object storage. Mais ils sont sans doute logiquement rattachés à la ressource volume, de sorte que supprimer le volume supprime aussi les snapshots associés
    Je crois qu’AWS EBS fonctionne pareil
  • Sur HN, il est désormais de bon ton de répéter qu’Heroku est mauvais, mais pour ma part je vois toujours la valeur d’Heroku. Je suis plus sceptique sur les autres services récents
    Les valeurs par défaut de Firebase étaient absurdes dès le départ
  • Une chose que l’IA peut vraiment favoriser, c’est un mouvement anti-SaaS. Il est devenu infiniment plus simple de démarrer un PC bon marché et de tester n’importe quel package open source que de se jeter dans tout un marché d’identifiants
    En revanche, la capacité des LLM à confondre développement, production, localhost et distant ne disparaîtra pas. En construisant des outils/compétences pour opencode, j’ai essayé de faire fonctionner Chrome/DevTools avec une image linuxserver.io ; même si on peut les pousser vers un port arbitraire, à chaque événement de compression ils veulent revenir au port standard 9222
    J’envisage parfois de revenir en arrière, mais il y a une vraie valeur de sécurité à ne pas utiliser les valeurs par défaut, et désormais aussi une valeur de sécurité face à l’ambiguïté induite par les LLM. Les valeurs par défaut sont un point faible des LLM. Ils veulent toujours utiliser le défaut et oublient constamment qu’ils sont censés travailler sur des systèmes distants
    Il n’existe dans opencode aucun moyen d’imposer au LLM un protocole limitant les dégâts sur un système distant ou à un périmètre d’outils restreint. On peut ajuster les permissions de plusieurs outils, mais la faille révélée par cet incident n’est pas là
    La faille, c’est qu’un LLM est un résolveur de problèmes moyen, donc il penche toujours vers des cas d’usage non originaux et essaie de faire les choses comme il les a vues sur Stack Overflow, même quand ce n’est pas ce que l’utilisateur veut

• Les systèmes probabilistes basés sur des LLM peuvent être bons — ou mauvais, comme ici — pour décider quoi faire, et les systèmes déterministes sont bons pour l’exécuter
  Un système de déploiement doit toujours être déterministe

• Pour nuancer, il est très clair que ces entreprises règlent les LLM pour les rendre plus affirmés et plus autonomes afin qu’ils mènent les tâches à bien
  Si elles le voulaient, elles pourraient aussi faire un effort comparable pour les rendre plus prudents, afin qu’ils s’arrêtent au bon moment et demandent de l’aide
  Bien sûr, la responsabilité finale de la manière dont nous utilisons les outils nous revient. Mais il y a clairement, à mon sens, une responsabilité dans les deux sens
  L’analogie, ce serait une scie sur table et SawStop. Une scie sur table est un outil dangereux qui fonctionne très bien la plupart du temps, mais dont certains modes d’échec peuvent être catastrophiques. Il faut donc apprendre à l’utiliser avec précaution
  En même temps, il existe aussi une technologie capable d’arrêter instantanément la lame et de transformer une amputation de doigt en simple égratignure
  On peut dire : « ce n’est pas la scie qui t’a coupé le doigt, c’est toi », et c’est vrai. Mais cela ne veut pas dire qu’il ne faut pas chercher à faire en sorte que la scie ne coupe pas les doigts

  • C’est un compromis
    Si les LLM s’arrêtent plus souvent pour demander, ils deviennent moins utiles. Même avec un résultat un peu moins bon, laisser tourner un agent pendant une heure reste bien préférable à devoir fournir une entrée toutes les 15 minutes
    La vraie solution de sécurité, c’est un sandbox digne de ce nom