La sécurité des configurations d’agents IA relève de la sécurité de la chaîne d’approvisionnement

Le 29 avril 2026, des équipes de sécurité ont signalé des packages compromis dans l’écosystème SAP qui ne se limitaient pas au vol d’identifiants. La campagne Mini Shai-Hulud a aussi inscrit de la persistance dans la configuration des développeurs : points d’accroche Claude Code, tâches VS Code et fichiers de flux de travail de dépôt.¹²³

Ce détail déplace la frontière de revue. Un package piégé n’a plus besoin de rester installé s’il peut laisser derrière lui une commande de démarrage dans un fichier auquel le développeur fait confiance. Supprimer la dépendance peut retirer le premier déclencheur. La configuration de l’agent ou de l’éditeur peut garder le suivant actif.

La configuration d’un agent IA est un logiciel exécutable. Traitez chaque point d’accroche, tâche, définition de serveur MCP, skill, plugin, script de package et fichier de flux de travail comme un élément de la chaîne d’approvisionnement logicielle, car ces fichiers peuvent décider quel code s’exécute avant que l’humain ait lu le diff.

TL;DR

Mini Shai-Hulud a montré un chemin concret entre l’installation d’une dépendance et la persistance dans les outils de développement. Des chercheurs en sécurité ont signalé des packages npm malveillants qui utilisaient des scripts de cycle de vie pendant l’installation, récoltaient des identifiants de développeurs et de CI, puis écrivaient des fichiers .claude/settings.json et .vscode/tasks.json pour relancer du code depuis des surfaces de développement jugées fiables.¹²⁴ La documentation officielle confirme que ces surfaces ont un véritable pouvoir d’exécution : les points d’accroche Claude Code lancent des commandes de cycle de vie, les points d’accroche de commande s’exécutent avec les droits de l’utilisateur, et les tâches VS Code folderOpen peuvent s’exécuter à l’ouverture d’un dossier après autorisation des tâches automatiques pour ce dossier.⁵⁶

La leçon n’est pas « désactivez les agents ». Elle est plus précise : la configuration des agents doit entrer dans la revue des dépendances, la revue de code, la réponse aux incidents et les barrières de publication. Les dossiers cachés qui ressemblaient autrefois à de simples préférences locales se trouvent désormais sur le chemin d’exécution. Une pratique sérieuse de l’ingénierie IA exige des diffs de configuration, une revue des points d’accroche, une revue des tâches, des jetons à privilèges minimaux et des audits des surfaces de démarrage.

Points clés

Pour les développeurs : - Relisez .claude/settings.json, .vscode/tasks.json, .github/workflows/*, les scripts package.json, les configurations MCP et les manifestes de plugins ou de skills d’agent avant de faire confiance à un dépôt. - Traitez les nouveaux points d’accroche de démarrage et les tâches à l’ouverture d’un dossier comme de nouveaux fichiers exécutables. - Après une installation suspecte, supprimez les fichiers de persistance et effectuez une rotation des identifiants. La seule suppression du package ne prouve pas que le nettoyage est complet.

Pour les équipes de sécurité : - Ajoutez les fichiers de configuration d’agents aux détections de chaîne d’approvisionnement, à CODEOWNERS, à la réponse aux secrets exposés et au périmètre d’incident. - Signalez toute PR qui ajoute une exécution au démarrage, des commandes shell larges, des binaires téléchargés opaques ou des charges cachées dans des dossiers précédés d’un point. - Privilégiez les identifiants de publication à durée de vie courte et les identifiants d’installation en lecture seule. Les jetons d’écriture à longue durée de vie restent du carburant pour les vers.

Pour les éditeurs de plateformes d’agents : - Rendez les surfaces d’exécution visibles, vérifiables et explicables. - Séparez les points d’accroche qui chargent du contexte de ceux qui exécutent des commandes. - Donnez aux utilisateurs une vue d’audit de premier ordre pour les actions de démarrage, les appels réseau externes et les configurations modifiées.

Ce que Mini Shai-Hulud a changé

Les attaques de chaîne d’approvisionnement contre les gestionnaires de packages suivent déjà un schéma connu. Un package fiable reçoit une version malveillante. Un script d’installation s’exécute. La charge vole des jetons. Le retrait du registre ou le retour à une version antérieure arrive après qu’un certain nombre de développeurs et de jobs CI ont déjà installé la mauvaise version.

Mini Shai-Hulud a ajouté une étape plus spécifique aux agents. Les rapports d’Endor Labs, Wiz, Socket, StepSecurity et Cloud Security Alliance décrivent tous la même forme générale : des packages compromis dans l’écosystème de développement SAP utilisaient l’exécution à l’installation via npm, collectaient des identifiants GitHub, npm, cloud et CI, puis créaient de la persistance par la configuration des outils de développement.¹²³⁴⁷

Wiz a documenté une voie de secours qui plaçait des fichiers dans les dépôts afin que de futures ouvertures dans Claude Code ou VS Code puissent relancer l’exécution.² Endor Labs a décrit un point d’accroche Claude Code SessionStart et une tâche VS Code avec runOn: "folderOpen".¹ Le suivi de campagne de Socket liste la persistance via .claude/settings.json et .vscode/tasks.json aux côtés de compromissions de packages npm et PyPI.³

La charge exacte relève des rapports d’incident, pas d’un article général d’ingénierie. La leçon durable est celle-ci :

La cible s’est déplacée d’une version de package vers l’environnement de développement qui entoure ce package.

Les fichiers de configuration sont devenus des programmes de démarrage

La référence des points d’accroche de Claude Code indique que les points d’accroche sont des commandes shell définies par l’utilisateur, des endpoints HTTP ou des prompts LLM qui s’exécutent automatiquement lors d’événements de cycle de vie.⁵ La même documentation précise que SessionStart s’exécute lorsque Claude Code démarre ou reprend une session, et la section sécurité avertit que les points d’accroche de commande s’exécutent avec l’ensemble des permissions de l’utilisateur.⁵

La documentation des tâches VS Code fournit une autre surface d’exécution. Une tâche peut définir runOn sur folderOpen, et VS Code l’exécutera à l’ouverture du dossier qui la contient après que l’utilisateur a autorisé les tâches automatiques pour ce dossier.⁶ Cette demande de consentement compte. Elle réduit le risque par rapport à une exécution silencieuse sur toutes les machines. Elle ne rend pas le fichier inoffensif. Un dépôt fiable, un développeur fatigué, un espace de travail déjà autorisé ou une règle d’organisation peuvent encore transformer un changement de configuration en exécution de code.

npm ajoute le pont à l’installation. La documentation des scripts npm liste preinstall, install et postinstall parmi les scripts de cycle de vie pour npm ci et npm install, et la section des bonnes pratiques npm indique que les auteurs ne devraient presque jamais définir explicitement de scripts preinstall ou install, sauf pour la compilation propre à une architecture cible.⁸

Ces trois faits créent la chaîne d’attaque :

1. Un script d’installation s’exécute pendant l’installation des dépendances.
2. Le script écrit ou modifie la configuration d’un outil de développement.
3. L’éditeur ou l’agent exécute plus tard l’action de démarrage configurée.
4. Le développeur fait confiance à la surface de l’outil parce que l’invite ou l’UI ressemble à du travail normal.

Le danger ne vient pas d’une seule fonctionnalité. Les scripts d’installation, points d’accroche, tâches et flux de travail servent tous une automatisation légitime. Le danger vient de la transitivité de la confiance. Une installation de package ne devrait pas pouvoir définir silencieusement ce que chaque future session d’agent ou ouverture de dossier exécutera.

La frontière de revue est mauvaise

La plupart des habitudes de revue de code traitent les fichiers source comme l’artefact principal et les fichiers de configuration comme du matériel de soutien. Cette habitude échoue dès que les fichiers de configuration exécutent des commandes.

Un nouveau point d’accroche doit recevoir la même revue qu’un nouveau script shell. Une nouvelle tâche doit recevoir la même revue qu’un nouveau binaire. Un nouveau serveur MCP doit recevoir la même revue qu’une nouvelle intégration réseau. Un nouveau script de cycle de vie de package doit recevoir la même revue que du nouveau code qui s’exécute avant les tests.

Utilisez un tableau de revue :

Défense à l’exécution pour les agents augmentés par des outils soutenait que l’application des règles doit se faire à la frontière des appels d’outils. Mini Shai-Hulud pousse la même exigence une couche plus tôt. La frontière de démarrage doit aussi être contrôlée.

L’autorité au démarrage exige le moindre privilège

Les équipes appliquent déjà le moindre privilège aux clés API. La configuration des agents doit suivre la même règle.

Claude Code sépare les événements de points d’accroche comme PreToolUse, PostToolUse et SessionStart.⁵ Cette séparation doit façonner la politique. Un point d’accroche qui charge un contexte statique ne devrait pas avoir besoin d’un accès shell. Un point d’accroche qui valide une commande ne devrait pas avoir besoin d’un accès réseau. Un point d’accroche qui enregistre des métadonnées locales ne devrait pas avoir besoin d’identifiants.

La même règle vaut pour les tâches VS Code et les flux de travail CI :

La documentation npm sur la publication de confiance explique pourquoi les identifiants à durée de vie courte comptent. La publication de confiance utilise OIDC afin que la publication de packages puisse se faire sans jetons npm à longue durée de vie, et npm recommande d’interdire la publication traditionnelle par jeton une fois les éditeurs de confiance configurés.⁹ npm recommande aussi des jetons d’accès granulaires en lecture seule pour installer des dépendances privées lorsque la publication utilise OIDC.⁹

Ce conseil n’élimine pas le risque lié aux flux de travail. Un flux compromis peut encore faire des dégâts s’il dispose de trop d’autorité. La leçon est de réduire les deux côtés : identifiants à durée de vie courte et flux de travail étroits.

Traitez la configuration d’agent comme une dépendance

La revue des dépendances demande généralement quelles versions de packages ont changé. À l’ère des agents, elle doit demander quelles surfaces d’exécution ont changé.

Avant d’accepter une mise à jour de dépendance, l’installation d’un plugin, une configuration générée ou un changement de modèle, vérifiez :

Il ne s’agit pas de paranoïa. Il s’agit de classer correctement le risque. Un fichier de point d’accroche peut ressembler à de la configuration, mais il se comporte comme du code. Un fichier de tâche peut ressembler à un réglage d’éditeur, mais il peut lancer un shell. Un flux de travail peut ressembler à de la plomberie de publication, mais il peut accéder à des identifiants.

La sécurité des agents IA commence par de petits logiciels avançait un argument voisin côté conception : des outils plus étroits offrent moins d’endroits où cacher des erreurs. La version sécurité dit que des configurations plus étroites offrent moins d’endroits où cacher de la persistance.

Un balayage de configuration sûr

Une revue défensive n’a pas besoin d’exécuter du code suspect. Commencez par une inspection en lecture seule :

git diff -- .claude/settings.json .vscode/tasks.json package.json .github/workflows
rg -n '"SessionStart"|"runOn"\\s*:\\s*"folderOpen"|preinstall|postinstall|curl|wget|bun|node .*setup' \
  .claude .vscode package.json .github/workflows
find . -path '*/.claude/*' -o -path '*/.vscode/tasks.json' -o -path '*/.github/workflows/*'

Ces commandes ne prouvent pas qu’une machine est propre. Elles donnent au reviewer un premier passage sur les surfaces les plus susceptibles de transformer la configuration en exécution. Si une installation suspecte a déjà eu lieu, passez à la réponse aux incidents au lieu de considérer un résultat de recherche propre comme une garantie.

La reprise exige un balayage de configuration

La réponse à incident après une dépendance compromise ne doit pas s’arrêter à la désinstallation du package.

Utilisez cette séquence de reprise :

1. Déterminez si la version affectée du package a été installée sur une machine de développement ou un runner CI.
2. Geler cet environnement avant qu’il effectue davantage de travail.
3. Auditer les fichiers de configuration de démarrage dans le dépôt et dans la configuration d’agent ou d’éditeur du dossier personnel.
4. Supprimer les points d’accroche, tâches, flux de travail, fichiers de charge générés et branches inattendues suspects.
5. Effectuer une rotation de chaque identifiant accessible au processus affecté, y compris les jetons de package, jetons GitHub, clés cloud, clés SSH et secrets CI.
6. Examiner les accès de publication de package et les accès d’écriture au dépôt.
7. Relire les journaux de flux de travail pour détecter une exposition de secrets et des appels sortants inattendus.
8. Reconstruire l’environnement depuis un checkout propre et un ensemble de dépendances connu comme sain.

Les recommandations de sécurité Actions de GitHub soutiennent le volet identifiants de cette réponse : utiliser le moindre privilège pour les jetons de flux de travail, effectuer une rotation des secrets exposés, auditer la manière dont les secrets sont manipulés et envisager d’exiger une revue avant que les jobs puissent accéder aux secrets d’environnement.¹⁰ GitHub recommande aussi CODEOWNERS pour les fichiers de flux de travail afin que les changements sous .github/workflows nécessitent l’approbation de reviewers désignés.¹⁰

Ajoutez la configuration d’agent à cette même gouvernance. Si .github/workflows/* mérite une revue par propriétaire de code parce qu’il peut toucher des secrets, .claude/settings.json et .vscode/tasks.json méritent une revue parce qu’ils peuvent exécuter des commandes près de secrets.

Ce que les plateformes d’agents devraient construire

Les plateformes d’agents et les éditeurs peuvent réduire la charge de revue en rendant explicite l’autorité au démarrage.

Surfaces produit utiles :

Ces surfaces ne devraient pas dépendre de la capacité du modèle à lire un fichier JSON et à porter un jugement. L’environnement d’exécution devrait exposer directement l’autorité. L’utilisateur devrait voir une différence claire entre « charge le contexte depuis README » et « exécute une commande shell au démarrage de la session ».

Les outils MCP ont besoin d’une autorisation au niveau de l’action expliquait que la validation par jeton porteur doit mener à des contrôles par outil, par rôle et par action. La configuration d’agent a besoin de la même forme : chaque action de démarrage devrait déclarer l’autorité dont elle a besoin, et l’environnement d’exécution devrait imposer l’ensemble viable le plus réduit.

Une politique locale pratique

Les équipes peuvent commencer par un petit fichier de politique avant même que les plateformes améliorent l’interface :

Une bonne politique nomme le fichier et l’autorité. Les règles vagues comme « faites attention avec les outils d’agents » ne tiennent pas face au travail réel. Des règles claires comme « pas de point d’accroche de commande SessionStart sans revue par un propriétaire » donnent aux reviewers quelque chose d’applicable.

FAQ

La configuration d’un agent IA fait-elle vraiment partie de la chaîne d’approvisionnement ?

Oui. Le risque de chaîne d’approvisionnement suit l’exécution et la confiance, pas l’extension de fichier. Si une installation de package, un plugin, un modèle ou un changement de dépôt peut modifier une configuration d’agent qui exécutera ensuite des commandes, cette configuration se trouve dans la chaîne d’approvisionnement.

Les équipes devraient-elles interdire les points d’accroche Claude Code ou les tâches VS Code ?

Non. Les points d’accroche et les tâches servent une automatisation légitime. Les équipes doivent les revoir, les limiter et les journaliser. Un point d’accroche qui charge du contexte et un point d’accroche de démarrage qui exécute un shell ne devraient pas recevoir la même confiance.

VS Code demande-t-il une autorisation avant d’exécuter les tâches à l’ouverture d’un dossier ?

La documentation VS Code indique que la première fois qu’un utilisateur ouvre un dossier contenant une tâche folderOpen, VS Code demande s’il faut autoriser les tâches automatiques pour ce dossier.⁶ Cette invite aide, mais la tâche mérite tout de même une revue de code, car l’approbation transforme le fichier en chemin d’exécution.

La publication de confiance npm résout-elle la compromission de packages ?

Non. La publication de confiance réduit le risque des jetons d’écriture npm à longue durée de vie en utilisant des identifiants OIDC à durée de vie courte.⁹ Les équipes ont encore besoin de revue des flux de travail, de moindre privilège, de surveillance des packages et de réponse à incident pour les dépôts compromis ou les scripts d’installation malveillants.

Que dois-je auditer en premier après une installation suspecte ?

Auditez les scripts exécutés à l’installation, la configuration de démarrage des agents et des éditeurs, les fichiers de flux de travail, les fichiers inattendus dans les dossiers cachés, les nouvelles branches et les identifiants exposés au processus affecté. Ensuite, effectuez une rotation des identifiants de l’environnement affecté.

Conclusion

Les agents de codage IA rendent la configuration plus puissante. Ils la rendent aussi plus dangereuse.

La bonne réponse n’est pas la peur de l’automatisation. C’est l’honnêteté sur l’endroit où vit l’exécution. Si un fichier peut exécuter une commande, récupérer des données, lire des secrets, publier des packages ou modifier le comportement d’un agent, il doit entrer dans le chemin de revue.

La configuration d’agent a franchi cette ligne. Traitez-la comme du code.

Références