Comment exécuter plusieurs agents de codage IA en toute sécurité avec des arbres de travail Git et des autorisations isolées

Attribuez à chaque agent de programmation sa propre branche et son propre répertoire de travail, puis restreignez séparément l’accès du processus aux fichiers, aux identifiants et au réseau. Les worktrees Git réduisent les interférences accidentelles entre les modifications, mais ne constituent pas des environnements de sécurité isolés. Un flux de travail parallèle sûr nécessite à la fois un état du dépôt facile à comprendre et des permissions d’exécution effectivement appliquées.

Ce guide présente les commandes locales pour les worktrees, l’accès limité à chaque tâche, la configuration indépendante des tests et une séquence d’intégration soumise à une revue humaine. Utilisez un dépôt qui vous appartient ou que vous êtes autorisé à modifier, et commencez par des tâches sans risque. La procédure est indépendante des outils : une interface d’agent de programmation peut en automatiser certaines étapes, mais les limites sous-jacentes doivent toujours être vérifiées.

Que se passe-t-il lorsque des agents partagent un espace de travail ?

Deux agents peuvent écraser des modifications non validées, modifier le même fichier de dépendances ou prendre l’état temporaire d’une autre tâche pour la conception prévue du projet. Ils peuvent aussi lancer des tests dans un répertoire dont le contenu change pendant leur exécution. L’échec qui en résulte peut être difficile à reproduire, car aucun des deux agents n’a testé une révision stable.

Le problème ne se limite pas aux fichiers source. Les ports, noms de bases de données, caches, répertoires de données de test et processus en arrière-plan partagés peuvent créer des interférences, même lorsque les différences touchent des modules distincts. Un agent peut arrêter un service utilisé par un autre, ou régénérer des fichiers à partir d’un schéma en cours de modification.

Notre explication de la coordination multi-agent décrit comment la délimitation des tâches et leurs dépendances réduisent ces interférences. Avant de créer davantage d’agents, consignez pour chaque tâche le résultat attendu, la zone de modification autorisée, les dépendances et les tests d’acceptation. « Travailler ensemble sur la même fonctionnalité » ne constitue pas un contrat suffisant pour permettre des modifications indépendantes.

Un répertoire distinct réduit les risques d’interférences accidentelles ; un contexte de sécurité distinct contrôle les ressources auxquelles le processus peut accéder. Gardez ces objectifs séparés afin de ne pas confondre séparation réussie des branches et protection des fichiers privés ou des services de production.

Quand utiliser des worktrees plutôt que des clones séparés ?

Les worktrees Git sont utiles lorsque plusieurs branches d’un même dépôt doivent disposer simultanément de répertoires de travail. Des clones séparés peuvent être préférables lorsqu’une expérimentation nécessite une configuration du dépôt plus indépendante ou un autre paramétrage du dépôt distant. Aucune de ces options ne limite à elle seule l’accès de l’utilisateur du système d’exploitation aux secrets ou aux autres répertoires.

Choisissez en fonction du flux de travail réel. Les worktrees peuvent faciliter les revues par branche, tandis que des clones séparés peuvent aider à contenir certaines expérimentations destructrices au niveau du dépôt. Pour du code non fiable ou des risques d’exécution plus larges, utilisez un environnement d’exécution suffisamment isolé, quelle que soit la manière dont le code source a été récupéré.

Ce tableau sert d’aide à la planification, et non de certification de sécurité. Testez la frontière sur laquelle vous comptez vous appuyer, y compris les fichiers et services visibles depuis le shell réellement utilisé par l’agent.

Couverture : logotype officiel de la marque Conductor issu du kit de marque, utilisé sans modification à des fins d’identification éditoriale. Les marques des produits restent la propriété de leurs détenteurs ; aucune affiliation n’est sous-entendue.

Comment créer une branche et un arbre de travail par agent ?

Partez d’une base connue et approuvée. Enregistrez le travail existant avant de changer de branche et inspectez le répertoire de travail au lieu de supposer qu’il est propre. L’exemple suivant suppose un dépôt local dont la base approuvée est main ; utilisez la base appropriée à votre projet. Ne copiez pas une commande avec un nom de branche erroné en essayant ensuite de la faire fonctionner à tout prix.

git status --short
git branch --show-current
git worktree list
git switch main
git worktree add -b agent/docs ../agent-docs main
git worktree add -b agent/tests ../agent-tests main
git worktree list

Attribuez à chaque agent le chemin de son propre arbre de travail et une tâche bien délimitée. Notez le commit de base et précisez quels fichiers partagés nécessitent une coordination. Ne copiez pas tout l’environnement de développement personnel dans chaque répertoire par commodité ; cela pourrait dupliquer des identifiants et des éléments privés sans rapport avec la tâche.

Suivez cette séquence de bout en bout :

1. Vérifiez que l’état du dépôt est propre ou préservé en toute sécurité, puis choisissez la base approuvée.
2. Créez une branche et un arbre de travail uniques pour chaque tâche.
3. Fournissez uniquement le contexte nécessaire à la tâche et définissez clairement les critères d’achèvement.
4. Configurez des identifiants dédiés et à portée limitée uniquement si la tâche l’exige.
5. Attribuez aux tests des chemins temporaires, des ports et des états de service jetables distincts.
6. Inspectez chaque diff et résultat de test avant de proposer l’intégration.
7. Effectuez la fusion en suivant le processus de revue humaine et les contrôles du dépôt.
8. Conservez les éléments de preuve nécessaires, supprimez normalement les arbres de travail une fois le travail terminé et révoquez les accès temporaires.

Ces commandes créent l’état du dépôt ; elles ne configurent pas le bac à sable. Si un outil d’agent dispose de son propre gestionnaire d’espaces de travail, examinez les branches et les chemins obtenus afin que le même contrat reste compréhensible en dehors de l’interface.

Comment isoler les clés, les fichiers d’environnement et les jetons ?

Un arbre de travail ne doit pas hériter de l’ensemble des identifiants d’un développeur. Préférez une identité dédiée, limitée aux autorisations sur le dépôt et les services nécessaires à la tâche. Conservez les secrets dans un espace de stockage approuvé et transmettez-les par le mécanisme pris en charge par l’outil, et non dans une invite, un fichier de tâche ou un fichier .env versionné.

La documentation des jetons de GitHub explique les autorisations et le cycle de vie des jetons. Choisissez le périmètre pratique le plus restreint, une durée d’expiration adaptée et un moyen de les révoquer. Un jeton nécessaire pour lire le code source n’implique pas l’autorisation de modifier les fichiers de workflow, de fusionner des demandes de fusion ou d’administrer un dépôt.

Les variables d’environnement sont un moyen de transmettre des informations, pas une frontière d’isolation complète. Un processus enfant peut en hériter, et une commande de débogage ou un journal peut les exposer. Vérifiez quelles variables sont transmises à chaque processus de travail et évitez de partager des valeurs de production avec les tests. Utilisez des identifiants fictifs pour les services qui peuvent être simulés.

Les recommandations de l’OWASP sur la gestion des secrets fournissent des informations sur le contrôle des accès et la rotation des secrets. Si un agent lit un secret dont il n’avait pas besoin, considérez cela comme un problème de configuration, même si aucune divulgation n’est constatée. L’environnement doit rendre les accès inutiles impossibles ou les restreindre délibérément, plutôt que de compter sur le modèle pour ne pas s’y intéresser.

Comment les conteneurs ou les bacs à sable peuvent-ils limiter l’accès ?

Examinez la configuration réelle : identité de l’utilisateur, chemins montés, politique réseau, privilèges, sockets et identifiants disponibles. Un conteneur auquel sont montés le répertoire personnel de l’hôte et le socket du moteur de conteneurs peut avoir accès à bien plus que son dossier de travail. L’étiquette « bac à sable » ne prouve pas que l’accès à ces ressources est restreint.

L’aperçu de la sécurité de Docker présente les principaux points à prendre en compte lors de l’exécution. Utilisez les contrôles pris en charge par la plateforme pour réduire les privilèges, ne monter que les données nécessaires et séparer l’état des services. Vérifiez si le processus de travail peut accéder à des emplacements qui devraient être hors de son périmètre. Un refus d’accès réussi indique utilement qu’un contrôle est actif.

L’accès réseau doit être défini en fonction de la tâche. Une tâche peut nécessiter un registre de paquets et un hébergeur de dépôts sans avoir besoin d’accéder à des destinations sortantes arbitraires ou à des bases de données de production. Appliquez les contrôles à un niveau où ils peuvent être imposés et documentez les exceptions. Ne désactivez pas la vérification des certificats pour faire fonctionner l’installation des dépendances ; résolvez le véritable problème de confiance ou de connectivité.

La documentation de Docker sans privilèges décrit une option permettant de réduire les privilèges du démon et des conteneurs. Cela ne rend pas toutes les charges de travail inoffensives et ne dispense pas d’examiner les montages et les secrets. Choisissez un niveau d’isolation adapté au code exécuté et à la valeur de l’environnement hôte.

Comment faut-il réviser et fusionner les modifications ?

Examinez aussi bien le travail non validé que les commits. Un agent peut annoncer qu’une tâche est terminée alors que des fichiers pertinents ne figurent pas dans son commit ou qu’il a testé un répertoire de travail différent de la branche proposée. Demandez-lui de préciser le résultat réel, puis inspectez-le vous-même.

git -C ../agent-docs status --short
git -C ../agent-tests status --short
git diff --stat main...agent/docs
git diff main...agent/docs
git diff --stat main...agent/tests
git diff main...agent/tests

Exécutez les vérifications pertinentes du projet dans chaque répertoire de travail, puis à nouveau sur la révision intégrée lorsque les interactions le justifient. Examinez les contrats partagés, les fichiers générés et les mises à jour des dépendances. Si la branche de base change pendant la révision, déterminez quels éléments de preuve sont obsolètes. Ne donnez pas l’impression qu’une approbation reste valable si le code qu’elle était censée approuver a changé.

La documentation de GitHub sur les branches protégées décrit des contrôles côté dépôt qui peuvent compléter le flux de travail. Séparez l’acceptation humaine des modifications importantes de la capacité de l’agent à soumettre une proposition. Un agent de révision peut apporter un autre point de vue sans devenir la seule autorité habilitée à fusionner.

Notre guide de révision d’agentic-autofix fournit une liste de vérification complémentaire pour l’acceptation. En cas de conflit, déterminez d’abord le comportement attendu. Demander à un modèle de supprimer les marqueurs de conflit sans lui expliquer le contrat peut produire un fichier propre qui combine les comportements de façon incorrecte.

Une fois le travail accepté préservé et intégré en toute sécurité, effectuez le nettoyage habituel :

git worktree list
git worktree remove ../agent-docs
git worktree remove ../agent-tests
git branch -d agent/docs
git branch -d agent/tests

N’ajoutez pas d’options de forçage pour contourner un refus. Un répertoire de travail Git contenant des modifications non validées ou une branche que Git ne considère pas comme fusionnée doit être inspecté. Préservez les modifications inachevées et comprenez l’historique avant de décider quoi supprimer.

Que faut-il surveiller pendant les exécutions parallèles ?

Surveillez la propriété des tâches, la durée d’exécution des processus, l’utilisation des ressources, les requêtes externes et la file des résultats en attente de vérification. Un agent qui continue de fonctionner après la fin d’une tâche peut continuer à utiliser des identifiants ou à modifier des services partagés. Déterminez comment l’arrêter et comment confirmer qu’il s’est effectivement arrêté.

Fixez des budgets raisonnables et des conditions d’escalade pour chaque tâche. Des échecs répétés de dépendances, des demandes d’autorisation inattendues ou des modifications hors périmètre devraient déclencher une inspection plutôt que des tentatives illimitées. Tenez des journaux utiles, mais évitez d’y consigner des valeurs secrètes ou des contenus privés superflus.

Notre liste de contrôle des autorisations des agents personnels aide à préparer l’examen des accès. L’analyse de la transition de Conductor montre également pourquoi le travail doit rester portable : les commits, l’état des tâches et les éléments probants de l’examen doivent survivre à un changement de produit d’orchestration.

Avant de lancer une autre série de tâches, vérifiez que les identifiants temporaires ont été révoqués s’il y a lieu, que les services en arrière-plan ont été pris en compte et que la destination des branches terminées est connue. Évaluez le travail accepté et l’effort d’examen, pas seulement le nombre d’agents actifs. Si l’intégration constitue le goulot d’étranglement, réduisez le travail en cours au lieu d’ajouter davantage de résultats à la file d’attente.

Avant le nettoyage, consultez le flux de travail pour les fichiers récupérables afin de repérer les éléments qui ne figurent pas dans l’historique Git. Un jeu de données non suivi, un fichier de configuration local ou l’état d’un service externe peut nécessiter son propre plan de récupération.

FAQ

Deux agents peuvent-ils utiliser une seule branche sans risque ?

Il est possible de coordonner un travail partagé, mais les agents indépendants devraient normalement disposer de branches et de répertoires de travail distincts. Sinon, il devient difficile d’attribuer les modifications et les résultats des tests et de les reproduire.

Ajouter .env à .gitignore protège-t-il son contenu contre un agent ?

Non. Les règles d’ignorance influent sur le suivi Git, pas sur les droits de lecture du système de fichiers. Gardez les secrets inutiles hors de l’environnement accessible au worker.

Chaque agent devrait-il disposer d’un jeton lui permettant de fusionner des modifications ?

Non. N’accordez que les autorisations nécessaires à la tâche. Proposer une modification et l’accepter dans la branche protégée relèvent de pouvoirs différents.

Que faire si la suppression du worktree refuse de s’exécuter ?

Vérifiez le répertoire pour repérer le travail non validé ou non suivi et conservez ce qui est important. N’utilisez pas l’option force comme étape de nettoyage habituelle.

Un test réussi dans chaque branche suffit-il ?

Pas lorsque les modifications interagissent. Exécutez les vérifications pertinentes sur la version réellement intégrée et examinez le comportement aux frontières entre les composants.

Conclusion

Un codage parallèle sûr associe l’isolation du code source à des contrôles d’exécution et d’identifiants. Les worktrees facilitent la séparation et l’examen des modifications, tandis que des autorisations dédiées et des environnements sandbox correctement configurés limitent ce qu’un agent peut atteindre.

Partez d’une base propre, attribuez à chaque tâche un responsable et un contrat clairs, et n’intégrez que des résultats qui peuvent être examinés. Conservez les éléments probants avant le nettoyage, révoquez les accès temporaires et n’augmentez le travail en parallèle que lorsque les résultats acceptés justifient le coût de coordination.