Votre agent de code peut lire vos clés SSH. Voici comment le cloisonner

Quand un agent de code lance ls, cat ou npm install sur votre portable, il les lance en tant que vous. Pas comme invité, pas comme compte de service limité : comme votre utilisateur, avec votre dossier personnel, vos clés SSH, chaque fichier .env de chaque projet que vous avez cloné un jour, et les identifiants git et cloud qui traînent dans votre configuration. C'est la partie qu'on saute quand on branche un agent sur un terminal, et c'est pourquoi l'annonce de GitHub du 2026-10-07 compte plus que sa taille ne le laisse croire : le sandboxing local pour Copilot est désormais disponible pour tous.

Le risque, c'est le texte que l'agent lit, pas l'agent

Cette partie est générale, elle ne concerne aucun produit en particulier. Un agent décide quoi exécuter à partir de ce qu'il lit, et il lit beaucoup de choses que vous n'avez pas écrites : le README d'un dépôt fraîchement cloné, une issue ouverte par quelqu'un, une page web qu'il a récupérée, un commentaire dans une dépendance. Si l'un de ces textes lui dit d'afficher un fichier ou d'envoyer quelque chose quelque part, l'agent peut obéir, parce qu'à ses yeux l'instruction fait partie du travail. C'est de l'injection de prompt. Vous ne pouvez pas relire chaque ligne qu'un agent lit, donc la bonne question n'est pas « va-t-il se faire piéger » mais « qu'est-ce qu'il peut atteindre le jour où ça arrive ».

Ce que restreint le bac à sable de GitHub

Selon GitHub, le bac à sable est disponible dans Copilot CLI, l'application Copilot et les sessions VS Code qui utilisent Agent Host, sans surcoût par rapport à Copilot. Les outils et commandes lancés par Copilot tournent avec un accès restreint au système de fichiers, au réseau, aux identifiants et à d'autres capacités du système, selon des politiques définies par le développeur ou l'organisation. GitHub liste ce que vous pouvez contrôler : quels fichiers et dossiers ces commandes peuvent lire ou modifier ; l'accès à Internet, au réseau local, aux identifiants Git et à ceux de GitHub CLI ; et le sandboxing des outils locaux comme les serveurs MCP locaux et les serveurs de langage, là où c'est pris en charge. Les entreprises peuvent imposer le bac à sable et verrouiller les politiques pour qu'un développeur ne puisse pas les assouplir.

En dessous se trouve ce que GitHub appelle Microsoft eXecution Container (MXC), qui traduit une seule politique de bac à sable dans les contrôles natifs de Windows, macOS et Linux. GitHub fait aussi une remarque avec laquelle je suis d'accord : le modèle et le bac à sable des outils sont deux sujets distincts, donc la politique s'applique à ce qui est exécuté, quel que soit le modèle aux commandes.

Des couches à reprendre pour n'importe quel agent

Quel que soit votre agent, voici des habitudes générales, pas des réglages tirés de l'annonce de GitHub, et chacune ferme une porte différente :

• Le dossier du projet, rien d'autre. L'agent lit et écrit dans le dépôt sur lequel il travaille, rien au-dessus.
• Pas d'identifiants ambiants. Ne le laissez pas hériter de vos jetons personnels. S'il a besoin d'un accès, donnez-lui un jeton à courte durée de vie limité à cette tâche.
• Une liste blanche réseau. Les registres de paquets et les API dont la tâche a besoin, pas Internet en entier.
• Un humain valide tout ce qui est destructif. Supprimer, faire un force-push, supprimer une table.
• Les dépôts non fiables vont dans un conteneur ou une VM, jamais directement sur la machine qui détient vos clés.
• Lisez le diff avant qu'il quitte votre machine, et ne confiez jamais d'identifiants de production à un agent.

L'étape suivante prend dix minutes : ouvrez un terminal comme le fait votre agent et listez ce que cet utilisateur peut lire, en commençant par ~/.ssh, le dossier de configuration de votre cloud et les fichiers .env de vos projets. Tout ce qui figure sur cette liste est à la portée de l'agent aujourd'hui. Si vous utilisez Copilot, activez le bac à sable et commencez par les règles sur le système de fichiers et les identifiants ; avec un autre agent, construisez la même clôture avec un dev container et un jeton à portée limitée. Source : GitHub changelog, sandboxing local pour GitHub Copilot.