Quatre agents de code sortis sans forcer la moindre barrière

Trois chercheurs ont passé des mois à ne pas attaquer le bac à sable

Eilon Cohen, Dan Lisichkin et Ariel Fogel, de Pillar Security, se sont posé une question très précise sur les bacs à sable livrés avec les agents de code à IA. Non pas si les murs tiennent, mais s'ils sont bâtis au bon endroit. Le 20 juillet 2026, ils ont commencé à publier leur réponse sous la forme d'une série intitulée Week of Sandbox Escapes, à raison d'un article par jour, consacrée à Cursor, à la CLI OpenAI Codex, à la CLI Google Gemini et à Google Antigravity.

Dans chaque cas, l'agent s'est comporté correctement. Il est resté dans l'espace de travail qu'on lui avait attribué et n'a violé aucune règle appliquée par le bac à sable. Il a écrit un fichier. Un processus extérieur au bac à sable a ensuite lu ce fichier, lui a accordé sa confiance et a exécuté ce qu'il y trouvait. L'évasion a eu lieu sans que l'agent effleure jamais la frontière.

Pillar résume la démonstration en une ligne : le rayon d'impact d'un agent, ce n'est pas le processus de l'agent, c'est tout ce que l'agent peut écrire et que l'hôte tiendra ensuite pour fiable. Cette phrase est l'essentiel, et elle explique pourquoi corriger les failles une à une ne referme pas le dossier.

Un socket suffit à expliquer trois des quatre produits

La faille la plus nette est aussi la moins exotique. Codex CLI, Cursor et Gemini CLI pouvaient tous atteindre le socket Docker local depuis l'intérieur de leur bac à sable. Un démon privilégié sur l'hôte démarre un conteneur pour quiconque parvient à lui parler, et ce conteneur s'exécute entièrement hors du bac à sable. Un seul avis de sécurité, GHSA-v4xv-rqh3-w9mc, couvre trois des quatre produits testés. Il est corrigé.

Codex présentait un second défaut, de nature différente. Sa liste blanche de commandes sûres accordait sa confiance aux commandes d'après leur nom. Elle autorisait git show comme opération de lecture seule sans jamais modéliser ce que des arguments dangereux passés à git show permettent réellement de faire. Le correctif figure dans la version 0.95.0, et le signalement a valu à ses auteurs une prime de gravité élevée.

Lus ensemble, ces deux cas laissent apparaître le même schéma. Ce sont deux listes blanches. Toutes deux ont été rédigées à partir de ce qu'un exploitant peut voir, un chemin de socket et un nom de commande, et non à partir de ce que ces objets rendent possible une fois qu'on les atteint.

Les évasions sont passées par des fichiers auxquels votre éditeur se fie déjà

Cursor en a fourni trois. Un agent pouvait réécrire l'interpréteur d'un environnement virtuel Python, puis attendre que l'extension Python de l'éditeur, qui s'exécute hors bac à sable, le lance à sa place. Il pouvait créer un répertoire Git sous un nom non standard, de sorte que les règles de bac à sable fondées sur les chemins ne correspondaient plus, et laisser fsmonitor s'en saisir. Il pouvait enfin déposer dans l'espace de travail une configuration de hooks que l'outillage exécutait sans isolement. Cette dernière porte le CVE-2026-48124 et l'avis GHSA-pc9j-3qc2-95wv, et les trois sont corrigées dans Cursor 3.0.0.

Les deux failles de Google relèvent de la même famille. Le profil Seatbelt de macOS qui protège Antigravity avait été rédigé comme une liste de blocage, laquelle autorise tout ce qui n'y est pas nommé explicitement, et une configuration de tâches .vscode parvenait à franchir les protections du Secure Mode. Google a salué auprès des chercheurs la qualité exceptionnelle du rapport, avant de classer les failles comme difficiles à exploiter parce qu'elles supposent de l'ingénierie sociale, et de les déclasser sur ce fondement.

Le classement se défend dans sa propre logique, mais il ne change rien pour qui exploite ces outils au quotidien. Pour un agent, l'ingénierie sociale tient en une phrase dans un README, un commentaire sur un ticket ou un paragraphe dans la documentation d'une dépendance. Lire du texte non fiable, c'est la journée de travail ordinaire d'un agent.

La frontière que vous avez achetée n'est pas celle dont vous disposez

Chacun de ces produits présente le bac à sable comme le contrôle qui rend le codage autonome acceptable. C'est la réponse que reçoit toute revue de sécurité, et c'est ce qui a motivé les autorisations accordées. La recherche montre que le bac à sable ne gouverne qu'une chose, le processus de l'agent. Il n'a jamais rien promis quant à l'espace de travail.

La vraie surface d'exposition, c'est l'espace de travail, parce qu'il est lu par une longue liste de processus conçus des années avant les agents, qui partent tous du principe qu'un humain a tapé ce qu'ils lisent. L'extension Python. Le démon Git. Le socket Docker. Le hook de pre-commit. L'installateur de dépendances. Le runner de CI qui clone la branche. Aucun n'a été conçu pour traiter le contenu d'un dépôt comme une entrée hostile, et c'est pourtant exactement ce que chacun d'eux fait aujourd'hui.

L'objet de la gouvernance est donc mal choisi. Les propriétaires d'entreprise ont pris l'habitude d'approuver des agents. Ce qui appelle une politique, c'est l'espace de travail, et la règle tient en peu de mots : un dépôt dans lequel un agent d'IA peut écrire est une entrée non fiable pour tous les processus situés en aval, au même titre qu'un fichier téléversé par un inconnu.

Ce qu'il faut changer cette semaine

Commencez par le socket, puisqu'un seul avis couvrait trois des quatre produits. Aucun agent de code n'a besoin d'accéder à un socket Docker, et le lui retirer relève du paramétrage, pas du projet. Passez ensuite aux versions. Cursor 3.0.0 et Codex CLI 0.95.0 sont les lignes corrigées, et les outils de développement se mettent à jour utilisateur par utilisateur plutôt qu'à l'échelle du parc : qu'un éditeur publie un correctif ne signifie pas que vos ingénieurs le détiennent.

Le changement qui dure porte sur l'endroit où tournent les agents. Une branche qu'un agent a touchée devrait arriver dans la CI avec le statut de source non fiable, ce qui revient en pratique à ce que la chaîne n'exécute ni hooks, ni tâches, ni interpréteurs issus de cette branche tant qu'un humain n'a pas approuvé le diff. C'est une décision de chaîne plutôt que d'outil, et elle survivra à la prochaine divulgation.

Au titre de NIS2, un incident qui commence dans l'éditeur d'un développeur et se termine dans votre chaîne de production doit être notifié dans les mêmes délais que n'importe quel autre. L'obligation ne fait pas de différence entre un attaquant qui a hameçonné un ingénieur et un agent qui a lu un README empoisonné, si bien que le contrôle doit se placer là où la chaîne peut l'imposer.

À lire ensuite: Le correctif nginx est là, l'exploit arrive en août  |  ServiceNow a corrigé son cloud d'abord, vous 103 jours plus tard