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é. 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 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.

Cloner un dépôt suffit désormais. 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.

Deux 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 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. Si votre contrôle est « on a mis à jour », votre contrôle porte un numéro de version et contient une situation de course.

La mitigation recommandée par Manifold vaut la peine d'être appliquée dès aujourd'hui, tient en une commande, et illustre bien à quel point un correctif par problème est étroit :

# Auditer un depot que vous vous appretez a ouvrir avec un agent
git config --get core.fsmonitor

# Desactiver le mecanisme globalement
git config --global core.fsmonitor false

# Ou le neutraliser sur les appels en arriere-plan
git -c core.fsmonitor=false status

Cela ferme core.fsmonitor. 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, et le contournement proposé était de lancer la CLI directement ou d'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.

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.

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.

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 et elle a supprimé une classe entière chez trois produits.

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.

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.

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 suggéré 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 le résume ainsi : 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. Séparément, la divulgation GitSpawn de Manifold Security en septembre 2026 a couvert goose (CVE-2026-72718), Codex (CVE-2026-19592), Claude Code (CVE-2026-55607) et Hermes Agent (CVE-2026-71963), Qwen Code et Grok Build étant également confirmés vulnérables au moment de la divulgation.

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

Oui, et c'est le constat de GitSpawn. 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. L'audit tient en une commande, git config --get core.fsmonitor, et la désactivation globale en git config --global core.fsmonitor false.

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.