Agents IA : pourquoi le sandbox devient aussi important que le prompt

Un assistant qui suggère du code et un agent qui exécute des commandes n’ont pas le même niveau de risque. Dès qu’un agent peut lancer un shell, modifier des fichiers ou appeler le réseau, son environnement d’exécution devient une frontière de sécurité à part entière.

Ce que GitHub ajoute dans Copilot

Le 23 septembre 2026, GitHub a annoncé des réglages de sandbox local dans l’application GitHub Copilot pour les sessions locales liées à un dépôt et à son working tree. La fonctionnalité est en public preview et reste désactivée par défaut.

La politique se configure par projet et couvre trois familles de ressources : le système de fichiers, le réseau et les credentials. Les réglages peuvent définir des dossiers supplémentaires en lecture/écriture ou lecture seule, des dossiers interdits, l’accès Internet sortant ou au réseau local, ainsi que l’accès aux credentials Git et GitHub CLI.

Le vrai sujet : borner les capacités de l’agent

Le prompt indique à l’agent ce qu’on souhaite qu’il fasse. Le sandbox définit ce qu’il peut réellement faire. Cette distinction devient essentielle avec les workflows agentiques.

Une instruction n’est pas une frontière de sécurité

Dire « ne touche pas à ce dossier » ou « n’utilise pas le réseau » dans un prompt n’offre pas la même garantie qu’une politique d’exécution qui bloque techniquement l’accès.

Cette logique rapproche les agents IA des autres composants exécutant du code non entièrement prévisible : conteneurs, workers CI/CD, extensions ou environnements de test. Le principe reste le même : limiter les capacités au strict nécessaire.

1. Système de fichiers : limiter ce que l’agent peut voir et modifier

Un agent n’a pas toujours besoin d’accéder à tout le dossier personnel, aux autres projets ou aux répertoires contenant des secrets. Le sandbox permet de séparer les zones accessibles en écriture, celles qui restent en lecture seule et celles qui sont explicitement interdites.

Pour un travail sur un dépôt, la règle simple est de commencer avec le périmètre le plus réduit puis d’élargir seulement si la tâche le nécessite réellement.

2. Réseau : empêcher une commande de parler à n’importe quoi

L’accès réseau est une capacité sensible. Un script peut télécharger une dépendance, appeler une API, atteindre un service local ou transmettre des données vers l’extérieur.

GitHub permet de configurer séparément l’accès Internet sortant et le réseau local. Cela ouvre la voie à des politiques adaptées au type de tâche : analyse locale sans réseau, installation de dépendances avec Internet, ou tests nécessitant explicitement certains services locaux.

3. Credentials : éviter que l’agent hérite automatiquement de votre identité

Le sandbox peut aussi contrôler les credentials Git utilisés pour les opérations HTTPS authentifiées et ceux de GitHub CLI. C’est un point important : un agent capable d’exécuter une commande avec les mêmes droits que l’utilisateur peut transformer une simple erreur en action distante.

Le bon réflexe est donc de ne donner à une session que les credentials dont elle a besoin, et seulement quand l’action distante est attendue.

Le détail le plus important : échouer plutôt que perdre l’isolation

GitHub précise que si le système d’exploitation ne peut pas appliquer la politique demandée, le shell sandboxé échoue avec une erreur au lieu de s’exécuter sans sandbox.

C’est une propriété essentielle : la sécurité doit être fail-closed. Une protection impossible à appliquer ne doit pas être remplacée silencieusement par une exécution sans restriction.

Ce que le sandbox local ne couvre pas

Les réglages annoncés concernent les sessions locales de l’application Copilot. Ils ne s’appliquent pas aux sessions cloud ni aux sessions exécutées sur un hôte distant. GitHub précise également que les réglages de sandbox de l’application Copilot et de Copilot CLI sont configurés séparément.

Enfin, les politiques gérées par une entreprise peuvent rendre la politique effective plus restrictive que les préférences locales du développeur.

Les bonnes pratiques à retenir

Activer l’isolation avant de donner davantage d’autonomie à un agent.
Limiter l’écriture au dépôt ou aux répertoires nécessaires.
Interdire explicitement les dossiers contenant des secrets ou d’autres projets.
Couper le réseau lorsqu’il n’est pas nécessaire.
Ne fournir les credentials Git/GitHub que pour les tâches qui en ont besoin.
Préférer un comportement fail-closed lorsqu’une politique ne peut pas être appliquée.
Traiter séparément les environnements local, CLI, distant et cloud.

L’agent devient une charge de travail à isoler

Les modèles continueront à progresser, mais leur niveau d’autonomie aussi. La question de sécurité ne peut donc plus se limiter à la qualité du prompt ou à la validation du code produit.

Pour les agents capables d’agir, le modèle de confiance doit inclure une couche d’exécution : permissions minimales, réseau contrôlé, credentials limités et isolation réellement appliquée. Le sandbox devient alors aussi important que le prompt.

Sources

Publié le 24 septembre 2026. La fonctionnalité est en public preview et peut évoluer.