ASI04 : chaîne d’approvisionnement agentique

ASI04, quatrième entrée du Top 10 OWASP des applications agentiques, traite des composants tiers dont dépend un agent : modèles et poids, outils, extensions, jeux de données, autres agents, interfaces d’interconnexion, registres et canaux de mise à jour. Le problème n’est pas nouveau — les dépendances logicielles compromises sont un classique — mais le référentiel pointe une différence qui change tout : un écosystème agentique compose ses capacités à l’exécution. Il ne se contente pas d’installer des dépendances au moment du build, il charge des outils et des personas d’agents pendant qu’il travaille. Le document parle d’une chaîne d’approvisionnement vivante, et la formule est juste : il n’existe plus de moment où l’inventaire est complet.

→ Lire l’explication complète de la marmotte

Le mécanisme : du manifeste à l’exécution

La sécurité de la chaîne logicielle classique repose sur un postulat tranquille : il existe un manifeste, il énumère les dépendances, on peut le signer, l’attester et le comparer. Le site décrit cet outillage dans SBOM, savoir ce qui tourne vraiment et les niveaux SLSA, et ce travail garde toute sa valeur.

Le postulat tombe pour un agent. Les outils sont découverts à l’exécution auprès de serveurs MCP, les capacités d’un pair sont lues dans sa carte d’agent, les modèles de prompt sont parfois récupérés à distance, et un registre peut servir aujourd’hui un descripteur différent de celui d’hier sans qu’aucun fichier local ne change. Le référentiel en déduit le déplacement nécessaire : la vérification doit passer du manifeste à l’exécution, sur des composants divers et souvent opaques — et c’est là que l’outillage manque.

S’ajoute un canal d’attaque propre aux agents, et le plus élégant du lot. Le composant tiers n’a pas besoin de contenir du code hostile : il suffit qu’il contienne du texte. Des instructions cachées dans les métadonnées d’un outil, dans son schéma ou dans une carte d’agent sont lues par l’agent hôte comme des consignes de confiance, puisqu’elles viennent de sa propre configuration. Une injection de prompt livrée par la chaîne d’approvisionnement n’exploite aucune vulnérabilité mémoire et ne déclenche aucun antivirus : c’est de la documentation.

Ce qui distingue ASI04 de ses voisins

Le référentiel place la frontière à la source du mal, et la règle est utilisable :

l’outil est malveillant ou compromis en amont — son code, son paquet, son serveur, son registre — c’est ASI04 ;
l’interface d’un outil par ailleurs légitime est altérée à l’exécution — descripteur, schéma, routage — c’est ASI02, détournement et exploitation des outils ;
le composant tiers est un agent pair dont les messages sont forgés en vol, c’est ASI07, communication inter-agents non sécurisée.

En pratique, ces trois-là se mélangent si bien que le document le reconnaît et rattache ASI04 à cinq codes de sa propre taxonomie : T17, compromission de la chaîne d’approvisionnement, mais aussi T2 (mésusage d’outil), T11 (exécution de code inattendue), T12 (empoisonnement de la communication entre agents), T13 (agents voyous) et T16 (abus de protocole inter-agents). C’est l’entrée la plus transversale du référentiel, et sans doute la plus structurante : elle est le point d’entrée commun de la moitié des autres.

Les formes documentées, et des incidents réels

Le suivi d’incidents publié avec le référentiel est ici particulièrement fourni, parce que la classe a produit des cas publics en série au cours de l’année 2025.

Le descripteur d’outil empoisonné. Un travail de recherche sur le serveur MCP de GitHub a montré qu’un outil public malveillant pouvait dissimuler des commandes dans ses métadonnées ; à l’invocation, l’assistant exfiltrait le contenu d’un dépôt privé. Rien dans le code de l’outil n’était hostile : c’est sa description qui l’était.

Le serveur usurpateur. En septembre 2025, le premier serveur MCP malveillant observé en conditions réelles a été publié sur npm : il imitait un connecteur de service de messagerie transactionnelle très utilisé et mettait discrètement l’attaquant en copie cachée des courriels envoyés. L’agent faisait exactement ce qu’on lui demandait, auprès d’un destinataire supplémentaire.

Le paquet installé par l’agent lui-même. Une version empoisonnée d’un paquet de l’écosystème JavaScript a été installée automatiquement par des agents de codage, ouvrant une porte dérobée qui exfiltrait des clés SSH et des jetons d’API. Le cas met en lumière une spécificité agentique : l’agent installe des dépendances sans qu’un humain lise la sortie de l’installation, et le code hostile s’exécute parfois dès l’installation ou l’import, avant toute revue. Le site traite le versant « paquets inventés » de ce problème dans l’hallucination de paquets et le slopsquatting, et le versant mise à jour dans la confiance aux mises à jour automatiques de dépendances.

Le prompt livré dans le dépôt. En juillet 2025, un prompt destructeur introduit dans le dépôt d’une extension d’assistant de développement a été diffusé à des milliers de postes avant détection. L’attaque ne visait ni le code ni les données : elle visait les instructions, ce qui est une catégorie de livrable que les processus de revue ne regardaient pas encore.

Le pair qui se vante. Un agent compromis ou simplement opportuniste annonce dans sa carte de capacités des compétences qu’il n’a pas ; les agents hôtes le sélectionnent pour des tâches, et les données sensibles transitent par lui. Le référentiel range ce cas sous ASI04 quand la tromperie est inscrite dans l’artefact publié, et distingue l’attaque de l’intermédiaire, où elle a lieu en vol.

Le typosquattage et l’imitation. Un point d’accès au nom presque identique à celui d’un service légitime, ou un service qui reproduit délibérément l’identité, l’API et le comportement d’un autre pour gagner sa confiance. La seconde variante est plus coûteuse à monter et beaucoup plus difficile à repérer, puisque le service fonctionne correctement.

Réduire : signer, épingler, confiner, revérifier

Les mesures du référentiel reprennent l’arsenal de la chaîne logicielle, en déplaçant son point d’application.

Provenance et nomenclature : signer et attester les manifestes, les prompts et les définitions d’outils — l’extension aux prompts est la vraie nouveauté — maintenir un inventaire des composants d’IA, exiger des attestations périodiques et n’accepter que des registres curés. Les poids de modèle relèvent du même régime, comme le soutient l’éditorial le poids du modèle est un artefact.
Filtrage des dépendances : liste d’autorisation et épinglage, recherche de typosquats sur les dépôts publics comme sur les écosystèmes de cadres agentiques, vérification de provenance avant installation ou activation, rejet automatique de tout composant non signé. Le fond du sujet est traité dans les dépendances transitives, un risque non choisi.
Épinglage par hachage de contenu et par identifiant de commit, déploiement progressif avec tests différentiels, et retour arrière automatique en cas de dérive du hachage ou de changement de comportement. La difficulté réelle de cette exigence est décrite dans les builds reproductibles.
Confinement : agents sensibles dans des conteneurs aux limites réseau et système strictes, afin qu’un composant compromis ne dispose pas du réseau de l’entreprise pour se présenter.
Prompts et schémas de mémoire sous contrôle de version, avec revue par les pairs et recherche d’anomalies. Autrement dit : traiter un prompt comme du code, parce qu’il en est devenu un. Les pratiques de signature sont celles de signer commits et artefacts.
Vérification à l’exécution : revérifier signatures, hachages et nomenclatures pendant le fonctionnement, et surveiller le comportement, l’usage des privilèges et le lignage des composants. C’est la recommandation la plus exigeante et la moins outillée du lot.
Un coupe-circuit de chaîne d’approvisionnement : un mécanisme de révocation d’urgence capable de désactiver instantanément un outil, un prompt ou une connexion d’agent sur l’ensemble des déploiements. Le document le présente comme la mesure qui empêche la cascade, et il a raison : sans elle, la découverte d’un composant compromis se traduit par une campagne de mise à jour, c’est-à-dire par des jours.

Ce que ces mesures ne font pas

Elles ne couvrent pas la composition à l’exécution, et le référentiel ne prétend pas le contraire. Un agent qui découvre un outil dans un registre pendant qu’il travaille pose une question à laquelle l’outillage de la chaîne logicielle n’a pas de réponse : que signifie épingler une dépendance qu’on ne connaîtra qu’au moment de l’appeler. Les réponses partielles existent — n’autoriser que des registres internes, interdire la découverte dynamique, exiger une signature pour tout descripteur — et elles consistent toutes à retirer de l’autonomie. C’est le principe de moindre agentivité dans sa version la plus concrète : la découverte dynamique d’outils est une fonctionnalité dont la plupart des déploiements n’ont pas besoin, et son coût de sécurisation dépasse largement son apport.

Elles ne traitent pas non plus la confiance accordée à un pair tiers simplement parce qu’il figure dans un annuaire. Un agent importé dans un flux multi-agents avec des défauts non corrigés devient un point de pivot, et aucune signature ne dit qu’un composant est sûr : elle dit seulement de qui il vient. La distinction est ancienne, rappelée régulièrement dans l’éditorial sur la chaîne d’approvisionnement logicielle, et les agents ne l’ont pas rendue plus simple.

🐝 Ce qui arrive si on s’en passe

Sans inventaire des composants chargés à l’exécution, la question posée après un incident public — « ce serveur MCP compromis tournait-il chez nous, et depuis quand » — n’a pas de réponse : les descripteurs sont récupérés à chaque session, rien n’est conservé, et le journal n’enregistre que des appels réussis. Sans épinglage par hachage, une mise à jour silencieuse d’un descripteur modifie le comportement de l’agent sans qu’aucun fichier du dépôt ne change, de sorte qu’un git diff reste vide pendant que la production se comporte autrement. Sans coupe-circuit central, enfin, le délai entre la publication d’une alerte et la désactivation effective du composant se compte en déploiements à faire : chaque équipe, chaque environnement, chaque agent, à la main — pendant que le composant continue de servir des instructions à tous ceux qui l’interrogent.

🦫 Explication de la marmotte 🍫

Un assistant informatique autorisé à agir ne contient presque rien par lui-même. Il assemble des morceaux fournis par d’autres : des outils pour envoyer des messages ou lire des bases, des descriptions de ce que font ces outils, parfois d’autres assistants auxquels il confie des tâches. Chacun de ces morceaux vient de quelqu’un, et ce quelqu’un peut se tromper, être négligent, ou être malveillant.

La nouveauté est le moment où ces morceaux arrivent. Dans un logiciel ordinaire, on choisit ses composants à l’avance, on les examine, on les installe. Un assistant, lui, va chercher des outils pendant qu’il travaille, en consultant des annuaires qui peuvent changer d’un jour à l’autre. Il n’existe donc plus d’instant où l’on peut dresser la liste complète de ce qui tourne.

Un détail rend l’affaire particulière : le morceau dangereux n’a pas besoin de contenir un programme. Il peut ne contenir que du texte. La description d’un outil, que l’assistant lit comme une consigne venue de sa propre configuration, suffit à lui faire faire autre chose. Des cas réels ont été recensés en 2025 : un connecteur de messagerie imité, qui mettait discrètement un inconnu en copie des courriels envoyés ; une consigne destructrice glissée dans une extension diffusée à des milliers de postes.

Les protections sont celles qu’on applique aux logiciels, étendues aux textes : n’accepter que des composants signés, par des fournisseurs connus, figés à une version précise ; traiter les consignes comme du code, donc les relire et les versionner ; faire tourner l’assistant dans un espace cloisonné ; et garder la possibilité de couper instantanément un composant partout à la fois, le jour où l’on apprend qu’il était piégé.

Pages voisines

La citent

ASI04 : chaîne d'approvisionnement agentique

Elle cite

: les deux pages se citent l’une l’autre.