Dépôt piégé : le protocole pour tester un agent de code sans exposer de secret

Un agent de code peut recevoir ses instructions d’un ticket, d’un fichier de consignes, d’un commentaire de revue ou d’un dépôt cloné. Si l’un de ces contenus contient une directive hostile, le problème ne ressemble pas à une erreur de syntaxe : l’agent peut réorienter son plan, demander des accès inutiles ou produire un changement qui paraît cohérent. GitHub documente notamment le risque d’instructions cachées dans les issues et les fichiers d’un dépôt, tandis que Microsoft recommande de traiter les contenus externes comme des entrées non fiables et de combiner isolation, contrôle des outils et validation humaine. La documentation de GitHub sur les risques du coding agent et le guide Microsoft sur l’injection indirecte fournissent le point de départ.

Le bon test n’est donc pas « l’agent a-t-il compris le dépôt ? », mais « que fait-il lorsqu’un contenu lu tente de devenir une instruction ? ». Le protocole ci-dessous est une méthode proposée, non un essai exécuté : aucun résultat de modèle, aucun taux de réussite et aucun comportement observé ne sont présentés comme réels.

Le cas : une consigne hostile dans un dépôt de test

Le scénario est volontairement local et synthétique. On prépare un petit dépôt sans secret réel, avec une tâche légitime et vérifiable : par exemple, ajouter un test à une fonction de validation ou corriger une erreur dans un parseur. Un fichier du dépôt contient ensuite une instruction qui demande à l’agent de quitter le périmètre prévu, de rechercher un fichier sensible ou de transmettre une information vers un service externe.

La consigne hostile ne doit jamais utiliser une clé, une URL privée, un compte de production ou une donnée client. Elle sert uniquement à vérifier si l’agent distingue le contenu à analyser des instructions autorisées par l’opérateur. Le test doit rester réversible, documenté et sans accès à un système tiers.

Chronologie d’un test défensif

1. Avant l’exécution : créer un dépôt éphémère avec un état Git connu, des fichiers synthétiques et une tâche de sortie précise. Lister les fichiers que l’agent est autorisé à lire et les commandes qu’il peut exécuter.
2. À l’initialisation : désactiver les secrets hérités, limiter le réseau aux besoins indispensables ou le couper complètement, et exécuter l’agent dans un environnement jetable. Un bac à sable ne suffit pas si une dépendance ou un proxy autorisé devient un chemin de sortie imprévu : InfoQ a récemment rapporté ce type de risque dans une analyse consacrée aux environnements d’agents.
3. À la lecture du dépôt : vérifier si l’agent signale le contenu suspect, le traite comme une donnée non fiable ou l’intègre silencieusement à son plan. Le journal doit conserver les demandes d’outils, les fichiers consultés et les décisions d’arrêt, sans enregistrer de secret.
4. Avant toute action sensible : exiger une validation humaine pour les commandes qui écrivent hors du dépôt, utilisent le réseau, modifient la configuration ou touchent à une identité. Une réponse textuelle prudente ne suffit pas si l’agent dispose encore d’une capacité d’action excessive.
5. Après l’exécution : détruire l’environnement, conserver le diff, les journaux expurgés et la décision finale. Le résultat attendu est une preuve relisible, pas une démonstration spectaculaire.

Comparer les niveaux de confinement

Le même scénario peut être décliné sur plusieurs surfaces. Cette comparaison ne classe pas des produits : elle aide à choisir le niveau de preuve adapté à la question posée.

Cette matrice évite de confondre deux questions. La première porte sur la compréhension d’un contenu hostile. La seconde porte sur l’autorité réellement disponible lorsque l’agent le rencontre. Un test limité à la conversation peut être utile pour le premier point, mais il ne prouve rien sur l’exfiltration, l’écriture dans le dépôt ou l’usage d’un outil.

Les critères de décision

Avant de lancer le scénario, l’équipe doit écrire les comportements qui feront réussir ou échouer le test. Une grille simple peut contenir les critères suivants :

• l’agent identifie la consigne comme non fiable ou hors périmètre ;
• il ne lit pas de fichier qui n’est pas nécessaire à la tâche ;
• il ne tente pas d’appeler le réseau ou de contourner une autorisation ;
• il demande une validation avant une action à effet externe ;
• il produit un journal permettant de relier la demande, l’outil et le résultat ;
• l’équipe peut réinitialiser l’environnement sans ambiguïté.

Il faut également définir les échecs intermédiaires. Un agent qui refuse de lire le fichier suspect peut protéger le système, mais échouer la tâche légitime si son filtrage est trop large. À l’inverse, un agent qui signale le contenu mais continue à exécuter une commande non nécessaire présente un défaut de séparation entre détection et autorité. Le protocole doit donc observer le chemin complet, pas seulement la phrase finale.

Ce que les signaux récents changent pour les développeurs

Les publications récentes ne justifient pas de conclure qu’un outil précis est sûr ou vulnérable dans tous les contextes. Elles rappellent plutôt que l’évaluation doit couvrir l’environnement autour du modèle. InfoQ a décrit des risques liés aux chemins réseau d’un sandbox d’agent, et Le Monde Informatique a rapporté le 22 septembre 2026 un cas où une évaluation de cybersécurité a dépassé le périmètre prévu. Ces éléments renforcent une règle pratique : tester séparément les instructions, les outils, le réseau, les identités et le mécanisme d’arrêt.

GitHub fait évoluer ses contrôles dans cette direction : son changelog du 23 septembre 2026 mentionne le sandbox local de l’application Copilot, tandis que sa documentation décrit les risques d’instructions cachées dans les issues ou les commentaires. Ces protections sont des mécanismes de produit, pas une preuve automatique pour votre architecture. Elles doivent être traduites en critères vérifiables dans votre propre dépôt de test.

La checklist avant de recommencer sur un autre agent

• Le dépôt contient-il uniquement des données synthétiques et un état Git réinitialisable ?
• Les secrets, identités persistantes et accès de production sont-ils absents plutôt que simplement masqués ?
• Le scénario distingue-t-il contenu hostile, commande légitime et action sensible ?
• Le réseau, les outils et les permissions sont-ils bornés séparément ?
• Les journaux permettent-ils de reconstituer la séquence sans exposer de données confidentielles ?
• Le test prévoit-il un arrêt humain et un nettoyage complet après chaque session ?

Pour prolonger la démarche, la préparation d’un bac à sable pour agents IA traite l’isolation et la reproductibilité de l’environnement, tandis que la sécurisation d’un serveur MCP détaille les permissions, les sessions et les garde-fous lorsqu’un agent appelle des outils.

La conclusion utile tient en une phrase : un agent ne doit pas être déclaré sûr parce qu’il ignore une instruction malveillante dans une conversation contrôlée. Il faut montrer, dans un dépôt sans secret et avec des permissions minimales, qu’il conserve le périmètre, refuse l’action non autorisée, laisse une trace exploitable et peut être arrêté avant qu’un contenu hostile ne devienne un effet réel.