Ce que l’assistant peut réellement faire

En mode agent, un assistant de code lit les fichiers du projet, les modifie, lance des commandes — installation, tests, scripts — et peut se connecter à des serveurs MCP ou au web. Il agit avec les droits de votre compte. Les risques viennent de trois directions :

  • Le contenu qu’il lit : un README, un commentaire ou un ticket peut contenir une instruction cachée, comme l’explique notre guide sur l’injection de prompt.
  • La configuration du dépôt : scripts d’installation, configuration MCP du projet, extensions, plugins. The Hacker News a rapporté le 18 septembre 2026 la faille « Plugin4Shell » : le propriétaire d’un dépôt de plugins pouvait faire installer un autre code que la version épinglée et vérifiée, dans quatre agents de code (Claude Code, Codex, GitHub Copilot et Gemini CLI). Anthropic et OpenAI l’ont corrigée dans Claude Code 2.1.179 et Codex 0.146.0 : garder ses outils à jour fait partie de la sécurité.
  • Ce qu’il propose : commandes destructrices, dépendances inexistantes — le CERT-FR signale que des attaquants enregistrent des noms de paquets inventés par les assistants —, code vulnérable.

Claude Code : modes de permission et bac à sable

Selon sa documentation de sécurité, Claude Code propose deux grands modes. En mode Manuel, il démarre en lecture seule et demande votre accord avant de modifier un fichier, lancer des tests ou exécuter une commande, sauf pour une liste de commandes en lecture seule comme ls ou git status. Le mode Auto, mode de départ des sessions interactives dans le terminal et dans VS Code, confie l’examen des actions à un modèle classifieur qui bloque celles qu’il juge dangereuses ; vos règles d’autorisation et d’interdiction restent appliquées.

Autres protections documentées : un outil bash isolable dans un bac à sable avec isolation du système de fichiers et du réseau ; les commandes qui récupèrent du contenu sur le web, comme curl et wget, ne sont pas approuvées automatiquement ; une boîte de dialogue de confiance s’affiche à l’ouverture d’un dossier non approuvé, et les serveurs MCP déclarés par un projet demandent leur propre accord. Attention : une session non interactive lancée avec -p n’affiche ni l’une ni l’autre. Anthropic recommande de relire les commandes avant de les approuver, de ne pas transmettre directement du contenu non fiable et d’utiliser des machines virtuelles pour les scripts touchant des services externes.

Codex : bac à sable et politique d’approbation

La documentation de Codex indique que l’agent fonctionne par défaut sans accès réseau et, en local, dans un bac à sable imposé par le système qui limite ce qu’il peut toucher, en général au dossier de travail. Une politique d’approbation détermine quand il doit s’arrêter pour vous demander. Pour un dossier versionné, OpenAI recommande le mode Auto (écriture dans l’espace de travail et approbation à la demande) ; pour un dossier non versionné, la lecture seule.

OpenAI met en garde : prudence avant d’activer l’accès réseau ou la recherche web, car une injection de prompt peut amener l’agent à récupérer et suivre des instructions non fiables. L’option qui contourne approbations et bac à sable est marquée comme un risque élevé et déconseillée.

GitHub Copilot dans VS Code : confiance de l’espace de travail

Visual Studio Code recommande d’ouvrir les projets non vérifiés en mode restreint : tant que vous n’avez pas fait confiance à l’espace de travail, les agents y sont désactivés. Avant d’exécuter une commande dans le terminal, l’agent demande une approbation explicite. Les fonctions d’approbation automatique réduisent la friction mais peuvent mener à des actions destructrices, à la modification de fichiers sensibles ou à l’exécution de code arbitraire. VS Code conseille aussi de relire la configuration MCP d’un dépôt avant de lui faire confiance et, face au risque d’injection, de préférer le bac à sable de l’agent ou un conteneur de développement aux seules règles d’approbation automatique.

Dix réflexes, quel que soit l’outil

  1. Travailler dans un dépôt Git propre, sur une branche dédiée, pour pouvoir tout annuler.
  2. Garder la confirmation des commandes, surtout pour les suppressions, installations et accès réseau.
  3. Ouvrir un dépôt inconnu en mode restreint, ou dans un conteneur ou une machine virtuelle.
  4. Laisser l’accès réseau fermé par défaut et l’ouvrir domaine par domaine.
  5. Ne jamais donner de secret de production : variables de test, comptes de test, données fictives.
  6. Relire chaque diff avant le commit, comme le travail d’un collègue.
  7. Vérifier que chaque dépendance proposée existe, est la bonne et est maintenue.
  8. N’installer que des serveurs MCP, extensions et plugins de confiance, en relisant la commande exacte.
  9. Lancer les tests et l’analyse de sécurité avant de fusionner.
  10. Réserver le mode sans confirmation aux environnements jetables, sans secret ni accès à la production.

Ce que Prompt OS ajoute à la mission

Prompt OS prépare la mission que vous donnerez à Claude Code, Codex ou Copilot. Il y ajoute, selon le projet, la protection des secrets, la validation humaine des actions sensibles, les permissions minimales, l’isolation et le bac à sable, le contrôle des commandes shell, la vérification des dépendances et le retour arrière. La formation Prompt OS pour VS Code applique la même méthode directement dans VS Code : vous ouvrez le dossier, vous écrivez « Bonjour », l’assistant vous guide. Pour vérifier ensuite le code produit, voir notre guide sur le code généré par l’IA.

Conclusion

Les assistants de code sont devenus des collègues très rapides qui ne voient pas les pièges. Leurs protections intégrées sont solides si on les laisse actives : confirmation, bac à sable, réseau fermé, confiance explicite. Le reste relève des bonnes pratiques habituelles — Git, revue, tests — appliquées avec plus de discipline encore.