Agents IA : sept failles font sauter les sandboxes

Sept chemins d’évasion, quatre agents de programmation et une même brèche conceptuelle : le logiciel reste enfermé, mais ce qu’il écrit peut sortir à sa place. Le 20 juillet 2026, les chercheurs de Pillar Security ont publié la synthèse de plusieurs mois de tests menés sur Cursor, Codex CLI, Gemini CLI et Antigravity. Leur démonstration ne repose pas sur une intelligence artificielle qui fracasse directement les murs de sa sandbox. Elle montre un agent autorisé à déposer un fichier dans le projet, puis un outil de confiance situé à l’extérieur qui lit ce fichier et exécute son contenu.

Cette nuance change tout pour les équipes qui confient déjà du code, des dépôts et des tâches d’automatisation à des agents. Un README piégé, une issue, une dépendance ou un diff peut contenir une injection de prompt indirecte. Si l’agent la suit, une configuration apparemment banale peut devenir le relais vers le poste du développeur, où se trouvent souvent clés SSH, jetons cloud et accès de publication. La plupart des problèmes décrits ont été corrigés ou reconnus par les éditeurs, et leur exploitabilité varie. Mais leur répétition dans trois écosystèmes différents révèle un défaut plus profond qu’un simple bug isolé.

Une sandbox classique surveille ce que le processus de l’agent peut lire, écrire ou lancer. Pillar a testé la couture voisine : ce que d’autres composants font ensuite avec les fichiers que l’agent avait parfaitement le droit de créer. Les chercheurs regroupent leurs sept constats en quatre familles : profils d’interdiction incomplets, configuration de projet réellement exécutable, listes de commandes supposées sûres et démons locaux privilégiés accessibles depuis l’environnement confiné.

Le scénario Cursor illustre la mécanique. Un agent pouvait écrire une configuration de hook compatible avec Claude dans le workspace. À la fin du tour, le moteur de hooks de l’éditeur la chargeait dans le contexte local et lançait la commande sans la médiation attendue de la sandbox. L’avis GHSA-pc9j-3qc2-95wv rattache ce problème à la CVE-2026-48124, lui attribue un score CVSS 4.0 de 8,5 sur 10 et indique que Cursor 3.0.0 contient le correctif. Le fichier ne traversait donc pas physiquement une frontière interdite : il devenait l’instruction d’un lecteur plus puissant.

Ce mécanisme compte parce que les projets modernes sont remplis de configurations actives. Les extensions cherchent automatiquement un interpréteur Python, Git peut appeler des helpers ou des hooks, VS Code peut charger des tâches, et Docker expose un service capable d’agir sur l’hôte. Chacun apporte de la productivité. Ensemble, ils forment une chaîne de confiance que le mot « sandbox » ne suffit plus à résumer.

Dans Codex CLI, la recherche décrit une liste d’autorisation qui jugeait « git show » sûr en se fondant sur le nom de la commande, sans modéliser tous ses arguments ni les effets secondaires de Git. Pillar affirme qu’OpenAI a corrigé le problème dans la version 0.95.0 et versé une prime de sévérité élevée; la CVE restait en attente au moment de la publication. Il faut distinguer cette faille du constat lié à Docker, classé informatif pour Codex : les décisions de sévérité et les modèles de menace ne sont pas uniformes.

Un second chemin concernait simultanément Codex, Cursor et Gemini CLI. L’accès à un socket Docker permettait à un agent pourtant confiné de demander à un démon privilégié d’exécuter une opération hors de sa boîte. Le principe ressemble à une porte sécurisée dont l’interphone commanderait une grue placée de l’autre côté : la porte tient, mais le service joignable depuis l’intérieur déplace quand même ce qu’elle devait protéger. Pillar indique que ce chemin a été corrigé.

Pour Antigravity, les chercheurs ont rapporté un contournement du profil Seatbelt sur macOS et une tâche VS Code susceptible d’être exécutée par l’hôte. Selon leur compte rendu, Google a accepté les deux signalements comme vulnérabilités valides, tout en les rétrogradant parce qu’ils exigeaient de l’ingénierie sociale ou la confiance accordée à un dépôt contenant une injection indirecte. Cette réserve est importante : une preuve de concept n’équivaut ni à une campagne d’attaque observée ni à une compromission automatique de tous les utilisateurs.

Le déclencheur commun est l’injection de prompt indirecte. Au lieu de convaincre directement l’utilisateur d’exécuter une commande, un attaquant place une instruction dans un contenu que l’agent doit analyser. Le risque apparaît quand trois conditions se rencontrent : l’agent interprète l’instruction, il peut écrire une configuration active, puis un composant extérieur consomme cette configuration avec davantage de privilèges. Retirer une seule de ces étapes casse la chaîne.

Les entreprises peuvent donc agir sans attendre une solution magique. Elles doivent maintenir les agents à jour, isoler davantage les dépôts inconnus, limiter l’accès aux sockets et services locaux privilégiés, et soumettre les hooks, tâches et configurations exécutables à une approbation dédiée. Les journaux devraient relier la provenance d’un fichier à l’action déclenchée ensuite. Sans cette traçabilité, l’exécution semble venir de Git, de l’IDE ou de Docker alors que son origine réelle est un artefact produit par l’agent.

Cette alerte prolonge un résultat publié en avril par Cymulate sur les évasions fondées sur la configuration dans Claude Code, Gemini CLI et Codex CLI. Elle rejoint aussi les travaux académiques récents sur les injections de données contre des agents réels. Le nouveau signal n’est donc pas que toute automatisation serait dangereuse, mais que plusieurs équipes indépendantes retrouvent la même rupture entre l’auteur confiné et le lecteur privilégié.

Les éditeurs ont intérêt à préserver la vitesse qui rend leurs agents attractifs. Trop de confirmations transforment l’automatisation en succession de fenêtres d’autorisation; trop peu rendent invisibles les passages de relais. La réponse robuste consiste à évaluer l’invocation complète et ses effets, à traiter les configurations exécutables comme du code, et à appliquer aux helpers la même politique qu’aux commandes lancées directement par l’agent.

Les utilisateurs, eux, ne doivent pas conclure que les quatre produits sont équivalents ou actuellement vulnérables de la même manière. Une CVE notée 8,5 et corrigée dans Cursor 3.0.0 n’a pas le même statut qu’un constat informatif autour d’un socket Docker ou qu’un rapport accepté puis rétrogradé. La publication de Pillar documente une famille de défaillances; elle ne fournit pas de mesure comparative exhaustive de la sécurité globale des produits.

Le 20 juillet marque toutefois un basculement utile : l’agent ne peut plus être considéré comme un simple processus enfermé dans une boîte. Son périmètre réel inclut tous les fichiers qu’il façonne et tous les services qui leur font confiance ensuite. Les correctifs ferment sept chemins précis. La prochaine bataille consiste à rendre visible et contrôlable chaque passage entre une production de l’IA et une action privilégiée sur l’hôte.