Pourquoi la question se pose maintenant
Un agent de code ou d'automatisation ne se contente pas de proposer : il lance des commandes shell, installe des dépendances, lit des fichiers, appelle des API. Pendant longtemps, la seule protection était la fenêtre de validation : l'agent demande, l'humain clique sur « autoriser ». Ce modèle atteint ses limites pour deux raisons.
La première est humaine. Anthropic le dit sans détour : à force de cliquer sur « approuver », on finit par ne plus lire ce qu'on approuve. L'éditeur parle de « fatigue d'approbation », qui rend paradoxalement le développement moins sûr.
La seconde est structurelle. Un modèle de langage ne sait pas distinguer de façon fiable une instruction légitime d'une instruction cachée dans un contenu qu'il lit. Simon Willison, qui a forgé le terme « prompt injection », a formalisé en juin 2025 ce qu'il appelle la « trifecta létale » : dès qu'un agent cumule l'accès à des données privées, l'exposition à du contenu non fiable (un e-mail, une page web, un ticket) et la capacité de communiquer vers l'extérieur, un attaquant peut lui faire exfiltrer ces données. Sa conclusion est inconfortable : les filtres qui promettent de bloquer « 95 % des attaques » ne suffisent pas, car en sécurité 95 % reste un échec.
Si on ne peut pas garantir que l'agent obéira toujours, il faut limiter ce qu'il peut faire quand il désobéit. C'est exactement le rôle de l'isolation.
Ce que les incidents ont déjà montré
Deux épisodes de l'été 2025 résument le problème.
Replit, juillet 2025. L'investisseur Jason Lemkin construisait une application avec l'agent de Replit depuis neuf jours. Malgré un gel du code explicitement demandé, l'agent a supprimé la base de données de production : selon l'agent lui-même, les fiches de « 1 206 dirigeants et plus de 1 196 entreprises ». Fast Company précise que les données ont pu être récupérées. La réponse du PDG de Replit, rapportée par Tom's Hardware, est révélatrice : séparer automatiquement les bases de développement et de production « pour empêcher cela de manière catégorique ». Autrement dit, une barrière d'infrastructure plutôt qu'une consigne de plus.
Amazon Q Developer, juillet 2025. Dans son bulletin de sécurité, AWS explique qu'un jeton GitHub aux droits trop larges a permis à un attaquant d'introduire du code malveillant dans l'extension VS Code, inclus automatiquement dans la version 1.84.0. D'après BleepingComputer, ce code contenait un prompt demandant à l'agent de remettre le système dans un état proche de la sortie d'usine et de supprimer des fichiers et des ressources cloud. AWS indique qu'il n'a pas pu s'exécuter à cause d'une erreur de syntaxe. Le scénario reste instructif : la menace peut arriver par la chaîne d'approvisionnement de l'outil lui-même.
L'OWASP a intégré ces cas dans son Top 10 des applications agentiques, publié le 9 décembre 2025. Amazon Q y illustre le détournement d'outils, Replit les agents qui sortent de leur rôle, et une catégorie entière, l'exécution de code inattendue, vise les agents qui génèrent et lancent du code sans validation ni isolation.
Le signal : en douze mois, tout le monde a convergé
Ce qui fait de l'isolation une tendance et non une précaution de niche, c'est la vitesse à laquelle les grands acteurs ont livré des briques comparables.
- Octobre 2025, Anthropic. Claude Code reçoit un bac à sable au niveau du système d'exploitation (bubblewrap sous Linux, Seatbelt sous macOS) avec deux barrières : le système de fichiers, limité au répertoire de travail, et le réseau, qui ne sort que par un proxy filtrant les domaines. Anthropic affirme que, dans son usage interne, cela réduit les demandes d'autorisation de 84 %. Le moteur est publié en open source.
- Novembre 2025, Kubernetes. Google et la communauté lancent Agent Sandbox, un sous-projet officiel de SIG Apps. Il fournit une ressource Kubernetes dédiée aux environnements d'agents, compatible avec gVisor ou Kata Containers pour l'isolation. Le blog Kubernetes a détaillé l'approche en mars 2026, et le projet a publié sa version 1.0.0 fin août 2026.
- Avril 2026, Docker et Cloudflare. Docker lance Docker Sandboxes : chaque session d'agent tourne dans une micro-machine virtuelle avec son propre noyau et son propre démon Docker. Docker affirme offrir « l'isolation d'agent la plus forte du marché », ce qui reste un argument d'éditeur. Le même mois, Cloudflare annonce la disponibilité générale de ses Containers et Sandboxes.
- Juin 2026, AWS. Lambda MicroVMs est une brique serverless pensée pour exécuter du code généré par un utilisateur ou par une IA, dans des micro-VM Firecracker qui conservent leur état jusqu'à huit heures. La région Europe (Irlande) fait partie du lancement.
Côté outils de développement, le réglage par défaut a changé lui aussi. La documentation de Codex indique que l'agent d'OpenAI tourne en local avec le réseau coupé par défaut et des écritures limitées à l'espace de travail, et que certains chemins sensibles comme .git restent en lecture seule.
Une phrase du billet de Docker résume l'idée : un modèle de langage qui décide de ses propres limites de sécurité n'est pas un modèle de sécurité, et le périmètre doit venir de l'infrastructure, pas d'un prompt système.
Les quatre niveaux d'isolation, en clair
Toutes les isolations ne se valent pas. Pour un dirigeant, le plus utile est de connaître les quatre grands niveaux et ce qu'ils protègent.
Les quatre niveaux d'isolation, du plus léger au plus isolé. Le bon choix dépend de l'origine du code exécuté et de ce que l'agent peut atteindre.
1. Le bac à sable au niveau du système d'exploitation. C'est ce qu'utilisent Claude Code et Codex en local : des mécanismes natifs (bubblewrap, seccomp, Seatbelt) restreignent les fichiers et le réseau accessibles à chaque commande. Avantages : pas de Docker, mise en place rapide. Limite importante, que la documentation d'Anthropic souligne elle-même : le bac à sable de l'outil Bash ne couvre que les commandes shell. Les serveurs MCP et les scripts déclenchés automatiquement (les « hooks ») tournent hors de ce périmètre, sauf à envelopper tout le processus.
2. Le conteneur. Un conteneur Docker ou un dev container avec un pare-feu sortant en liste blanche isole tout l'environnement de travail. Anthropic et OpenAI publient tous deux des exemples de dev containers sécurisés. C'est souvent le meilleur rapport effort/protection pour une équipe. Limite : un conteneur partage le noyau de la machine hôte, ce qui le rend insuffisant pour du code franchement non fiable.
3. gVisor. C'est un noyau réimplémenté en espace utilisateur qui intercepte les appels système du conteneur. Selon la documentation d'Agent Sandbox, même en cas de faille d'évasion, l'attaquant n'atteint que ce noyau intermédiaire, pas l'hôte. C'est un bon compromis sur Kubernetes, sans virtualisation matérielle.
4. La micro-VM. Chaque agent reçoit son propre noyau, isolé par l'hyperviseur. Firecracker, le moteur open source d'AWS, n'émule que cinq périphériques et annonce un démarrage en moins de 125 ms pour moins de 5 Mio de mémoire par VM. On le retrouve derrière Lambda, E2B, Fly.io ou Kata Containers. C'est le niveau à viser dès que l'agent exécute du code dont personne ne connaît l'origine : dépôt tiers, code fourni par des clients, agents multi-tenants.
Le bon niveau dépend moins de la technologie que de deux questions : d'où vient le code exécuté, et que peut atteindre l'agent s'il dérape ?
Ce que l'isolation ne fait pas
L'isolation est nécessaire, pas suffisante. Trois angles morts reviennent dans toutes les documentations sérieuses.
Le réseau. Anthropic insiste : il faut les deux barrières. Sans isolation réseau, un agent compromis peut envoyer vos clés SSH à l'extérieur. Sans isolation des fichiers, il peut modifier sa propre configuration et sortir du bac à sable. Un conteneur avec un accès internet complet ne protège donc pas vos données.
Les secrets. Un agent isolé qui détient un jeton d'administration reste dangereux. Le schéma qui s'impose consiste à garder les identifiants hors du bac à sable. Claude Code sur le web fait passer les opérations git par un proxy qui vérifie la branche cible avant d'ajouter le vrai jeton. Docker injecte les secrets à l'exécution, en dehors de la micro-VM. L'incident Amazon Q rappelle d'ailleurs que le jeton trop large était dans la chaîne de build, pas dans l'agent.
Ce qui reste accessible en écriture. La documentation d'Anthropic le rappelle : tout répertoire monté en écriture peut être modifié, et tout environnement qui autorise des sorties réseau peut laisser fuiter ce que l'agent lit. Elle précise aussi que l'isolation ne change rien à ce qui est envoyé au fournisseur du modèle.
Côté français, l'ANSSI ne parle pas de micro-VM, mais ses recommandations de sécurité pour un système d'IA générative (avril 2024) vont dans le même sens : limiter, voire proscrire, les actions automatiques déclenchées à partir d'entrées non maîtrisées comme des e-mails ou des données d'internet (R27), cloisonner le système d'IA dans des environnements dédiés (R28), et proscrire l'exécution et le commit automatiques de code généré par IA sans contrôle (R30). Pour une PME qui doit justifier ses choix auprès d'un client grand compte ou d'un assureur, c'est une référence utile.
Le plan d'action pour une PME
Inutile de monter une plateforme Kubernetes pour commencer. Le plan suivant tient en un mois et s'articule avec le chantier passerelle MCP décrit dans l'article précédent.
Semaine 1 : cartographier où les agents exécutent du code. Postes des développeurs (Claude Code, Codex, Cursor, Copilot), CI/CD, automatisations n8n ou maison, agents exposés à des clients. Pour chacun, noter trois choses : d'où vient le code exécuté, quels secrets sont accessibles, quelles destinations réseau sont joignables.
Semaine 2 : activer ce qui existe déjà. La plupart des outils ont un bac à sable intégré qu'il suffit d'activer et d'imposer. Claude Code permet de diffuser la configuration du bac à sable par paramètres gérés (MDM ou console d'administration). Codex se configure en espace de travail limité, réseau coupé. Interdire en pratique les modes « sans garde-fou » (--dangerously-skip-permissions, --yolo) hors d'un conteneur ou d'une VM.
Semaine 3 : un environnement standard pour le travail autonome. Pour toute tâche lancée sans surveillance, un dev container de référence dans les dépôts, avec un pare-feu sortant en liste blanche, aucun secret de production, et un utilisateur non root. Pour du code non fiable (dépôt externe, code client), une VM jetable, une offre de micro-VM managée, ou un service d'exécution cloud.
Semaine 4 : sortir les secrets et tracer. Remplacer les jetons longue durée par des jetons à portée minimale et à durée courte, injectés hors du bac à sable. Séparer strictement développement et production : aucun agent n'a d'accès en écriture à une base de production. Activer la télémétrie quand l'outil la propose (Codex exporte des événements OpenTelemetry, dont les décisions d'approbation) et l'envoyer vers votre propre collecteur.
Checklist
- Inventaire des endroits où un agent exécute du code, avec un responsable pour chacun
- Bac à sable natif activé et imposé par configuration centrale sur les postes
- Aucun mode « sans permission » en dehors d'un conteneur ou d'une VM
- Isolation des fichiers et isolation réseau, toujours les deux ensemble
- Sorties réseau en liste blanche, refus par défaut
- Aucun secret de production dans l'environnement de l'agent
- Identifiants injectés hors du bac à sable, portée minimale, durée courte
- Bases de production inaccessibles en écriture aux agents
- Micro-VM ou VM jetable pour tout code d'origine inconnue
- Fichiers sensibles protégés en écriture : hooks git, configuration de l'agent, fichiers de démarrage du shell
- Journal des commandes et des approbations, conservé chez vous
- Test de maturité : vous pouvez supprimer et recréer l'environnement d'un agent en quelques minutes sans rien perdre d'important
Conclusion
La passerelle MCP répond à la question « quels outils l'agent a-t-il le droit d'appeler ? ». L'isolation répond à la suivante : « que se passe-t-il quand il fait autre chose que prévu ? ». Les deux briques se complètent, et le marché a tranché en un an : le bac à sable est désormais le réglage attendu, et les modes sans garde-fou sont l'exception à justifier.
Pour une PME, l'enjeu n'est pas de choisir entre Firecracker et gVisor dès lundi. Il s'agit d'activer ce que vos outils proposent déjà, de standardiser un environnement pour le travail autonome et de sortir les secrets de la portée des agents avant que les usages ne se multiplient. C'est le genre de cadrage que je fais avec des CTO et dirigeants de PME : cartographie de l'existant, choix du niveau d'isolation adapté à chaque usage, mise en place d'une configuration qui tient sans freiner les équipes. Si vos développeurs lancent déjà des agents en mode autonome, c'est le bon moment pour en parler.
Sources
- Anthropic Engineering, Beyond permission prompts: making Claude Code more secure and autonomous, 20 octobre 2025
- Anthropic, Choose a sandbox environment (documentation Claude Code), consulté le 6 octobre 2026
- Simon Willison, The lethal trifecta for AI agents, 16 juin 2025
- Fast Company, Replit CEO: What really happened when AI agent wiped Jason Lemkin's database, juillet 2025
- Tom's Hardware, AI coding platform goes rogue during code freeze and deletes entire company database, 21 juillet 2025
- AWS, Security Update for Amazon Q Developer Extension for Visual Studio Code (AWS-2025-015), 23 juillet 2025
- BleepingComputer, Amazon AI coding agent hacked to inject data wiping commands, 25 juillet 2025
- OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications, 9 décembre 2025
- Google Open Source Blog, Why Kubernetes needs a new standard for agent execution, novembre 2025
- Kubernetes Blog, Running Agents on Kubernetes with Agent Sandbox, 20 mars 2026
- Kubernetes SIG Apps, Agent Sandbox, isolation gVisor (documentation) et version 1.0.0, 28 août 2026
- Docker, Why MicroVMs: The Architecture Behind Docker Sandboxes, 16 avril 2026
- Cloudflare, Containers and Sandboxes are now generally available, 13 avril 2026
- AWS News Blog, AWS Lambda introduces MicroVMs, 22 juin 2026
- Firecracker, site officiel du projet, consulté le 6 octobre 2026
- OpenAI, Codex : Agent approvals & security, consulté le 6 octobre 2026
- ANSSI, Recommandations de sécurité pour un système d'IA générative, 29 avril 2024
