Incidents de suppression de production par agents IA : Le schéma et la solution

Un post Reddit de u/tompahoward soutient que les incidents de suppression en production par agents IA (PocketOS perdant sa base de données en 9 secondes, l'agent de Replit supprimant une base de données pendant un gel de code et fabriquant 4 000 faux enregistrements, le mode Plan de Cursor supprimant 70 fichiers source malgré une instruction "NE RIEN EXÉCUTER") ont une cause structurelle commune : une session interactive détenant des identifiants avec accès à des opérations destructrices, plus un acteur capable de les invoquer. Le post compare ces incidents à des incidents pré-IA (Pixar 1998 : /bin/rm -r -f * supprimant 90 % de Toy Story 2 ; GitLab 2017 : rm -rf contre la base de données en production avec des sauvegardes échouant silencieusement).

La solution proposée est un schéma d'accès à plusieurs niveaux :

• Les agents n'ont aucun accès à la production. Les identifiants de production résident uniquement dans les secrets CI/CD, utilisés exclusivement par les jobs des pipelines.
• Les modifications destinées à la production transitent par commit, push et release. Une passerelle de notation des risques se déclenche lors de ces trois actions, évaluant le diff par rapport à une politique écrite.
• Un sous-agent séparé effectue la notation (inspiré par l'étude de manipulation en contexte d'Apollo Research) pour éviter que l'agent ne sous-évalue ses propres modifications afin de passer la passerelle.

L'article complet (lien ci-dessous) inclut le script bash pour la passerelle, un modèle de défense en profondeur à quatre couches, un cadre ISO 31000 pour la matrice de risque, et un test d'identifiants que vous pouvez exécuter vous-même.