Les sandboxes pour agents de codage IA deviennent une discipline de sécurité à part entière, et non plus une réflexion après coup

Donnez à un agent de codage IA un accès complet à votre dépôt, à votre shell et à vos variables d'environnement, et vous lui aurez confié le même rayon d'explosion qu'un pipeline CI compromis. Cela pouvait encore passer pour un risque acceptable quand les agents exécutaient des tâches monotour, supervisées par un humain, durant quelques minutes. Cela a cessé de l'être dès l'instant où les agents ont commencé à tourner sans surveillance pendant des heures, à coordonner plusieurs sous-agents et à exécuter des commandes shell pour tester leurs propres modifications.

La réponse de l'industrie a convergé vers un schéma : exécuter les agents dans des environnements isolés et jetables — sandboxes, conteneurs ou worktrees git éphémères — plutôt que directement sur le checkout actif du développeur. Ce n'est plus une précaution expérimentale. Cela devient une infrastructure de base, et les équipes qui s'en passent accumulent un risque qu'elles n'ont pas évalué.

Pourquoi l'approche naïve montre ses limites

La manière évidente de faire tourner un agent de codage consiste à le pointer vers votre répertoire de travail et à le laisser modifier les fichiers directement. Cela fonctionne très bien pour de petites éditions supervisées. Mais cela s'effondre selon trois axes à mesure que l'autonomie augmente :

Exposition des identifiants. Un agent disposant d'un accès shell peut lire les fichiers .env, les clés SSH, les identifiants CLI cloud et les tokens API présents dans l'environnement — non pas parce qu'il le veut, mais parce qu'une étape de débogage ou une instruction mal interprétée l'amène à faire un cat sur un fichier qu'il ne devrait pas toucher. Une injection de prompt via une dépendance malveillante, un README empoisonné ou un registre de paquets compromis peut transformer cela en exfiltration active plutôt qu'en simple accident.

Effets irréversibles. Un agent qui teste une migration de base de données, exécute un script de nettoyage ou expérimente une commande de déploiement sur de l'infrastructure réelle peut causer des dégâts qu'aucune revue de code n'aurait approuvés — parce que personne ne l'a examiné avant exécution.

Pollution de l'état. Quand plusieurs agents ou plusieurs tentatives partagent un même worktree, les éditions partielles d'une tentative échouée contaminent la suivante. Le débogage devient de l'archéologie : quelles modifications viennent de quelle exécution ?

À quoi ressemble concrètement le schéma sandbox + worktree

Le schéma qui s'est imposé combine deux mécanismes distincts remplissant deux rôles distincts.

Les worktrees git (ou des clones complets du dépôt) assurent l'isolation au niveau du système de fichiers. Au lieu qu'un agent modifie votre unique copie checkoutée du dépôt, il dispose de son propre worktree — un répertoire séparé, adossé au même historique git, mais avec des fichiers et un état de branche indépendants. Plusieurs agents, ou plusieurs tentatives parallèles sur la même tâche, obtiennent chacun un worktree propre. Rien n'est commité sur la branche principale tant qu'un humain — ou une étape de vérification — n'a approuvé le diff.

Les sandboxes d'exécution assurent l'isolation au niveau des processus et du réseau. Les commandes shell de l'agent s'exécutent dans un conteneur, une VM ou un contexte d'exécution restreint qui n'a pas accès aux identifiants de l'hôte, pas de route vers internet au-delà d'une liste blanche explicite, et aucune capacité à toucher quoi que ce soit en dehors de son worktree attribué. La plateforme Antigravity de Google, par exemple, exécute son mode de raisonnement approfondi /boost dans ce qu'elle appelle des worktrees isolés éphémères, précisément pour que les sous-agents d'implémentation puissent exécuter des cibles de build et des suites de tests localement sans toucher à l'état de travail réel du développeur — et pour qu'une hypothèse infructueuse puisse simplement être écartée plutôt que reverruée manuellement.

Mis ensemble, cela signifie qu'un agent peut se voir accorder des permissions véritablement larges — lire l'ensemble du code, exécuter des commandes shell arbitraires, installer des paquets, atteindre des services locaux — sans que ces permissions ne s'étendent à ce que le développeur tient réellement à protéger. Le rayon d'explosion, c'est la sandbox jetable, pas la machine ni le compte.

L'étape de vérification reste cruciale

La sandbox résout le problème de confinement, pas celui de la justesse. Un agent peut tourner entièrement dans un environnement isolé et produire malgré tout du code faux, non sécurisé ou subtilement défaillant. Ce que la sandbox vous apporte, c'est la capacité de laisser un agent itérer — écrire du code, lancer des tests, constater des échecs, recommencer — sans qu'une intervention humaine soit nécessaire à chaque étape intermédiaire. La revue doit encore avoir lieu au moment où un diff est proposé pour merge, et de plus en plus, cette étape de revue est elle-même automatisée : des passes de vérification indépendantes qui relancent la suite de tests complète sur les modifications en sandbox avant qu'elles ne soient jamais présentées à une personne.

C'est aussi pour cela que le schéma de sandbox passe mieux à l'échelle que le prompting de permissions. Demander à un humain d'approuver chaque écriture de fichier ou chaque commande shell qu'un agent souhaite exécuter n'améliore pas réellement la sécurité — cela entraîne les gens à cliquer sur approuver sans lire, le même mode de défaillance qui a rendu les boîtes de dialogue de permissions du navigateur et les invites UAC quasiment inutiles. Isoler le rayon d'explosion en amont, puis examiner le diff final, constitue un modèle de sécurité plus honnête que l'espoir qu'un développeur fatigué lise chaque boîte de confirmation.

Que faire concrètement

Si vous faites tourner des agents de codage IA sur de vrais dépôts aujourd'hui, trois changements comptent davantage que n'importe quel outil fournisseur spécifique :

Séparez les identifiants de l'agent des vôtres. Ne laissez jamais un agent s'exécuter dans un shell où vos clés SSH personnelles, vos identifiants de fournisseurs cloud ou vos tokens API de production sont accessibles. Utilisez des tokens à portée limitée et à durée de vie courte pour l'accès dont l'agent a réellement besoin, et rien de plus.

Donnez aux agents leur propre worktree, pas votre checkout actif. Que ce soit via git worktree add, un conteneur jetable par tâche, ou une plateforme managée qui le fait pour vous, assurez-vous qu'une exécution défaillante ou malveillante ne laisse aucune trace sur la copie du code dans laquelle vous travaillez réellement.

Traitez l'egress réseau comme une permission, pas comme un défaut. Un agent qui peut installer des paquets arbitraires depuis internet public pendant une exécution en sandbox reste un risque pour la supply chain. Dans la mesure du possible, restreignez l'accès réseau sortant à une liste blanche explicite plutôt que de le laisser ouvert par défaut.

Rien de tout cela n'est une infrastructure exotique — les worktrees et les conteneurs existent depuis bien avant la vague actuelle d'outils de codage IA. Ce qui est nouveau, c'est l'urgence : des agents qui opèrent pendant des heures d'affilée, se coordonnent avec d'autres agents et exécutent du code sans qu'un humain surveille chaque étape ont fait de la frontière d'isolation une exigence, et non plus un exercice de durcissement qu'on repousse à plus tard.