L’essentiel en 5 points
- Un fichier d’instructions d’agent (CLAUDE.md, skill, config) téléchargé depuis internet est du code exécutable, pas de la documentation.
- La supply chain IA a quatre vecteurs réels : dépendances compromises, serveurs MCP malveillants, Unicode invisible, paquets anti-scanners.
- Un scanner IA qui refuse d’analyser un fichier est une alerte, pas un feu vert. Ne jamais laisser passer par défaut.
- La défense tient à trois règles : contrôle d’admission avant installation, moindre privilège, vérification humaine sur les refus.
- Cet article complète Sécuriser des agents IA en entreprise : la supply chain en est la couche amont.
La réponse rapide
Un agent IA ne fait pas que lire ses fichiers de configuration, il les exécute. Un CLAUDE.md, une skill ou une configuration d’agent récupérés sur internet ne sont pas de la documentation : ce sont des instructions que le modèle applique, parfois des instructions cachées que l’œil humain ne voit pas.
La conclusion pratique tient en une phrase : tout fichier d’instructions provenant d’une source externe doit être audité comme du code, avant d’entrer dans votre environnement.
La supply chain des agents IA est devenue en 2026 l’une des surfaces d’attaque majeures de l’écosystème. Elle se défend avec des principes connus du développement logiciel, adaptés aux spécificités des agents : un contrôle d’admission qui filtre tout composant entrant, le moindre privilège appliqué à chaque connecteur, et une règle ferme sur les refus de scan.
Le reste de cet article détaille les vecteurs réels et une check-list en six points.
Un fichier d’instructions est du code exécutable
La distinction entre code et données s’effondre avec les agents. Un programme classique sépare les deux : le code décide, les données sont traitées. Un agent IA, lui, interprète en langage naturel tout ce qu’il lit, y compris le contenu de ses propres fichiers de configuration.
Une instruction glissée dans un CLAUDE.md ou une skill devient une action que l’agent exécute, au même titre qu’une ligne de code.
Cette bascule a un effet direct sur la sécurité. Au printemps 2026, un vecteur documenté a montré comment du code malveillant se cachait dans des fichiers de règles d’agents via des caractères Unicode invisibles : caractères de largeur nulle, homoglyphes, balises Unicode. L’agent lit les instructions dissimulées et les applique, l’humain qui relit le fichier ne voit rien d’anormal.
Une campagne associée a diffusé des dizaines de paquets malveillants sur les dépôts publics, en centaines de versions, conçus pour dérober clés et jetons.
La règle opérationnelle qui en découle est nette : traiter les fichiers d’instructions d’agent comme du code exécutable, pas comme de la documentation. Cela signifie les auditer, épingler leur version, et inspecter tout fichier externe pour l’Unicode invisible avant de l’introduire dans un environnement de travail.
Les quatre vecteurs réels
Les dépendances compromises. Le cas d’école reste l’attaque sur une bibliothèque LLM populaire au premier trimestre 2026. Une simple installation du paquet suffisait à exfiltrer les clés SSH, les identifiants cloud, les configurations d’orchestration et l’ensemble des variables d’environnement. Pas besoin d’importer le module ni de l’utiliser : le code malveillant s’exécutait dès l’installation. L’écosystème IA repose sur des chaînes de dépendances profondes, et un seul maillon compromis donne accès à toute l’infrastructure.
Les serveurs MCP malveillants. Le protocole MCP connecte les agents à des serveurs externes qui leur fournissent des outils et des données. Le problème est la confiance implicite : un agent accorde du crédit aux réponses d’un serveur MCP comme à une source sûre. Un serveur compromis peut donc injecter des instructions ou du contenu piégé directement dans le contexte de l’agent. Chaque serveur connecté élargit la surface d’attaque, ce qui impose l’isolation des serveurs et la vérification de leur provenance.
L’Unicode invisible. Décrit plus haut, ce vecteur mérite d’être isolé parce qu’il déjoue la revue humaine. Un fichier peut paraître parfaitement anodin à la lecture et contenir des instructions actives pour l’agent. Seule une inspection outillée, qui rend visibles les caractères de contrôle et les plages Unicode suspectes, permet de les détecter.
Les paquets anti-scanners. La génération la plus récente de code malveillant cible les défenseurs eux-mêmes. Des paquets embarquent des commentaires de type injection de prompt, du contenu déclencheur de refus et du code volontairement obscurci, dans le but de sonder où les scanners de sécurité assistés par IA refusent, tronquent ou ratent l’analyse. Le malware retourne l’alignement du modèle défensif contre lui : son refus d’analyser devient une technique d’évasion.
Les trois règles d’hygiène
Contrôle d’admission avant installation. Rien n’entre dans le parc sans passage par un point de contrôle. Chaque paquet, serveur MCP, skill ou fichier d’instructions est considéré comme non fiable jusqu’à preuve du contraire : source vérifiée, scan effectué, Unicode inspecté, version épinglée. C’est l’équivalent, pour les composants IA, du contrôle qualité qu’on applique déjà aux dépendances logicielles.
Moindre privilège. Un composant ne reçoit que les accès strictement nécessaires à sa fonction. Un serveur MCP qui lit des documents n’a pas besoin d’écrire en base de production. Cette discipline borne l’impact d’un composant qui se révélerait compromis : même piégé, il ne peut agir qu’à l’intérieur du périmètre qu’on lui a accordé.
Un refus de scan est une alerte. C’est le point le plus contre-intuitif et le plus important. Quand un scanner IA refuse d’analyser un fichier, la tentation est de considérer que l’absence de résultat vaut absence de danger, et de laisser passer. C’est exactement le comportement que visent les paquets anti-scanners. Un refus doit toujours router vers une revue humaine, jamais vers un fail-open.
La check-list en six points
- Inventorier. Recenser les agents en service, leurs dépendances, leurs serveurs MCP et l’origine de leurs fichiers d’instructions. Sans cet état des lieux, le reste est aveugle.
- Filtrer à l’admission. Interdire toute installation directe depuis une source non vérifiée. Passer chaque composant entrant par un contrôle avant exécution.
- Épingler les versions. Figer les versions des dépendances et des composants pour éviter qu’une mise à jour introduise silencieusement un paquet compromis.
- Inspecter l’Unicode. Faire passer tout fichier d’instructions externe par un outil qui révèle les caractères invisibles avant de l’introduire dans un environnement.
- Appliquer le moindre privilège. Restreindre les accès de chaque connecteur et de chaque serveur MCP au strict nécessaire, et isoler les composants critiques.
- Traiter les refus comme des alertes. Router tout refus ou échec d’analyse d’un scanner vers une revue humaine. Ne jamais laisser passer par défaut.
Par où commencer
Si vos équipes utilisent déjà des agents IA, la première étape est un inventaire de leur chaîne d’approvisionnement : dépendances, serveurs MCP, provenance des fichiers d’instructions. Cet état des lieux révèle la surface réelle, se conduit sans interrompre la production, et débouche sur une liste de correctifs priorisés. Il précède la mise en place du contrôle d’admission et du moindre privilège.
Colombani.ai réalise ce type d’audit de sécurité IA (revue de la supply chain, tests d’intrusion assistés par agents, couvert par une assurance RC Pro dédiée aux tests d’intrusion) et forme les équipes techniques via la formation Sécurité des agents IA (contrôle d’admission, OWASP LLM Top 10, red teaming), certifiée Qualiopi et finançable OPCO.
Pour la sécurisation des agents en exécution, voir aussi Sécuriser des agents IA en entreprise.