En manipulant les fichiers utilisés ultérieurement par des logiciels fiables, les assistants de codage peuvent franchir efficacement les frontières de sécurité tout en restant confinés.
Les bacs à sable sont devenus un contrôle de sécurité clé pour les agents de codage de l’IA, mais de nouvelles recherches suggèrent qu’ils pourraient ne pas offrir l’isolement supposé par de nombreuses organisations.
Pillar Security a révélé une série de vulnérabilités montrant comment les agents d’outils tels que Cursor, Codex, Gemini CLI et Antigravity peuvent indirectement franchir les frontières de sécurité sans échapper techniquement à leur bac à sable.
« Dans presque tous les cas, l’agent n’a pas eu besoin de casser directement le bac à sable », ont indiqué les chercheurs dans un article de blog. « Il lui suffisait d’écrire quelque chose qu’un composant de confiance en dehors du bac à sable exécuterait, chargerait, analyserait ou considérerait plus tard comme sûr. »
Les résultats ont mis en évidence quatre modes de défaillance spécifiques et reproductibles dans les bacs à sable d’IA. Il s’agissait notamment des sandbox de liste de refus qui ne répondaient pas à la complexité croissante du système d’exploitation, des configurations d’espace de travail se révélant être du code exécutable, des listes d’autorisation de commandes faisant confiance aux noms de commandes au lieu des invocations et des démons locaux privilégiés qui se trouvaient entièrement en dehors du sandbox.
« Les RSSI et les acheteurs de solutions de sécurité doivent comprendre qu’il ne suffit pas qu’un IDE ou une CLI agent dispose d’un bac à sable », ont déclaré les chercheurs, ajoutant qu’il est important de savoir où se situe la limite réelle du bac à sable.
Échapper aux bacs à sable sans les casser
Pillar a remis en question la compréhension de base du sandboxing dans le développement assisté par l’IA. Plutôt que de s’échapper via des exploits du noyau ou des fuites de conteneurs, les attaques démontrées reposaient sur un mécanisme indirect.
Dans tous les chemins d’attaque présentés, l’agent reste confiné tout en produisant des fichiers que les applications côté hôte de confiance consomment ensuite.
Ces fichiers peuvent inclure la configuration de l’espace de travail, des scripts d’automatisation, des paramètres IDE et des contenus d’environnement virtuel qui participent naturellement au flux de travail d’un développeur. Lorsque des outils externes exécutent ou interprètent ultérieurement ces fichiers en dehors du bac à sable, le code provenant de l’environnement isolé franchit effectivement la limite de sécurité sans violer les règles du bac à sable.
Différentes évasions de bac à sable pour différents agents
Pillar a démontré le modèle sur plusieurs outils de codage d’IA en utilisant différentes techniques. Dans Antigravity, les chercheurs ont exploité les faiblesses du profil macOS Seabelt de type liste noire et ont abusé des configurations de tâches VS Code qui ont ensuite été exécutées en dehors du bac à sable. Cursor, quant à lui, s’est avéré faire confiance aux environnements virtuels Python créés par des agents, aux répertoires Git alternatifs et aux configurations de hook d’espace de travail qui s’exécutaient finalement avec les privilèges de l’hôte.
Les chercheurs ont également découvert un chemin d’évacuation commun affectant Cursor, Codex CLI et Gemini CLI via le démon privilégié de Docker Desktop, permettant aux agents en bac à sable d’exécuter des commandes en dehors de leurs environnements restreints.
Dans une autre découverte de la CLI du Codex, une liste autorisée Git supposée sûre pourrait être manipulée pour modifier la configuration du référentiel et déclencher l’exécution de code à un stade ultérieur.
Le développement agent exige un modèle de sécurité différent
Pilar a fait valoir que les entreprises ont besoin d’un nouveau modèle de sécurité pour les logiciels agentiques. Les protections des points de terminaison existantes se concentrent généralement sur la possibilité pour un processus de s’échapper de son environnement d’exécution. Mais les agents autonomes remettent en question cette situation en générant continuellement du contenu que d’autres systèmes de confiance consomment.
Les chercheurs ont recommandé de traiter les configurations d’espace de travail qui peuvent déclencher l’exécution comme des actifs sensibles, nécessitant une approbation explicite avant que les agents créent ou modifient l’automatisation côté hôte, garantissant que les processus d’assistance fonctionnent sous la même politique de sécurité que l’exécution directe de l’agent et préservant la provenance qui distingue les fichiers créés par l’utilisateur du contenu généré par le référentiel ou l’agent.
Il a également été conseillé aux organisations de modéliser les politiques de sécurité autour des effets secondaires des commandes plutôt que de simplement traiter l’appel, de limiter l’accès aux services locaux privilégiés et de surveiller les transferts de confiance tout au long du flux de développement.
