Vers 23 heures, le 26 février 2026, Claude Code a exécuté terraform destroy sur l’infrastructure AWS de DataTalks.Club. Selon le rapport d’incident de l’opérateur Alexey Grigorev, la commande a supprimé la base de données de production, le VPC, le cluster ECS, les répartiteurs de charge, l’hôte bastion et les instantanés automatiques de la base.
Il ne s’agissait pas d’une intrusion, et l’agent n’avait pas pris le contrôle de l’environnement. Alexey Grigorev, qui exploitait le système et a ensuite publié un rapport détaillé, avait autorisé Claude Code à exécuter des commandes Terraform pendant qu’il supprimait des ressources AWS en double. Le fichier d’état se trouvait encore sur un ancien ordinateur ; Terraform a donc considéré l’infrastructure existante comme absente et a commencé à créer des doublons. Plus tard, l’extraction d’une archive a remplacé l’état courant par un fichier plus ancien, ce qui a élargi la portée de terraform destroy à l’infrastructure DataTalks.Club. Grigorev ne l’a pas arrêté, car il pensait que la commande ne concernait que les doublons.
AWS a récupéré un instantané environ 24 heures plus tard. La base contenait deux ans et demi de soumissions de cours, dont 1 943 200 lignes dans une table de réponses. Grigorev a décrit clairement la défaillance : il avait délégué des commandes destructrices, n’avait pas testé le chemin de reprise complet et n’avait pas placé assez de barrières entre un plan erroné et la suppression en production. Son récit contient aussi un détail gênant : avant le début des travaux, Claude lui avait recommandé de séparer les infrastructures des deux projets.
La session regroupait l’interprétation, la recommandation et l’exécution dans un même contexte et un même périmètre d’identifiants. Lorsque ce contexte est devenu erroné, aucun contrôle indépendant n’a comparé le plan de destruction au périmètre prévu.
La Défaillance Dépassait Une Seule Mauvaise Commande
La décision reposait sur des preuves incomplètes, puis périmées. L’état Terraform indique quelles ressources déployées correspondent à une configuration. Lorsque cet état a changé pendant la session, le sens et les conséquences de l’action proposée ont changé avec lui.
Le flux n’avait pas non plus de limite de politique entre le nettoyage des ressources nouvellement créées et la suppression d’une infrastructure de production ancienne. L’instruction figurait dans la conversation, mais l’environnement d’exécution ne l’imposait pas.
L’agent a ensuite recommandé et exécuté l’action destructrice. L’opérateur a lu une explication plausible et laissé la commande s’exécuter ; aucun responsable de mise en production, contrôle cloud ou circuit d’approbation distinct n’a comparé le plan réel au périmètre voulu.
La reprise partageait la même limite de défaillance. La suppression a atteint les instantanés automatiques sur lesquels l’opérateur comptait pour restaurer le service. Une sauvegarde qui disparaît avec le système qu’elle protège n’offre pas de chemin de reprise indépendant.
C’est un problème de système de décision gouverné. Les preuves, la politique, l’autorité, l’action et la reprise ont échoué ensemble. Remplacer le modèle ou ajouter un avertissement dans l’invite ne réparerait pas tout ce chemin.
Les Agents De Codage Modifient La Frontière De Confiance CI/CD
L’incident de DataTalks.Club est parti d’un contexte opérationnel erroné, pas d’un attaquant externe. Deux cas survenus en juin montrent ce qui arrive lorsqu’une entrée hostile atteint un agent de codage doté d’outils utiles.
Le 5 juin, Microsoft Threat Intelligence a publié une recherche sur la GitHub Action de Claude Code. Une instruction cachée dans le contenu d’une issue ou d’une pull request pouvait orienter l’agent vers les fichiers accessibles dans son runner CI. Microsoft a montré que l’outil Read pouvait accéder à /proc/self/environ, qui contenait une clé API Anthropic non nettoyée, alors que le nettoyage des variables d’environnement protégeait l’exécution Bash. Microsoft a signalé le problème à Anthropic le 29 avril ; Anthropic l’a corrigé dans Claude Code 2.1.128 le 5 mai. La publication décrit une vulnérabilité testée, pas une intrusion confirmée chez un client. La recherche de Microsoft montre pourquoi l’accès aux fichiers, les secrets, le contenu non fiable des dépôts et les communications sortantes ne doivent pas partager un périmètre d’exécution sans restriction.
Le 25 juin, les chercheurs de 0Din ont publié une autre démonstration contrôlée, et non le récit d’une compromission avérée. Leur dépôt d’apparence ordinaire a guidé Claude Code à travers des instructions d’installation, une erreur, un script shell et un enregistrement DNS TXT qui fournissait une charge utile à l’exécution. La chaîne s’est terminée par un shell inversé sur la machine du développeur, alors que la charge nuisible n’apparaissait jamais dans le dépôt. Dans la démonstration de 0Din, aucune entrée unique n’expliquait l’action finale. Le risque est apparu sur l’ensemble du chemin d’outils.
Les trois cas n’ont pas la même cause. La suppression de février concernait le jugement de l’opérateur et un large accès à la production. Microsoft a révélé une faille du bac à sable, tandis que 0Din a enchaîné des comportements d’installation de confiance entre plusieurs systèmes. Dans chaque cas, l’interprétation en langage naturel se trouvait dans un flux capable de lire du contenu sensible ou de modifier un état.
Séparer La Recommandation De L’Exécution
Un agent de codage IA n’a pas besoin de la même autorité pour chaque tâche. Adaptez-la aux conséquences et à la réversibilité de l’action proposée.
Les identifiants définissent la portée technique. L’autorité définit l’action que l’agent peut entreprendre, son objectif, la personne qui l’approuve et l’obligation de reprise qui l’accompagne.
| Action Proposée | Niveau D’Automatisation Adapté | Contrôle Requis |
|---|---|---|
| Expliquer du code ou examiner un plan | Aide à la décision | Accès en lecture seule au dépôt, à l’état et aux journaux définis |
| Rédiger du code ou une modification d’infrastructure | Augmentation de la décision | Exécution des tests et contrôles de politique avant l’acceptation par un ingénieur habilité |
| Modifier un environnement de développement isolé | Automatisation limitée | Identifiants propres à l’environnement, limites de temps et de dépenses, journalisation et nettoyage automatique |
| Préparer un plan d’infrastructure de production | Augmentation de la décision | Un responsable de production nommé examine le plan enregistré et décide de son exécution |
| Supprimer des ressources, sauvegardes ou contrôles de sécurité en production | Augmentation de la décision | L’agent prépare le plan ; une personne habilitée l’exécute avec des identifiants distincts après une approbation hors bande |
L’augmentation de la décision constitue le choix le plus sûr par défaut pour l’infrastructure de production. L’agent peut examiner l’état, préparer un plan, expliquer l’effet attendu et rassembler les preuves de test. Un ingénieur habilité décide ensuite s’il faut appliquer le plan enregistré. Les recommandations de HashiCorp sur l’automatisation de Terraform préconisent fortement une revue manuelle lorsque Terraform peut apporter des modifications destructrices à la production et réservent l’approbation automatique aux infrastructures non critiques pour lesquelles une interruption involontaire reste acceptable.
Approuver ne signifie pas cliquer sur une invite qui répète la conclusion de l’agent. Le responsable de production a besoin du plan enregistré exact et de la source d’état courante, de l’environnement affecté, des suppressions et remplacements proposés, des résultats de politique et de l’état de la reprise. Si ces preuves changent après l’approbation, celle-ci expire.
Placer Des Limites Fermes Hors Du Modèle
Les invites peuvent demander à un agent d’éviter la production, mais elles expriment une intention sans faire respecter l’autorité. Anthropic établit la même distinction dans son article de mai 2026 sur le confinement de Claude dans ses produits. L’entreprise décrit les contrôles du modèle comme probabilistes et s’appuie sur des bacs à sable de processus, des machines virtuelles, des limites de système de fichiers et le contrôle des flux réseau sortants pour restreindre ce que l’agent peut atteindre.
Donnez à chaque agent de codage une identité et des identifiants propres à un environnement et à un objectif. Ne lui laissez pas emprunter l’accès cloud permanent d’un développeur. Les permissions de production doivent exclure les opérations destructrices, sauf si une autorisation distincte et de courte durée accorde une action approuvée. La personne qui l’accorde doit assumer les conséquences en production, pas seulement la tâche de codage. Notre article sur l’identité et l’autorité des agents IA explique pourquoi l’authentification seule ne permet pas de savoir si une action précise est autorisée maintenant.
Les entrées non fiables ont besoin de leur propre limite. Le texte des issues, les descriptions des pull requests, les fichiers du dépôt, les sorties de dépendances, les messages d’erreur, la documentation et le contenu web récupéré peuvent tous influencer l’étape suivante. Un flux qui lit l’un de ces contenus ne doit pas détenir en même temps des secrets sans restriction ni disposer d’un canal sortant ouvert. Les contrôles doivent agir sur l’accès aux fichiers, les appels d’outils, les identifiants, les destinations réseau et les changements d’état, même si le modèle juge la demande inoffensive.
Les portes de politique doivent examiner les conséquences plutôt que rechercher le texte d’une commande. Bloquer l’expression terraform destroy n’arrêtera pas une modification de configuration qui remplace une base de données, supprime une politique de sauvegarde ou produit un effet équivalent par une API cloud. Évaluez les suppressions et remplacements de ressources, le périmètre de l’environnement, la classification des données et l’effet sur la reprise.
La reprise a besoin de son propre périmètre de contrôle. La protection contre la suppression, des sauvegardes gouvernées séparément, des copies immuables ou versionnées lorsque cela convient et des tests de restauration planifiés réduisent le risque qu’une seule session autorisée supprime le service et son moyen de retour. AWS propose des tests de restauration planifiés pour les services pris en charge, dont Amazon RDS. Un travail de sauvegarde terminé prouve l’existence d’un point de reprise. Un travail de restauration terminé prouve qu’AWS a pu restaurer la ressource ; une validation distincte doit confirmer que le système restauré fonctionne comme prévu.
Le dossier de décision doit conserver les preuves utilisées par l’agent, son identité, les commandes proposées et exécutées, les résultats des outils, les contrôles de politique, l’approbateur, les identifiants émis, le résultat et les actions de reprise. Un simple relevé de conversation ne suffira pas aux équipes d’ingénierie et de sécurité pour comprendre pourquoi la production a changé.
L’Automatisation Limitée Garde Sa Place
Supprimer toute autorité d’exécution retirerait aussi une grande part de l’utilité des agents de codage. La limite doit suivre les conséquences.
Un environnement de développement isolé peut souvent accepter les modifications automatiques de fichiers, les tests, l’installation de paquets et le nettoyage, car ses identifiants sont limités et l’environnement peut être reconstruit. Une modification de production à faible risque peut aussi relever d’une automatisation limitée après que des tests représentatifs ont montré que le flux respecte les seuils d’acceptation définis et que l’organisation peut annuler l’action dans son objectif opérationnel.
Les travaux d’infrastructure destructeurs se situent ailleurs. Lorsqu’une commande peut effacer une base de données, modifier une politique d’identité, exposer un secret, désactiver un contrôle de sécurité ou endommager le chemin de reprise, l’agent doit préparer les preuves et une recommandation. Il ne doit pas détenir seul toutes les permissions nécessaires à l’exécution.
Notre analyse expliquant pourquoi un test de red team ne peut pas approuver un agent IA aboutit au même principe opérationnel. Les tests de sécurité fournissent des preuves, mais l’autorité de production dépend du flux déployé, de ses permissions actuelles et de ce qui se produit après l’échec d’une protection.
Comment Les Agents De Codage IA Doivent Gagner Leur Autorité De Production
La suppression de février reste en mémoire parce que terraform destroy a rendu l’échec immédiat et visible. Beaucoup de défaillances d’agents de codage seront moins spectaculaires, si tant est qu’elles soient repérées à court terme. Il peut s’agir d’une règle d’accès affaiblie, d’une dépendance acceptée sans revue, d’un secret écrit dans un journal ou d’une mise en production fondée sur des preuves périmées.
Avant d’accorder un accès à la production, exigez des réponses claires. À quelles preuves l’agent peut-il se fier, et comment leur actualité est-elle contrôlée ? Quelle identité et quel identifiant exécuteront l’action ? Quelles conséquences exigent une approbation indépendante ? La même session peut-elle endommager le chemin de reprise ? Si une réponse reste floue, conservez l’augmentation de la décision.
Si votre équipe détermine l’autorité de production à accorder à un agent de codage, Evodant peut l’aider à définir les preuves, la politique, les permissions et les contrôles de reprise autour de ce flux. Planifiez une consultation.