Agent IA en terminal : quelle combinaison de garde-fous avant d’autoriser les commandes ?

Donner un terminal à un agent IA change immédiatement la nature du risque. L’outil ne produit plus seulement une suggestion de code : il peut lire le dépôt, lancer des tests, installer une dépendance, contacter un service distant ou modifier plusieurs fichiers. La question utile n’est donc pas seulement de savoir si l’agent est performant. Il faut décider quelles commandes il peut exécuter, sur quelles ressources, avec quel réseau et sous quel contrôle.

Un scénario hypothétique suffit à montrer le problème. Une équipe demande à un agent de corriger un test instable. Le dépôt est isolé, les secrets de production sont absents et le système de fichiers est limité. Pour diagnostiquer l’échec, l’agent tente ensuite d’installer un paquet, d’appeler un proxy interne et de relancer une commande avec des droits plus larges. Chaque étape peut sembler raisonnable séparément. Ensemble, elles créent une chaîne d’accès que l’équipe n’avait pas explicitement validée.

Le bon périmètre : contrôler les capacités, pas seulement le modèle

Les recommandations récentes des éditeurs convergent sur un point : un environnement isolé ne suffit pas si les services accessibles depuis cet environnement disposent d’un réseau ou de privilèges trop larges. GitLab décrit ainsi le risque d’une liste d’autorisation qui donne indirectement à l’agent la portée du service autorisé. La documentation OpenAI rappelle également qu’un code généré par un agent peut accéder aux fichiers, identifiants et ressources réseau disponibles dans son environnement.

La première décision consiste donc à décrire les capacités nécessaires à la tâche. Pour une correction locale, l’agent peut avoir besoin de lire certains fichiers, d’écrire dans un répertoire de travail et d’exécuter les tests. Il n’a pas forcément besoin d’accéder au réseau, au gestionnaire de secrets, à l’API de production ou à l’ensemble du système de fichiers.

Cette logique complète préparer un bac à sable pour agents IA : l’isolement fournit une frontière technique, mais la politique d’accès doit encore préciser ce qui est autorisé à l’intérieur de cette frontière.

Quatre familles de garde-fous à comparer

Ces dispositifs ne sont pas interchangeables. Une approbation humaine ne remplace pas une restriction réseau : une personne peut valider une commande sans voir qu’elle déclenche une requête externe. De la même manière, une liste de domaines ne remplace pas une limitation des fichiers : l’agent peut encore lire une donnée sensible avant de l’envoyer vers une destination pourtant autorisée.

Cas 1 : la liste de commandes, utile pour commencer

La liste de commandes convient aux tâches courtes et répétitives : lancer un test ciblé, formater un fichier, produire un diff ou exécuter un analyseur statique. Elle doit porter sur des commandes concrètes plutôt que sur une autorisation vague du type « terminal complet ».

Une politique minimale peut distinguer trois niveaux :

• les commandes sans effet durable, comme la lecture d’un statut Git ou l’exécution d’un test local ;
• les commandes qui écrivent dans le dépôt ou modifient l’environnement de travail ;
• les commandes qui installent, publient, suppriment ou contactent un service externe.

Le piège est de croire qu’un nom de commande suffit. Un gestionnaire de paquets peut exécuter des scripts d’installation. Un interpréteur peut lancer une chaîne arbitraire. Un outil de build peut charger une configuration depuis le dépôt. La politique doit donc tenir compte des effets indirects, pas seulement du binaire appelé.

Cas 2 : le réseau, la frontière souvent oubliée

Le réseau doit être pensé comme une capacité séparée. Pour une tâche de correction locale, le mode sans sortie réseau est généralement le point de départ le plus lisible. Si l’installation d’une dépendance ou l’appel à une API est indispensable, l’autorisation doit viser des destinations précises, avec une passerelle qui ne transmet pas automatiquement des identifiants réutilisables.

GitLab rapporte qu’un service placé sur une liste d’autorisation peut devenir un relais vers d’autres destinations s’il possède lui-même une connectivité trop large. La conséquence pratique est importante : il faut contrôler le réseau de l’agent, mais aussi le réseau des proxys, registres et serveurs d’outils qu’il peut atteindre.

La documentation OpenAI recommande de garder les identifiants tiers hors de l’environnement de travail et de faire ajouter les secrets par un proxy de confiance uniquement pour les hôtes approuvés. Ce modèle réduit l’exposition directe, sans supprimer la nécessité de vérifier les journaux et les destinations réellement utilisées.

Cas 3 : l’approbation humaine, pour les changements qui comptent

L’approbation est pertinente lorsque l’action est difficile à annuler ou lorsqu’elle franchit une frontière de confiance. On peut exiger une validation avant une écriture hors du répertoire de travail, une modification de configuration, une installation, un appel réseau exceptionnel ou une création de pull request.

GitHub a récemment ajouté des permissions administrées au niveau de l’entreprise pour distinguer les opérations bloquées, soumises à approbation ou autorisées sans invite. Les contrôles couvrent notamment les commandes shell, les lectures et écritures de fichiers ainsi que les domaines réseau. Cette séparation est plus exploitable qu’un simple bouton d’auto-approbation appliqué à tout le workflow.

L’approbation doit toutefois présenter l’action dans son contexte : commande complète, répertoire courant, fichiers touchés, destination réseau et raison déclarée. Une fenêtre qui affiche seulement « autoriser cette commande ? » ne permet pas de mesurer correctement le risque.

Une méthode de choix pour une équipe

Le choix ne devrait pas commencer par le nom de l’outil. Il commence par la tâche et par les conséquences d’un échec. Une équipe peut classer chaque usage avec quatre questions :

1. Quels fichiers l’agent doit-il lire et modifier pour terminer la tâche ?
2. Quelles commandes sont nécessaires, y compris leurs effets indirects ?
3. Le réseau est-il indispensable, et quelles destinations précises sont justifiées ?
4. Quelle action doit obligatoirement rester humaine parce qu’elle est durable, externe ou difficile à annuler ?

Pour une tâche de test local, la combinaison raisonnable est un répertoire de travail limité, un réseau désactivé et une liste courte de commandes. Pour une mise à jour de dépendance, il faut ajouter une lecture contrôlée du manifeste et du lockfile, puis une validation humaine avant l’installation et la fusion. Pour une tâche qui appelle un service externe, le réseau doit passer par une passerelle documentée, avec des identifiants absents du contexte de l’agent.

Checklist avant d’ouvrir le terminal

• Le dépôt utilisé contient-il uniquement des données synthétiques ou autorisées ?
• Les secrets, fichiers SSH et variables de production sont-ils hors du périmètre lisible ?
• Les commandes permises sont-elles définies par leurs effets et non par une autorisation globale ?
• Le réseau est-il désactivé par défaut ou limité à des destinations précises ?
• Les proxys et serveurs d’outils accessibles ont-ils eux-mêmes une sortie réseau minimale ?
• Les écritures, installations, suppressions et publications exigent-elles une validation explicite ?
• Les commandes, fichiers touchés, destinations et décisions humaines sont-ils journalisés ?
• Existe-t-il un moyen simple de couper la session et de repartir d’un état propre ?

Pour relier cette politique à l’exploitation, il est utile de conserver une trace séparée des commandes et des résultats de test. Les principes d’observabilité d’un agent IA avec OpenTelemetry peuvent aider à reconstruire la séquence d’outils utilisée, sans transformer chaque sortie en archive de données sensibles.

Le compromis acceptable

Le garde-fou le plus efficace n’est pas celui qui bloque toute action. C’est celui qui rend explicite la capacité accordée, limite sa portée et fournit une sortie vérifiable. Une liste de commandes réduit les erreurs évidentes, une restriction de fichiers protège le périmètre local, un réseau contrôlé limite les chemins indirects et l’approbation humaine reprend la main avant les effets durables.

Une équipe peut commencer petit : une tâche, un dépôt de test, aucune donnée sensible, aucune sortie réseau par défaut et des commandes observables. Elle élargit ensuite les droits uniquement lorsqu’un besoin est démontré et qu’un contrôle correspondant existe. L’agent gagne alors en autonomie sans que la sécurité repose sur la seule promesse du modèle.