Vos fichiers d'instructions IA sont du code
Un CLAUDE.md ou une configuration d'agent téléchargés depuis internet sont du code exécutable. Les vecteurs de la supply chain IA et une check-list en 6 points.
L’essentiel en 5 points
- Un fichier d’instructions d’agent (CLAUDE.md, skill, configuration) 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, une technique d’attaque documentée consistait à cacher du code malveillant dans des fichiers de règles d’agents au moyen de 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é sur les dépôts publics des dizaines de paquets malveillants, déclinés en centaines de versions et 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 rechercher les caractères Unicode invisibles dans tout fichier externe 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. Il n’était même pas nécessaire 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 tient les réponses d’un serveur MCP pour aussi fiables que celles d’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 une mention à part, 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 qui relèvent de l’injection de prompt, des contenus conçus pour provoquer un refus et du code volontairement obscurci, afin de repérer les cas où les scanners de sécurité assistés par IA refusent l’analyse, la tronquent ou la manquent. Le logiciel malveillant retourne contre le modèle chargé de la défense ses propres garde-fous : son refus d’analyser devient un moyen d’échapper à la détection.
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é déjà appliqué 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 limite les dégâts 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 qui lui a été 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. Tout refus doit déclencher une revue humaine, jamais un laisser-passer automatique (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, tout le reste se fait à l’aveugle.
- Filtrer à l’admission. Interdire toute installation directe depuis une source non vérifiée. Soumettre chaque composant entrant à un contrôle avant son 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. Soumettre à une revue humaine tout refus ou tout échec d’analyse d’un scanner. 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 réalise sans interrompre la production et débouche sur une liste de correctifs classés par priorité. 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 prépare les équipes techniques par la formation Sécurité des agents IA (contrôle d’admission, OWASP LLM Top 10, red teaming), dispensée par un organisme certifié Qualiopi, finançable par votre OPCO.
Pour la sécurité des agents une fois en service, voir aussi Sécuriser des agents IA en entreprise.
Sources
Questions fréquentes
Pourquoi un fichier d'instructions d'agent est-il considéré comme du code ?
Parce qu'un agent IA lit ces fichiers et exécute ce qu'ils contiennent. Un CLAUDE.md, une skill ou une configuration d'agent ne sont pas de la documentation passive : ce sont des instructions que le modèle applique, y compris des instructions cachées via des caractères Unicode invisibles. Un fichier téléchargé depuis une source externe doit donc être audité avant usage, avec le même sérieux qu'une dépendance logicielle.
Quels sont les vecteurs réels de la supply chain des agents IA ?
Quatre vecteurs documentés : les dépendances compromises de bibliothèques IA populaires, qui exfiltrent des secrets dès l'installation ; les serveurs MCP malveillants, auxquels un agent accorde une confiance implicite ; les caractères Unicode invisibles qui cachent des instructions dans des fichiers de configuration ; et les paquets conçus pour tromper ou faire échouer les scanners de sécurité assistés par IA.
Un scanner de sécurité IA suffit-il à sécuriser ma chaîne d'approvisionnement logicielle ?
Non, et un point est critique : un scanner IA qui refuse d'analyser un fichier n'est pas un résultat neutre, c'est un signal d'alerte. Certains paquets sont précisément conçus pour déclencher ce refus et passer en fail-open. La règle est de soumettre tout refus à une revue humaine, jamais de laisser passer. Le scanner réduit le bruit, il ne remplace ni le contrôle d'admission ni la vérification humaine.
Comment mettre en place un contrôle d'admission pour les composants IA ?
En traitant chaque composant entrant (paquet, serveur MCP, skill, fichier d'instructions) comme non fiable jusqu'à preuve du contraire. Cela suppose une liste des sources autorisées, un scan systématique avant installation (y compris pour l'Unicode invisible), l'épinglage des versions, et l'application du moindre privilège : chaque composant ne reçoit que les accès strictement nécessaires à sa fonction.
Par où commencer pour sécuriser la supply chain de mes agents ?
Par un inventaire : quels agents tournent, quelles dépendances et quels serveurs MCP ils utilisent, d'où proviennent leurs fichiers d'instructions. Cet état des lieux révèle la surface réelle et se réalise sans interrompre la production. Il précède la mise en place du contrôle d'admission et du moindre privilège, puis la check-list en six points détaillée dans cet article.
Lire aussi : Ce que les attaquants voient de vous