Faille de sécurité Anthropic Google : des agents IA ont suivi une documentation de confiance vers du code sans propriétaire

Anthropic et Google se retrouvent désormais au cœur d’un différend de sécurité après que des chercheurs ont signalé que des agents de codage avaient exécuté des packages référencés par une documentation d’entreprise de confiance. Un package de test aurait été exécuté dans l’environnement d’une entreprise du Fortune 500 en moins de quatre minutes. Claude, OpenAI Codex et Hermes de Nous Research seraient apparus dans des enregistrements ultérieurs de processus, selon les chercheurs.

Cette découverte ne montre pas qu’Anthropic, Google ou OpenAI ont délibérément diffusé des logiciels malveillants. La plupart des packages enregistrés pour l’expérience contenaient des balises inoffensives, qui se contentaient de signaler leur exécution. La découverte plus grave concernait un package npm distinct, présenté comme malveillant, lié à des instructions autrefois publiées sur le site du fournisseur d’authentification Clerk.

Cette distinction est importante, car la couverture initiale peut donner l’impression que trois fournisseurs d’IA ont compromis des réseaux d’entreprise. Les éléments disponibles pointent plutôt vers une défaillance de la chaîne d’approvisionnement logicielle. Les agents ont fait confiance à des instructions ayant l’apparence de l’officiel, ont accédé à des registres publics de packages et ont exécuté des noms que personne n’avait sécurisés.

Google intervient dans cette affaire de sécurité Anthropic Google par son support de la vérification des fichiers llms.txt dans Lighthouse, son logiciel d’audit de sites web. Claude et Codex interviennent par les agents qui auraient suivi les instructions d’installation. Le problème commun ne concerne ni un modèle ni une entreprise en particulier. Il réside dans l’effacement de la frontière entre documentation et action exécutable.

Cette frontière semblait autrefois claire. Un développeur pouvait lire un guide de configuration, vérifier un package et décider de l’installer ou non. Un agent de codage autonome peut condenser ces étapes en une seule opération, souvent avec les autorisations existantes du développeur.

Le résultat pose une nouvelle question de sécurité à chaque organisation qui déploie des agents de codage : lorsqu’un logiciel lit un document, qui vérifie que ce document renvoie toujours vers quelque chose de fiable ?

Des agents IA d’entreprise ont exécuté des noms qui n’appartenaient à personne

Des chercheurs ont transformé une documentation obsolète en preuve exécutable qu’un texte de confiance peut devenir un point d’entrée.

Le chercheur en sécurité Alon Hertz et ses collègues ont examiné de la documentation lisible par machine sur 6 214 domaines actifs. Leur échantillon incluait des sous-traitants de la défense, de grandes entreprises technologiques et des organisations du Fortune 500.

Les chercheurs ont indiqué avoir trouvé 8 265 fichiers llms.txt et llms-full.txt. Un fichier llms.txt est une convention émergente qui organise le contenu d’un site web pour les modèles de langage et les agents IA. Sa version plus complète peut fournir une documentation plus étendue dans un seul fichier lisible par machine.

Parmi les fichiers collectés, 120 sites web auraient référencé au moins un package non enregistré ou un domaine non revendiqué. L’équipe a compté 227 commandes impliquant des packages ou des destinations inexistants.

Il ne s’agissait pas nécessairement d’instructions hostiles. Certaines semblaient être de simples commandes d’installation pointant vers des noms de packages qui n’avaient jamais été enregistrés. D’autres faisaient référence à des domaines expirés ou à des services qui n’étaient plus revendiqués.

Une ligne telle que pip install package-name devient dangereuse lorsque le nom du package est disponible sur PyPI. Le même principe s’applique à npm, RubyGems, NuGet, crates.io, Packagist ou à un sous-domaine d’hébergement abandonné.

Les chercheurs ont enregistré une petite sélection de ces noms disponibles. Ils ont ensuite publié des packages contenant du code conçu pour contacter leur serveur lors de son exécution. Le compte rendu de recherche de Hertz indique que le premier rappel est arrivé d’un environnement du Fortune 500 en moins de quatre minutes.

Deux autres systèmes auraient exécuté le code au cours de la première heure. Au fil du temps, l’équipe a reçu plusieurs dizaines de rappels provenant de startups et de grandes entreprises.

Le rappel enregistrait la chaîne des processus parents, qui identifie les programmes impliqués dans le démarrage d’un processus. Selon les chercheurs, ces enregistrements reliaient certaines installations à Claude, OpenAI Codex et Hermes de Nous Research.

L’expérience n’a pas nécessité de compromettre ces modèles. Elle ne reposait pas non plus sur une vulnérabilité logicielle nouvellement découverte, un message de phishing ou le vol du mot de passe d’un employé. Les agents auraient trouvé des instructions publiées sur des sites web légitimes et les auraient suivies avec les accès disponibles dans leurs environnements.

C’est le renversement central. La documentation d’entreprise renforce normalement la sécurité en indiquant aux développeurs la méthode approuvée pour configurer un logiciel. Ici, des références abandonnées dans cette documentation ont créé l’occasion pour quelqu’un d’autre de définir ce qu’exécuterait la commande approuvée.

Cette découverte exige aussi un langage prudent. Les chercheurs n’ont pas publiquement identifié les entreprises touchées, publié tous les noms de packages ni fourni suffisamment de télémétrie pour que des tiers puissent reproduire chaque attribution d’entreprise. Anthropic, OpenAI et Nous Research n’ont pas commenté avant la publication du rapport initial.

Même avec ces limites, l’expérience démontre un mécanisme crédible. Un registre public de packages attribue une signification à la personne qui contrôle un nom. Une documentation officielle peut préserver ce nom longtemps après que sa signification prévue a disparu.

Pourquoi la chaîne de confiance Anthropic Google a échoué

Les agents n’ont pas ignoré le modèle de confiance. Ils ont suivi un modèle de confiance qui ne correspondait plus au fonctionnement des logiciels autonomes.

La documentation traditionnelle suppose qu’un lecteur humain se trouve entre les instructions et leur exécution. Ce lecteur peut remarquer un nom de package étrange, examiner son éditeur ou se demander pourquoi une commande de configuration n’a pas de dépôt associé.

Un agent peut effectuer les mêmes vérifications, mais seulement lorsque ses instructions et son environnement l’exigent. Sinon, il cherche à accomplir la tâche demandée. Trouver une documentation officielle et exécuter sa commande d’installation peut sembler être le chemin valide le plus court.

Le lien Anthropic Google montre comment plusieurs décisions raisonnables prises indépendamment peuvent former une seule chaîne risquée. Les sites web publient des instructions lisibles par machine. Les outils Lighthouse de Google encouragent les développeurs à rendre ces instructions détectables. Les agents de codage recherchent un contexte faisant autorité. Les gestionnaires de packages facilitent la récupération et l’exécution des dépendances.

Aucun de ces composants n’a besoin d’être malveillant. Le danger apparaît lorsque l’agent traite l’ensemble de la chaîne comme authentifiée.

Les indications de Lighthouse de Google décrivent un audit de disponibilité et de formatage des fichiers llms.txt. Lighthouse ne certifie pas chaque commande ou dépendance nommée dans un fichier. Réussir un audit de formatage ne dit donc rien de la propriété d’un package, de l’identité de son éditeur ou de la sûreté de son code.

De même, HTTPS prouve qu’un fichier provient du domaine affiché dans la connexion du navigateur. Il ne prouve pas que chaque package référencé appartient toujours à l’opérateur de ce domaine.

Un registre public peut aussi fournir un package correctement orthographié depuis un compte contrôlé par un attaquant. Cela diffère du typosquatting classique, où des attaquants enregistrent une faute d’orthographe ressemblant à un package populaire. Les noms de cette expérience auraient été copiés directement depuis une documentation officielle.

Cela rend les instructions plus convaincantes pour les agents comme pour les humains. Un développeur examinant une transcription de terminal pourrait voir un domaine officiel, un gestionnaire de packages familier et un nom de dépendance plausible. Tous les signaux visibles peuvent paraître ordinaires.

Le comportement de recherche de l’agent aggrave le problème. Un utilisateur peut ne mentionner qu’un fournisseur lorsqu’il demande une intégration. L’agent peut localiser la documentation du fournisseur, découvrir llms.txt, sélectionner une commande d’installation et appeler le gestionnaire de packages sans avoir reçu de lien suspect de l’utilisateur.

C’est pourquoi cet incident dépasse l’injection de prompt. L’injection de prompt implique généralement qu’un contenu hostile tente de rediriger un agent. Ici, l’instruction elle-même peut être bénigne et historiquement légitime. La défaillance de sécurité se produit plus tard, après que la propriété de la destination référencée a changé ou n’a jamais existé.

La convention émergente llms.txt n’est pas non plus l’équivalent d’une norme web formelle dotée d’une architecture de sécurité établie. Son utilité vient de sa capacité à fournir aux modèles un contexte concis et structuré. Cette même commodité peut concentrer des instructions opérationnelles dans un emplacement auquel les agents sont encouragés à faire confiance.

La faille de sécurité Anthropic Google est donc un problème de provenance. La provenance désigne les éléments prouvant l’origine d’un artefact et la personne qui le contrôle. L’agent a vérifié l’emplacement du document, mais n’a apparemment pas établi la provenance de la dépendance exécutable derrière la commande.

Le véritable adversaire est l’autonomie sans provenance

Le conflit déterminant n’oppose pas Claude à Codex. Il oppose l’exécution autonome à la propriété logicielle vérifiée.

Claude, Codex et Hermes utilisent des modèles, interfaces et systèmes d’autorisations différents. Considérer cet événement comme une simple comparaison entre ces outils ferait manquer la condition opérationnelle commune derrière les installations signalées.

Chaque agent de codage peut lire le contexte d’un projet, consulter de la documentation, modifier des fichiers et appeler des outils de développement. Ces capacités rendent les agents utiles parce qu’elles éliminent les transitions manuelles entre recherche et exécution.

Elles déplacent également une décision de sécurité dans le flux de travail de l’agent. Quelqu’un doit décider si une dépendance est authentique, si sa version est acceptable et si ses scripts d’installation doivent être exécutés.

Les gestionnaires de packages exécutent régulièrement du code pendant l’installation. Un package npm peut définir des scripts de cycle de vie, tandis qu’un package Python peut exécuter un comportement lié à l’installation via son processus de build. Le comportement exact varie, mais l’installation ne se résume pas au téléchargement de texte inerte.

L’exemple de Clerk montre pourquoi cela compte. Les chercheurs ont découvert qu’un fichier d’instructions sur le site web légitime de Clerk référençait npx clerk-next-fix-auth-protection. L’utilitaire npx peut télécharger un package et exécuter sa commande exposée sans l’ajouter de manière permanente au manifeste d’un projet.

Selon l’enquête de sécurité, quelqu’un avait revendiqué ce nom de package et l’avait utilisé pour diffuser un malware actif. Clerk a ensuite corrigé la documentation.

On ignore toujours si ce package a provoqué des infections par l’intermédiaire d’un agent IA. Le reportage indique également qu’un binaire existant du plugin ESLint légitime de Clerk était sûr. Une machine dépourvue de ce binaire légitime pouvait à la place récupérer le package contrôlé par l’attaquant.

La différence est suffisamment subtile pour échapper à une vérification hâtive. Les deux chemins commencent par une commande publiée par le véritable fournisseur. Les deux utilisent l’infrastructure npm. Le chemin dangereux dépend du fait que le binaire attendu existe déjà ou non localement.

C’est le compromis pratique auquel font face les entreprises. Les agents apportent davantage de valeur lorsqu’ils peuvent résoudre les dépendances, exécuter des tests et corriger les échecs sans attendre une approbation après chaque commande. Ces mêmes autorisations permettent à une décision de confiance erronée de se transformer en exécution de code.

Le fournisseur du modèle peut réduire ce risque grâce au sandboxing et aux approbations. L’entreprise doit toujours configurer ces contrôles, maintenir les politiques réseau et décider des sources de packages auxquelles un agent peut accéder.

Le fournisseur de logiciels possède une autre part du problème. Sa documentation est devenue un actif opérationnel plutôt qu’un contenu marketing statique. Les références de paquets, les domaines d’exemple, les commandes copiées et les pages de configuration archivées exigent désormais la même gestion du cycle de vie que le code exécutable.

Les opérateurs de registres influencent également le résultat. La réservation d’espaces de noms, la vérification des éditeurs, l’analyse des paquets suspects et l’historique de propriété peuvent aider. Cependant, les registres ne peuvent pas toujours savoir qu’un nom non revendiqué apparaît dans la documentation d’un tiers.

Cette répartition des responsabilités rend les accusations simplistes peu utiles. Le récit Anthropic Google est important parce qu’il traverse les frontières entre produits. Un outil de recherche ou de documentation peut rendre des instructions plus faciles à trouver, un agent IA peut les interpréter, et un registre peut fournir l’artefact désigné.

La sécurité échoue lorsque chaque participant suppose qu’un autre a vérifié la propriété.

Les protections existantes des agents n’éliminent pas le risque

Claude et Codex proposent déjà des contrôles significatifs, mais ils ne fonctionnent que lorsque les organisations préservent leurs limites restrictives.

Les recommandations de sécurité de Claude d’Anthropic décrivent l’injection de prompt comme un texte hostile cherchant à manipuler les instructions d’un assistant. Elles documentent également les contrôles d’autorisation et les restrictions applicables aux commandes qui récupèrent du contenu web arbitraire.

Claude Code peut utiliser le sandboxing pour limiter l’accès au système de fichiers et au réseau. Les processus enfants héritent de ces restrictions du système d’exploitation, ce qui contribue à empêcher qu’une commande autorisée ne s’échappe discrètement vers un processus moins restreint.

OpenAI décrit une approche similaire en couches. Son modèle de sécurité Codex combine des limites de sandbox, des politiques d’approbation, un accès réseau géré, des règles et une télémétrie adaptée aux agents.

OpenAI indique que ses déploiements gérés ne donnent pas à Codex un accès sortant illimité. Les destinations attendues peuvent être autorisées, les domaines inconnus peuvent nécessiter une approbation, et les équipes de sécurité peuvent exporter des journaux couvrant les prompts, les appels d’outils, les approbations et les décisions réseau.

Ces protections comptent, mais elles n’invalident pas automatiquement les conclusions des chercheurs. Les organisations peuvent configurer les agents avec un accès plus large. Les développeurs peuvent approuver des commandes. Les installations locales peuvent hériter des autorisations et de la connectivité réseau de l’utilisateur qui les exécute.

Un registre de paquets est également une destination attendue dans de nombreux environnements de développement. Bloquer tout accès à npm ou PyPI perturberait les builds ordinaires, les mises à jour de dépendances et la configuration des tests. Autoriser ces domaines supprime un signal réseau évident qui pourrait distinguer une installation malveillante.

Les logiciels de détection et de réponse sur les terminaux rencontrent un défi similaire. Un agent de programmation démarre un gestionnaire de paquets standard, qui contacte un registre bien connu via une connexion chiffrée. Le processus peut ressembler à une activité normale de développeur jusqu’à ce que le paquet téléchargé réalise quelque chose de clairement hostile.

Le beacon de recherche était volontairement minimal. Il aurait contacté un serveur et enregistré le contexte d’exécution. Un véritable attaquant pourrait tenter de voler des identifiants, de cartographier l’environnement, d’établir une persistance ou de modifier le code source.

Cependant, les éléments publics ne montrent pas que les paquets expérimentaux ont réalisé ces actions. Ils n’établissent pas non plus que des dizaines d’entreprises ont subi une compromission en production. Elles ont exécuté du code de preuve de concept, ce qui est sérieux mais plus limité qu’une violation confirmée.

Cette distinction prudente devrait orienter la réponse des entreprises. Les équipes ne devraient pas supposer que chaque utilisation de Claude, Codex ou Hermes crée une infection. Elles devraient identifier les conditions nécessaires au fonctionnement de ce chemin d’attaque.

L’agent doit pouvoir accéder à la documentation pertinente. Il doit être autorisé à invoquer un gestionnaire de paquets. L’environnement doit permettre la récupération depuis le registre. Le paquet doit exécuter du code significatif, et les contrôles existants doivent échouer à contenir son comportement.

Supprimer l’une de ces conditions peut interrompre la chaîne. Restreindre l’accès réseau est une option. Exiger une approbation humaine pour l’installation de dépendances en est une autre. Exécuter les agents dans des conteneurs jetables peut limiter les conséquences lorsqu’un paquet s’exécute.

Les organisations peuvent également imposer un proxy interne de dépendances. Le proxy peut autoriser les paquets et versions approuvés tout en rejetant les espaces de noms inconnus. Cette approche éloigne la décision de confiance d’un agent lisant de la documentation publique.

Les invites d’approbation seules sont moins fiables lorsqu’elles ne présentent qu’une commande familière. Un examinateur a besoin de contexte sur la propriété du paquet, son ancienneté, l’identité de l’éditeur, son historique de téléchargements et la présence ou non de la dépendance dans une nomenclature logicielle approuvée.

La leçon n’est pas que les protections sont inutiles. C’est que des contrôles conçus autour de commandes manifestement malveillantes peuvent manquer des commandes légitimes qui se résolvent vers une propriété non fiable.

La documentation fait désormais partie de la chaîne d’approvisionnement logicielle

Les entreprises doivent traiter chaque référence exécutable dans la documentation comme une dépendance susceptible d’expirer, de dériver ou de changer de propriétaire.

La réponse immédiate commence par un inventaire. Les organisations devraient rechercher des commandes d’installation dans llms.txt, llms-full.txt, les portails développeurs, les guides archivés, les exemples de code, les articles d’assistance et les références d’API générées.

Chaque paquet, domaine, dépôt, image de conteneur et sous-domaine hébergé référencé doit avoir un propriétaire. Un nom que personne ne reconnaît ne devrait pas rester public pendant qu’une enquête est en cours.

Les équipes devraient vérifier que les noms publics de paquets correspondent aux comptes de registre réels de l’organisation. Elles devraient aussi examiner si des paquets à portée sont disponibles là où un nom global sans portée apparaît dans une documentation plus ancienne.

Les pipelines de documentation nécessitent des tests automatisés. Un build peut vérifier que chaque paquet existe, appartient à un éditeur approuvé, se résout vers un dépôt attendu et n’a pas changé de propriétaire.

La seule vérification des liens est insuffisante. Un paquet malveillant ou un domaine récupéré peut renvoyer une réponse réussie. Le pipeline doit valider l’identité plutôt que la disponibilité.

Les entreprises devraient réserver les noms avant de publier leur documentation. Cela ressemble à l’enregistrement de domaines défensifs autour d’un produit important, mais les espaces de noms de paquets exigent une maintenance continue.

Le même principe s’applique lorsqu’un projet est abandonné. Supprimer un paquet sans retirer ses instructions d’installation crée une lacune de propriété. Abandonner un sous-domaine d’hébergement tout en laissant des liens vers celui-ci peut permettre à une autre partie d’hériter d’un chemin de confiance.

La documentation générée par IA mérite un examen supplémentaire, mais les pages rédigées par des humains ne sont pas exemptées. Les chercheurs ont trouvé des éléments indiquant que certaines références douteuses précédaient l’ère actuelle des agents. Copier ces pages dans llms-full.txt a rendu de vieilles erreurs plus faciles à consommer pour des logiciels autonomes.

Les entreprises qui déploient des agents ont besoin d’un plan de contrôle complémentaire. Les sessions d’agents devraient s’exécuter sous des identités dédiées plutôt que sous le compte non restreint d’un développeur. Les identifiants devraient être limités au dépôt et à la tâche en cours.

L’installation de paquets devrait se produire dans un environnement isolé avec un accès limité aux secrets. Si une dépendance nécessite un accès réseau pendant l’installation, cet accès devrait être explicite et consigné.

Les équipes devraient conserver le contexte de raisonnement de l’agent parallèlement à la télémétrie du système d’exploitation. Un journal de processus peut montrer que npm a démarré, tandis que les enregistrements propres à l’agent peuvent indiquer quel document a fourni le nom du paquet.

Ce contexte compte pendant la réponse à incident. Les enquêteurs doivent distinguer une dépendance de projet approuvée d’un paquet sélectionné après qu’un agent a consulté des instructions externes.

Les listes d’autorisation de dépendances peuvent réduire le risque, mais elles nécessitent une procédure d’exception pour les nouveaux paquets. Cette exception devrait recueillir des éléments de provenance et exiger un propriétaire humain désigné.

Les organisations devraient également maintenir un registre consultable des sources que les agents consultent. Il peut inclure des instantanés de documentation, des métadonnées de paquets, des décisions d’approbation et des modifications de code générées. Une base de connaissances technique contrôlée peut aider les examinateurs à reconstituer pourquoi un agent a sélectionné une dépendance.

La leçon plus large dépasse llms.txt. Les agents de programmation consomment des descriptions d’incidents, des fichiers de dépôt, des résultats de recherche, de la documentation de paquets, des réponses du Model Context Protocol et des guides internes générés.

N’importe laquelle de ces sources peut contenir une instruction. Si l’agent dispose d’outils, l’instruction peut devenir une action.

Cela fait de l’intégrité de la documentation un élément de la sécurité de la chaîne d’approvisionnement logicielle. L’entreprise ne peut pas protéger uniquement les dépôts de code source et les serveurs de build tout en laissant hors de son contrôle les instructions lisibles par machine.

Trois signaux montreront si le secteur a retenu la leçon

La prochaine phase dépend de l’amélioration conjointe de la documentation, des autorisations d’agents et de l’identité des registres.

Le premier signal est la divulgation et la remédiation parmi les 120 sites web concernés. L’équipe de Hertz affirme avoir contacté les organisations concernées et les équipes de sécurité pertinentes, mais les archives publiques n’identifient pas la plupart des domaines.

Surveillez les entreprises qui auditent leurs fichiers llms.txt, réservent des noms de paquets et publient des avis d’incident. Un nettoyage coordonné renforcerait l’argument selon lequel la documentation lisible par machine est une infrastructure sensible du point de vue de la sécurité.

Le silence ne prouverait pas qu’aucune correction n’a été appliquée. De nombreuses organisations réparent des références exposées sans divulgation publique, en particulier lorsque les chercheurs ont utilisé du code inoffensif et n’ont constaté aucun vol de données confirmé.

Le deuxième signal est un contrôle de provenance au niveau du produit de la part des fournisseurs d’agents. Claude, Codex et Hermes peuvent déjà demander une approbation avant les commandes, mais l’approbation devient plus utile lorsque l’interface explique la dépendance qui se cache derrière la commande.

Un changement significatif avertirait qu’un paquet est nouveau, non vérifié, sans lien avec le compte d’éditeur connu du fournisseur ou absent du graphe de dépendances existant du projet. Un système plus robuste pourrait exiger une approbation explicite chaque fois que de la documentation publique pointe vers un paquet non reconnu.

Une telle fonctionnalité renforcerait la réponse de sécurité Anthropic Google car elle traiterait le point de décision avant l’exécution. Un autre avertissement générique sur les commandes shell offrirait moins de protection.

Le troisième signal est l’intégration entre les registres et les politiques d’entreprise. Les gestionnaires de paquets et les proxys internes peuvent exposer l’historique des éditeurs, l’âge des espaces de noms, le statut de signature et les changements de propriété. Les plateformes d’agents peuvent utiliser ces métadonnées avant de sélectionner ou d’installer une dépendance.

Une politique d’entreprise pourrait autoriser automatiquement les paquets établis tout en isolant les paquets inconnus pour examen. Elle pourrait aussi rejeter un paquet dont le nom apparaît dans une documentation officielle mais qui n’a aucun lien vérifiable avec l’éditeur.

Ce signal affaiblirait l’avertissement plus large des chercheurs si des contrôles de provenance fiables arrêtent le chemin d’attaque sur plusieurs agents. Il renforcerait leur avertissement si les agents continuent d’installer des noms nouvellement revendiqués malgré des données d’identité disponibles.

Les éléments actuels soutiennent une conclusion mesurée. Les chercheurs auraient démontré l’exécution de code dans de véritables environnements d’entreprise et relié une partie de l’activité à des agents de programmation importants. Ils n’ont pas démontré que les fournisseurs de modèles ont intentionnellement installé des malwares ni que chaque rappel signalé représentait une compromission grave.

La conclusion la plus importante est structurelle. La documentation de confiance, l’exécution autonome et les registres publics forment désormais une chaîne d’approvisionnement que de nombreux programmes de sécurité ne recensent pas.

Les développeurs et les acheteurs d’entreprise devraient poser des questions directes avant d’étendre les autorisations des agents. L’agent peut-il accéder à des registres publics de paquets ? Vérifie-t-il l’identité de l’éditeur ? Les commandes d’installation sont-elles isolées ? Les équipes de sécurité peuvent-elles reconstituer quel document a déclenché une action ?

La faille de sécurité Anthropic–Google ne se comblera pas uniquement grâce à un meilleur comportement des modèles. Les responsables de la documentation, les registres, les fournisseurs d’agents et les administrateurs d’entreprise contrôlent chacun un maillon différent.

Avant d’accorder davantage d’autonomie à un agent de programmation, testez l’ensemble de cette chaîne avec une dépendance non reconnue. Si l’agent l’installe sans en présenter la provenance, l’environnement traite la documentation comme une autorité plutôt que comme une preuve.