Votre agent ne s'est jamais évadé du sandbox. Il n'en avait pas besoin.

Qu'est-ce qu'une évasion de sandbox dans un agent de code ?

Le plus souvent, ce n'est pas une évasion du tout. Dans les cas divulgués en 2026, l'agent n'a pas percé son conteneur, ni mis en défaut un hyperviseur, ni exploité une faille noyau. Il a utilisé sa capacité ordinaire et prévue d'écrire des fichiers dans le projet sur lequel il travaillait, et l'un de ces fichiers se trouvait être une entrée d'un programme qui, lui, tourne avec tous les privilèges de l'utilisateur.

Voici l'ensemble divulgué, publié par Pillar à raison d'un billet par jour. Il vaut d'être lu comme une liste, parce que le schéma ne devient évident qu'à l'échelle de l'ensemble.

Lisez la troisième colonne de haut en bas. Quatre des sept sont une écriture, pas une évasion. L'agent a produit un fichier, un processus de confiance l'a consommé, et ce processus n'était pas dans la boîte.

Si un agent peut écrire les entrées futures des systèmes, c'est qu'il n'a jamais été sandboxé.

La CSA appelle cela le Trust Handoff Flaw et, en citant les chercheurs de Pillar, le définit précisément : l'agent « reste dans la boîte et respecte chaque règle », mais écrit un fichier, une configuration de hook, un interpréteur d'environnement virtuel, une entrée de config Git, une définition de tâche, « qu'un autre outil, non sandboxé, consomme une fois le tour de l'agent terminé ».

Cette définition travaille plus qu'il n'y paraît. Elle déplace la frontière de sécurité, d'un endroit que vous pouvez configurer vers une relation que vous n'avez probablement jamais inventoriée : l'ensemble des programmes de la machine du développeur qui lisent des fichiers locaux au projet et agissent dessus sans rien demander.

Pourquoi les sandbox cèdent-ils toujours de la même façon ?

Parce que quatre hypothèses reviennent sans cesse dans la conception des sandbox, et que le comportement d'un agent les invalide toutes les quatre. La note de la CSA les nomme, et il vaut mieux les énoncer comme des erreurs de conception que comme des bugs, parce que chacune reviendra dans le prochain produit qui livrera un agent.

Rien de tout cela n'est exotique. Ce sont les modes de défaillance classiques de la sécurité périmétrique, redécouverts dans un nouvel endroit, par des équipes qui livrent vite dans une catégorie qui n'existait pas il y a deux ans.

GitSpawn : la même faille, dans le fichier que tout dépôt possède

Si le schéma vous paraît encore abstrait, la divulgation de Manifold Security début septembre 2026 le rend concret, et c'est l'illustration la plus nette de tout l'argument.

core.fsmonitor est un réglage de performance Git. Sa valeur est une commande, que Git exécute pour déterminer quels fichiers ont changé. Git la lit dans le .git/config du dépôt lui-même. Les agents de code appellent Git au démarrage pour connaître la branche et les fichiers modifiés, donc la commande s'exécute immédiatement, avec les privilèges de l'utilisateur, avant même qu'une fenêtre d'approbation puisse exister pour être affichée.

C'est sur le mode de livraison qu'il faut être précis, et Manifold l'est : « cloner une URL hostile ne fait rien, pas plus qu'un fetch ou un pull ». Un git clone ordinaire ne transporte pas le .git/config du dépôt source. Le dépôt doit arriver sous forme de fichiers, avec son dossier .git déjà dedans : une archive .zip partagée, un dossier synchronisé, un disque partagé, une clé USB. Ouvrir ce dossier avec un agent suffit alors. Pas de dépendance malveillante, pas de script post-install, pas de code à relire, et rien qu'un scanner lisant les fichiers sources signalerait. La charge est dans un fichier de configuration que la plupart des développeurs n'ont jamais ouvert.

Trois détails méritent d'être soulignés. D'abord, les correctifs sont par chemin et non par classe : Manifold a signalé une seconde route vers Claude Code, par un autre réglage Git, encore active en 2.1.252 après le correctif de la première. Ensuite, plusieurs agents étaient encore vulnérables confirmés au moment de la divulgation : Manifold compte huit failles sur sept agents, dont quatre encore sans correctif à la publication. Enfin, les identifiants demandent du soin. Manifold ne cite aucun CVE pour sa faille Claude Code, et l'identifiant Claude Code avec lequel on la confond facilement, CVE-2026-55607, décrit une autre faille : une évasion de sandbox par confusion de chemins dans les worktrees Git, présente à partir de la 2.1.38 et corrigée en 2.1.163, bien avant la 2.1.193 sur laquelle Manifold a confirmé la sienne. Si votre contrôle est « on a mis à jour », votre contrôle porte un numéro de version et contient une situation de course.

Ce qui protège vraiment est plus étroit qu'il n'y paraît, autant être exact. Manifold donne deux conseils. Si vous recevez un dépôt sous forme de fichiers, inspectez .git/config avant d'ouvrir le dossier avec un agent, car « tout réglage qui nomme un programme peut l'exécuter ». Si vous éditez un agent, ou un simple script qui appelle Git en arrière-plan, assainissez la configuration Git de ces appels, par exemple avec git -c core.fsmonitor=false status. Le troisième geste est de nous : mettez l'agent à jour, le tableau ci-dessus indique les versions qui portent un correctif.

# Un depot recu sous forme de fichiers : lire sa config avant qu'un agent ne l'ouvre
cat .git/config

# Dans un outil ou un script qui appelle Git en arriere-plan, surcharger la cle sur l'appel lui-meme
git -c core.fsmonitor=false status

Le réglage global souvent conseillé à la place, git config --global core.fsmonitor false, ne vous protège pas. La documentation de Git énumère les fichiers de configuration dans l'ordre, système, puis global, puis le .git/config du dépôt, et précise qu'ils sont « lus dans l'ordre indiqué ci-dessus, la dernière valeur trouvée l'emportant sur celles lues avant ». La valeur du dépôt est lue après votre valeur globale, donc un .git/config piégé gagne. L'option -c fait exception : d'après le manuel de Git, sa valeur « l'emporte sur les valeurs des fichiers de configuration ».

Même bien fait, cela traite core.fsmonitor et rien d'autre. Cela ne fait rien pour core.hooksPath, pour .vscode/tasks.json, pour un interpréteur venv, pour un hook .claude, ni pour la prochaine clé de configuration dont quelqu'un remarquera qu'elle est exécutable. On ne corrige pas une propriété de conception à coups de patchs.

Ce que le sandbox couvre vraiment, et ce qu'il ne couvre pas

Rendons justice au sandbox, qui mérite réellement d'être déployé : il fait un vrai travail, et ce travail n'est pas rien. Il est simplement plus étroit que le discours qui l'entoure.

Les quatre dernières lignes sont celles qui comptent, et elles partagent une propriété : l'agent ne fait rien d'interdit. Les contrôles de périmètre détectent des violations de frontière. Aucune de ces lignes n'en est une.

Il reste une défaillance à ranger ici, parce que c'est la plus humaine de toutes. En mars 2026, une issue a été ouverte contre Claude Code signalant que le réglage sandbox de ~/.claude/settings.json n'était pas appliqué quand l'agent tournait dans l'extension VS Code ou Cursor : l'extension lançait le binaire natif sans l'option --sandbox, si bien que le profil Seatbelt de macOS n'était jamais appliqué, même avec sandbox.enabled: true. L'auteur l'a vérifié en écrivant un fichier dans ~/Desktop depuis une session Cursor. L'issue a été fermée en doublon quatre jours plus tard, et le seul contournement consigné est celui de l'auteur du signalement : lancer la CLI directement, ou utiliser des hooks PreToolUse comme garde de substitution.

Quel que soit son statut aujourd'hui, la classe de problème est permanente : un sandbox est une configuration, une configuration a des surfaces où elle ne s'applique silencieusement pas, et un contrôle que vous croyez actif est pire qu'un contrôle que vous savez inactif.

Alors, concrètement, on fait quoi ?

Gardez le sandbox. Cessez de le traiter comme le contrôle. Puis fermez le passage de témoin, là où se trouve l'exposition réelle.

1. 01

   Inventoriez ce qui lit les fichiers du projet sans rien demander

   C'est l'étape que personne ne fait, et c'est celle que réclame la CSA. Listez les programmes d'un poste de développement qui consomment des fichiers du répertoire de travail et agissent dessus : l'éditeur et ses extensions, le serveur de langage, le client Git, le profil de shell, le runtime de conteneurs, le lanceur de tâches, le watcher de tests. Cette liste est votre vraie surface d'attaque. Le sandbox n'y figure pas.

2. 02

   Préférez les allowlists aux denylists, et modélisez les arguments

   Une denylist exige d'avoir énuméré le système d'exploitation. Une allowlist exige d'avoir énuméré votre propre flux de travail, ce qui est un problème que vous pouvez réellement finir. Et validez ce qu'une commande fait, pas comment elle s'appelle : git show était sur une allowlist à cause de son nom.

3. 03

   Coupez les démons privilégiés

   Aucune session d'agent ne devrait pouvoir joindre le socket Docker, la config Kubernetes ou un point d'accès local plus privilégié qu'elle. Celle-ci est gratuite. Cursor l'a fermée en une version et Gemini CLI a suivi en 0.58.0 ; OpenAI n'a publié aucun correctif pour Codex.

4. 04

   Traitez les écritures de configuration comme des opérations privilégiées

   Une modification de .git/config, de .vscode/, de .claude/, de .cursor/, d'un interpréteur virtualenv ou d'un workflow de CI n'est pas une modification de code. C'est une modification de ce qui va s'exécuter ensuite. Elle mérite un chemin d'approbation différent de celui d'un composant React, et aujourd'hui elle reçoit généralement le même.

5. 05

   Nettoyez l'environnement avant de nettoyer le système de fichiers

   Les variables d'environnement voyagent avec le processus. Un sandbox parfaitement isolé qui hérite d'AWS_SECRET_ACCESS_KEY a isolé le système de fichiers et publié le credential.

6. 06

   Mettez la décision sur l'écriture, pas sur le périmètre

   Chaque point ci-dessus est une mesure de durcissement qu'un chemin déterminé finira par contourner, parce qu'elles sont toutes statiques. Ce qui ferme la classe, c'est d'évaluer l'action au moment où elle a lieu, avec la capacité de la refuser.

Cette dernière étape est là où se situe notre propre produit, alors lisez les trois paragraphes qui suivent en le sachant. Si nous pensons que cela découle des preuves et non de notre feuille de route, c'est que la CSA est arrivée à la même conclusion structurelle sans rien vendre, et que le contournement qu'un utilisateur a laissé dans le propre suivi d'issues d'Anthropic était un hook PreToolUse.

Un hook se place là où le sandbox ne peut pas. Il évalue un appel d'outil avant son exécution, ce qui veut dire qu'il voit l'écriture elle-même : cette session est sur le point de modifier .git/config, ou d'ajouter un core.hooksPath, ou d'éditer un fichier de workflow qui se déclenche sur les forks avec des droits d'écriture, ou d'appeler un outil dont la description a changé depuis hier. Ce sont des événements discrets et inspectables, avec un sujet et un objet. Un sandbox, lui, voit un processus écrire des octets dans un répertoire autorisé et n'a aucune base pour s'y opposer, puisque rien d'interdit ne se produit.

C'est une autre question, pas un mur plus épais. Le sandbox demande « ce processus a-t-il le droit d'être ici ». La barrière demande « cette action précise doit-elle avoir lieu maintenant ». Le Trust Handoff Flaw existe précisément parce que la première question a une réponse satisfaisante pendant que la seconde n'est jamais posée.

Et il se dégrade honnêtement. Les règles dans le contexte de l'agent améliorent ce qu'il propose, ce qui est une amélioration réelle et probabiliste. Les findings dans la boucle font qu'un changement proposé est raisonné contre l'état réel du dépôt. Seul le hook est déterministe, et nous préférons dire lequel des trois est un contrôle plutôt que de laisser croire qu'ils le sont tous. La version large de cet argument est dans la sécurité des agents de code IA.

Questions fréquentes

Le sandbox suffit-il à sécuriser un agent de code IA ?

Non, et les divulgations de 2026 montrent pourquoi avec une clarté rare. Sur les sept évasions reproduites chez Cursor, Codex CLI, Gemini CLI et Antigravity, la plupart n'ont pas consisté à sortir du sandbox. L'agent a écrit un fichier dans son workspace autorisé, et un processus de confiance hors sandbox l'a exécuté plus tard. Le sandbox borne les dégâts d'un processus qui se comporte mal à l'intérieur de la frontière, ce qui vaut la peine d'être en place. Il ne peut rien contre un agent qui se comporte parfaitement et passe sa charge à quelque chose qui n'a jamais été dans la boîte.

Qu'est-ce que le Trust Handoff Flaw ?

C'est le nom que la Cloud Security Alliance a donné, dans une note de recherche du 22 juillet 2026, au schéma qui sous-tend les évasions de sandbox des agents de code en 2026. L'agent reste à l'intérieur de sa frontière et respecte chaque règle, mais écrit un fichier, une configuration de hook, un interpréteur d'environnement virtuel, une entrée de config Git ou une définition de tâche, qu'un autre outil non sandboxé consomme une fois son tour terminé. La note reprend le résumé en une ligne de Pillar : si un agent peut écrire les entrées futures des systèmes, c'est qu'il n'a jamais été sandboxé.

Quels agents de code ont eu des évasions de sandbox en 2026 ?

Les travaux de Pillar Security ont reproduit des évasions chez Cursor, le Codex CLI d'OpenAI, le Gemini CLI de Google et Antigravity de Google, sept au total, dont au moins quatre ont reçu un correctif éditeur, selon le décompte de la CSA. Séparément, la divulgation GitSpawn de Manifold Security du 1er septembre 2026 a couvert goose (CVE-2026-72718, corrigé en 1.44.0), Claude Code (aucun CVE cité : le chemin core.fsmonitor a été corrigé en 2.1.196, un second chemin restait ouvert en 2.1.252), Hermes Agent (CVE-2026-71963), Qwen Code et Grok Build, ces trois derniers étant encore sans correctif à la divulgation. Manifold a aussi trouvé Codex et Cursor vulnérables, tous deux corrigés depuis ; la fiche qu'OpenAI a elle-même publiée pour la faille core.fsmonitor de Codex CLI est CVE-2026-19592, corrigée en 0.131.0.

Un dépôt Git peut-il exécuter du code juste en étant ouvert ?

Oui, s'il vous est parvenu sous forme de fichiers et non par git clone. core.fsmonitor est un réglage de performance Git dont la valeur est une commande que Git exécute pour déterminer quels fichiers ont changé, et Git la lit dans le .git/config du dépôt lui-même. Les agents de code appellent Git au démarrage, donc la commande s'exécute avec les privilèges de l'utilisateur avant qu'aucune fenêtre d'approbation n'apparaisse. C'est le constat de GitSpawn, et Manifold est précis sur la livraison : un clone ordinaire ne transporte pas le .git/config de la source, le dépôt doit donc arriver avec son dossier .git déjà dedans, en archive .zip partagée, dossier synchronisé, disque partagé ou clé USB. Lisez .git/config avant d'ouvrir un tel dossier avec un agent. git config --global core.fsmonitor false n'y change rien, parce que Git lit le fichier du dépôt après le fichier global et que la dernière valeur l'emporte ; seul git -c core.fsmonitor=false, sur la commande elle-même, passe devant.

Faut-il une microVM, gVisor ou un conteneur pour son agent de code ?

Choisissez selon vos contraintes de performance et de GPU, car pour cette classe de menace le choix ne change presque rien. Firecracker donne l'isolation la plus forte, gVisor est un intermédiaire raisonnable avec un noyau en espace utilisateur, et les conteneurs sont le plancher. Aucun des trois ne change le fait qu'une extension Python non sandboxée exécute un interpréteur que l'agent a modifié. Dépensez votre effort de décision sur ce que l'agent a le droit d'écrire et sur les programmes locaux qui lui font confiance, et traitez la primitive d'isolation comme un réglage de rayon d'action.

Activer le réglage sandbox de mon agent le sandboxe-t-il vraiment ?

Vérifiez-le plutôt que de le supposer. En mars 2026, une issue contre Claude Code signalait que sandbox.enabled: true dans ~/.claude/settings.json n'avait aucun effet quand l'agent tournait dans l'extension VS Code ou Cursor, parce que l'extension lançait le binaire natif sans l'option --sandbox et que le profil Seatbelt de macOS n'était donc jamais appliqué. L'auteur l'a confirmé en écrivant dans ~/Desktop depuis une session Cursor. Testez votre propre configuration en tentant une écriture hors du workspace et en observant si elle est refusée.

Qu'est-ce que la sécurité agent-time, et en quoi diffère-t-elle du sandbox ?

Le sandbox pose une question de périmètre : ce processus a-t-il le droit d'être à cet endroit. La sécurité agent-time pose une question d'action : cette opération précise doit-elle avoir lieu maintenant, et elle sait refuser. La différence est décisive face au Trust Handoff Flaw, parce que l'écriture qui cause l'exécution ultérieure n'est pas une violation de périmètre et paraît parfaitement légitime à une couche d'isolation. Une barrière qui évalue l'appel d'outil voit que la cible est .git/config et la décline, ce qu'aucune force d'isolation ne fera.

Cela veut-il dire que les sandbox d'agents ne servent à rien ?

Pas du tout, et les abandonner serait la mauvaise leçon. Un sandbox borne de façon fiable les dégâts d'une dépendance malveillante, d'une commande destructrice ou d'une boucle emballée, et ce sont des cas fréquents. La correction consiste à cesser de le présenter comme un confinement face à un agent adverse. C'est un réducteur de rayon d'action, qui se place à côté du contrôle de sortie réseau, de l'hygiène des credentials et d'un point d'application sur les actions elles-mêmes.