Un agent chargé de corriger une API peut lire le dépôt, installer des dépendances, lancer les tests et ouvrir une pull request. Sur un poste de développeur, ces opérations peuvent aussi lui donner accès à une clé SSH, à un registre privé ou à un cluster Kubernetes. Avant de généraliser l’agentic coding en entreprise, il faut donc déterminer avec quelle identité les commandes s’exécutent, quels fichiers elles peuvent lire et quels services elles peuvent joindre.
Ces choix se jouent dans l’environnement d’exécution, les permissions des outils et la chaîne CI/CD. Un fichier AGENTS.md aide l’agent à travailler dans le projet. Il ne suffit pas à protéger le poste ni la production. Voici une architecture de départ pour une équipe qui veut laisser ses agents développer et tester, tout en gardant la maîtrise de la livraison.
Ce que montre réellement l’incident du dossier Téléchargements
Dans un rapport publié le 22 octobre 2026, Forever Security décrit une tentative d’installation du paquet malveillant function-color par un agent. Un fichier d’instructions placé dans le dossier Téléchargements présentait cette installation comme une étape de configuration. Chez le client observé, la tentative a été bloquée avant exécution. L’origine du fichier reste inconnue.
Les chercheurs ont ensuite reproduit la chaîne dans leur laboratoire. Les taux de réussite publiés concernent ces essais, avec leurs versions et leurs permissions, et ne mesurent pas la proportion de postes compromis. La plupart des reproductions Codex utilisaient une action inoffensive ; le véritable paquet malveillant a été exécuté une fois dans une machine virtuelle isolée.
Le mécanisme mérite l’attention : un contenu lu par l’agent devient, à tort, une consigne pour ses outils. C’est une injection de prompt indirecte. Un README, une issue ou une sortie d’outil peuvent tenter la même confusion. La protection doit continuer à fonctionner lorsque le modèle suit une mauvaise instruction.
Instructions, permissions et sandbox : trois fonctions distinctes
Les instructions du projet décrivent les conventions, les commandes de test et l’architecture. Leur chargement dépend du client. Codex assemble notamment les fichiers d’instructions rencontrés entre la racine du projet et le répertoire courant. Claude Code possède ses propres règles de découverte et de priorité. Il faut vérifier les fichiers effectivement chargés, plutôt que supposer qu’un même AGENTS.md produit partout le même comportement. Les documentations Codex et Claude Code détaillent ces règles.
Les permissions décident ensuite si un outil peut agir, doit demander une validation ou doit refuser. La sandbox applique des restrictions techniques aux processus : fichiers accessibles, écritures autorisées et connexions réseau. Codex distingue explicitement ces deux contrôles dans sa documentation sur les approbations. Une demande approuvée peut élargir le périmètre ; la politique d’entreprise doit donc aussi encadrer les possibilités d’élévation.
Cette distinction évite une erreur fréquente : interdire la lecture d’un .env dans un outil ne bloque pas forcément sa lecture par Python ou Node.js. Les permissions de Claude Code le précisent. Pour protéger un secret, le processus ne doit pas pouvoir accéder au fichier qui le contient. Une consigne « ne lis pas ce fichier » ne crée pas cette restriction.
Isoler l’exécution : un worktree ne suffit pas
Un worktree Git donne à chaque tâche son propre répertoire de travail, généralement associé à une branche distincte. C’est utile pour paralléliser les modifications, comparer les résultats et abandonner un correctif. Les worktrees partagent toutefois des éléments du dépôt, dont la configuration par défaut. Ils ne créent aucune séparation des processus, des identités ou du réseau. Supprimer une branche n’annule pas un appel API déjà exécuté. La documentation Git décrit ce qui est partagé.
Ce qu’un conteneur apporte, et ce qu’il faut configurer
Pour une première architecture, on peut placer une copie de travail du dépôt dans un conteneur dédié, lancé sans privilèges, avec un utilisateur non root, des ressources limitées et uniquement les volumes nécessaires. Les namespaces séparent certaines vues du système ; les cgroups limitent notamment CPU et mémoire ; seccomp réduit les appels système disponibles. Ces mécanismes se complètent. Aucun ne compense un montage du répertoire personnel ou du socket Docker de l’hôte. Voir les mécanismes de sécurité Docker.
Un devcontainer doit être revu comme une configuration d’exécution : image de base, volumes, options de lancement et commandes de préparation. Une définition fournie par un dépôt peut démarrer du code dès l’initialisation : initializeCommand s’exécute même sur l’hôte. La spécification Dev Container décrit ces commandes de cycle de vie. Pour des dépôts externes, mieux vaut partir d’une image approuvée et traiter les personnalisations comme des changements à examiner.
Lorsque le code est moins fiable ou que plusieurs équipes partagent l’infrastructure, une isolation supplémentaire peut se justifier. gVisor interpose un noyau applicatif pour réduire les interactions directes avec le noyau hôte. Firecracker utilise des microVM fondées sur KVM, avec un hôte maintenu et le dispositif d’isolation jailer, ou des restrictions au moins équivalentes. Ces choix demandent des tests de compatibilité, de démarrage et de performance. Ils ne retirent pas les droits d’une clé cloud que l’on injecte ensuite dans l’environnement.
Vérifier tout le chemin réseau
Le filtrage doit couvrir l’exécution réelle. La sandbox de Claude Code encadre les commandes shell et leurs processus enfants ; les serveurs MCP, les hooks et certains outils suivent d’autres contrôles. Bloquer Internet pour le shell ne suffit donc pas à affirmer que l’agent entier est hors ligne.
Dans l’architecture proposée ici, les installations passent par un miroir de paquets approuvé et les appels au modèle par une passerelle dédiée. Les autres sorties sont refusées par défaut, avec des exceptions limitées au besoin de la tâche. Il faut tester aussi les accès au réseau interne et aux services de métadonnées cloud. Le contrôle doit être appliqué hors de portée du code exécuté. Autoriser un domaine ne garantit pas que toutes les données envoyées vers ce domaine sont légitimes.
Séparer les identités de l’agent, de la CI et du déploiement
Le poste du développeur réunit souvent des accès qui n’ont aucune utilité pour corriger un test : agent SSH, configuration Kubernetes, session Azure, identifiants de registre. Les recopier dans l’environnement de l’agent étend inutilement ses possibilités. Un secret stocké dans un coffre redevient accessible au processus dès qu’il est injecté dans ses variables d’environnement.
Pour un appel métier, un service intermédiaire peut conserver le secret et exposer une opération précise : lire les logs d’un environnement de test, par exemple. Il doit contrôler l’utilisateur, la ressource et les paramètres à chaque appel. La documentation de sécurité des environnements Agents API décrit cette séparation entre l’exécution du code et les composants qui détiennent les identifiants.
La répartition suivante est une proposition d’architecture, à adapter aux dépôts et aux données de l’équipe :
| Étape | Accès accordés | Condition de passage |
|---|---|---|
| Agent de développement | Copie du dépôt isolée, données de test, outils nécessaires à la tâche | Diff et résultats de tests disponibles pour revue |
| Soumission de la PR | Identité limitée au dépôt ; branche principale protégée | Aucun droit de contourner les validations |
| CI de vérification | Environnement propre, identité distincte, sans droit de déploiement production | Contrôles exécutés sur la révision examinée |
| Construction de livraison | Sources acceptées et registre d’artefacts autorisé | Artefact relié au commit et identifié par son empreinte |
| Déploiement | Identité temporaire limitée à l’application et à l’environnement | Approbation indépendante et déploiement de l’artefact validé |
Le compte qui propose le code ne doit pas pouvoir supprimer les contrôles qui l’évaluent. Cette séparation doit résister à une modification du pipeline dans la PR. Azure Pipelines permet notamment d’attacher des approbations et des checks aux ressources, en dehors du YAML que l’auteur du pipeline peut modifier.
Pour le déploiement, la fédération OIDC évite de conserver une clé cloud permanente dans la CI. Le fournisseur vérifie l’identité et les attributs du job avant de délivrer un accès temporaire. Il faut limiter cette relation de confiance au dépôt, à l’environnement et au contexte de livraison attendus. Un jeton court reste exploitable par le code qui le reçoit pendant sa validité. Voir le fonctionnement OIDC dans GitHub Actions.
Skills et MCP font partie des dépendances à maîtriser
Un skill peut fournir des instructions, des ressources et des scripts. Le fichier SKILL.md n’est pas, à lui seul, un exécutable ; il peut néanmoins conduire l’agent à lancer du code. La revue doit couvrir l’ensemble du paquet, ses dépendances et les accès attendus. La spécification Agent Skills permet d’en identifier les composants.
Un serveur MCP ajoute une autre surface. En transport stdio, c’est un processus local : ses possibilités dépendent du compte, des fichiers et du réseau auxquels il a accès. Pour un serveur distant, il faut examiner l’authentification, les autorisations et les données transmises. L’annotation readOnlyHint décrit l’intention déclarée d’un outil ; elle ne vérifie ni son implémentation ni l’absence de fuite. Les annotations MCP doivent être traitées comme non fiables lorsque le serveur ne l’est pas.
Une équipe peut tenir un catalogue limité : propriétaire identifié, version ou commit fixé, empreinte du paquet, permissions et procédure de mise à jour. Un changement de script, de dépendance ou de schéma d’outil déclenche une nouvelle revue. Une signature permet de vérifier l’intégrité de l’artefact et l’identité du signataire, à condition de reconnaître sa clé. Elle ne prouve pas que son comportement convient au projet.
SkillSpector, publié par NVIDIA, peut compléter cette revue avec une analyse statique, une analyse sémantique optionnelle et des résultats SARIF exploitables dans la CI. Son score sert à prioriser les alertes. Un score faible n’est pas une certification, et les conditions de blocage doivent être configurées explicitement.
La CI réexécute du code qui n’est pas encore approuvé
Un agent peut produire une modification applicative raisonnable et un script de test dangereux. Au lancement de la CI, ce script s’exécute avec les accès du runner. La sandbox utilisée pendant le développement ne protège plus cette seconde exécution. Les fichiers de workflow, les scripts de build et les lockfiles doivent donc faire partie de la revue.
Un lockfile ne neutralise pas les scripts d’installation
Dans un projet Node.js, npm ci exige un lockfile cohérent et ne le réécrit pas. Il peut toutefois exécuter des scripts d’installation. L’option --ignore-scripts les désactive, avec un risque de casser certains paquets qui en dépendent. Un npm test lancé explicitement exécute toujours le script de test : celui-ci doit rester isolé. Ces comportements sont documentés dans la référence npm.
La politique utile consiste à fixer la version du gestionnaire, examiner les changements de dépendances et autoriser les scripts nécessaires après revue. Il faut aussi séparer les caches selon leur niveau de confiance : un job exécutant une contribution non approuvée ne devrait pas pouvoir fournir librement des fichiers réutilisés ensuite par une construction privilégiée.
Le déclencheur du pipeline change les accès disponibles
Sur GitHub, une PR venant d’un fork et exécutée avec pull_request dispose normalement d’un token en lecture seule et ne reçoit pas les autres secrets. pull_request_target s’exécute dans le contexte du dépôt de base : y récupérer puis exécuter le code proposé peut exposer ce contexte privilégié. GitHub détaille ce piège dans sa documentation dédiée. Les PR provenant de branches internes doivent aussi être examinées ; elles ne bénéficient pas nécessairement des restrictions appliquées aux forks.
Sur GitLab, lancer dans le projet parent un pipeline de merge request venant d’un fork peut utiliser la configuration du fork avec les ressources et variables du parent. Les variables protégées obéissent à des conditions supplémentaires. Un lancement manuel ne rend donc pas le contenu fiable. Voir les pipelines de merge request GitLab.
Enfin, « runner éphémère » doit signifier un environnement d’exécution réellement propre. Désenregistrer un runner après un job ne nettoie pas automatiquement le disque, les processus ou les caches d’un hôte réutilisé. Les recommandations GitHub sur les runners auto-hébergés insistent sur cette persistance possible.
Faire relire la modification et ses preuves
Un deuxième agent peut chercher des oublis avec un contexte séparé : spécification, diff, interfaces touchées et résultats de tests. Le projet Elephant-Goldfish propose notamment une revue de spécification sans transmettre toute la conversation initiale. Cette méthode aide à révéler des hypothèses implicites. Elle ne rend pas la revue indépendante des erreurs du modèle ou du document fourni.
Pour une modification d’authentification, une relecture utile vérifie les refus d’accès, l’expiration des sessions et les droits des différents rôles. Pour une migration SQL, elle examine le verrouillage, la compatibilité avec la version précédente et la reprise après échec. Il faut demander ces preuves dès la définition de la tâche. Le nombre de fichiers modifiés ou de tests ajoutés renseigne peu sur ces risques.
La branche principale doit exiger les contrôles pertinents et une revue des zones sensibles, dont la configuration des agents et de la CI. Si le contenu change après validation, l’approbation doit être réévaluée. GitHub permet aussi de fixer l’intégration autorisée à produire un check. Attention : un statut skipped ou neutral peut satisfaire certaines règles de checks requis. Il faut s’assurer que le contrôle attendu a effectivement tourné. Voir les règles de protection des branches.
Tester les restrictions avant d’élargir l’autonomie
Un pilote peut commencer sur un dépôt et un environnement de test, avec trois vérifications reproductibles. Utilisez des fichiers et des comptes factices : ces essais servent à mesurer les restrictions, pas à exposer de vrais secrets.
- Fichiers : placer un faux secret hors du périmètre autorisé et vérifier que sa lecture échoue depuis les outils de fichiers comme depuis un programme lancé par l’agent.
- Réseau : vérifier qu’une destination non autorisée est bloquée depuis le shell et depuis chaque composant disposant de son propre accès, notamment les serveurs MCP.
- Livraison : soumettre une PR de test qui tente d’éviter un contrôle ou d’atteindre l’environnement de production. Les protections du dépôt et du déploiement doivent refuser l’opération sans dépendre du jugement de l’agent.
Pour comprendre un incident, conservez l’identifiant de tâche, le commit de départ, la version du client, les outils et skills chargés, les décisions d’autorisation, les commandes exécutées et les destinations réseau. Reliez ces traces à la PR et à l’artefact livré. Les journaux eux-mêmes doivent avoir des accès et une rétention maîtrisés ; recopier systématiquement les prompts et les sorties peut y accumuler du code et des données sensibles.
En cas d’action suspecte, la procédure doit permettre d’arrêter la tâche, de révoquer ses accès et de conserver les traces avant de détruire l’environnement. Effacer le worktree ne suffit pas si un identifiant a été utilisé ailleurs.
L’agent peut gagner progressivement de l’autonomie à mesure que l’équipe vérifie ses restrictions et la qualité de ses modifications sur des tâches représentatives. Commencez par lui permettre de produire une PR vérifiable, avec un environnement de travail reproductible et une CI sans accès production. Les droits supplémentaires doivent répondre à un besoin identifié et être testés avec la même précision que le code livré.
Pour prolonger le sujet : notre article sur le harness engineering et l’environnement des agents, ainsi que celui sur la sécurité des modèles auto-hébergés.
Sources vérifiées le 28 octobre 2026. Les comportements des clients et les options de sécurité dépendent de leur version et de leur configuration.
