Des chercheurs de Lasso ont constaté que l’isolation d’agents d’IA autonomes pourrait ne pas suffire à empêcher le vol de données sensibles, après avoir démontré plusieurs techniques d’exfiltration contre les environnements NemoClaw et OpenShell de NVIDIA.
Les résultats montrent comment des attaquants peuvent détourner des outils de confiance et des connexions sortantes autorisées pour dérober discrètement des identifiants, manipuler le comportement des agents et maintenir leur persistance au sein des environnements d’exécution de l’IA.
« Au cours des derniers mois, nous avons constaté une forte hausse du nombre de salariés qui créent et déploient des agents d’IA personnels au sein des entreprises, souvent sans même que leur organisation en ait connaissance », a déclaré Noy Pearl, chercheuse en IA et sécurité chez Lasso, dans un e-mail envoyé à eSecurityPlanet.
Elle a expliqué : « Cette recherche montre que restreindre l’environnement d’un agent n’élimine pas le risque lorsque celui-ci peut prendre des décisions de manière autonome, accéder à des ressources connectées et interagir avec des systèmes externes. »
Noy a ajouté : « Les caractéristiques mêmes qui rendent les agents d’IA utiles dans les environnements de production sont celles que les adversaires chercheront à cibler. »
Principaux enseignements de l’étude sur les environnements isolés d’IA
- Les chercheurs ont démontré que l’isolation des environnements d’IA ne suffit pas nécessairement à empêcher l’exfiltration de données depuis des agents d’IA autonomes.
- Les attaques ont détourné des outils de confiance tels que GitHub, npm et des binaires autorisés, plutôt que d’exploiter une vulnérabilité logicielle traditionnelle.
- Des données sensibles, notamment des clés d’API, des variables d’environnement et des identifiants OpenClaw, pouvaient être exfiltrées par des canaux sortants autorisés.
- Une attaque de démonstration a établi une persistance et modifié le comportement de l’agent d’IA au moyen d’un empoisonnement de la configuration de l’agent.
- Ces résultats mettent en évidence les préoccupations croissantes concernant la sécurité de la chaîne d’approvisionnement de l’IA, les flux de travail de confiance et la gestion des risques liés aux agents autonomes.
Les attaques contre l’environnement isolé d’IA de NemoClaw
Cette recherche met en évidence les risques de sécurité croissants auxquels s’exposent les entreprises qui déploient des agents d’IA autonomes capables d’installer des paquets, d’accéder à des fichiers et d’exécuter du code avec un contrôle minimal.
Bien que l’OpenShell de NVIDIA utilise une isolation fondée sur Kubernetes et des contrôles de règles pour isoler les charges de travail d’IA, les chercheurs ont constaté que ses fonctionnalités de confiance pouvaient toujours être détournées à des fins malveillantes.
Le problème tient principalement au fait que les agents d’IA autonomes doivent interagir avec des outils et des services externes pour rester utiles.
Des opérations telles que l’exécution de npm install, l’accès à des dépôts GitHub, l’exécution de scripts et la communication avec des API nécessitent intrinsèquement une connectivité sortante et l’accès à des binaires autorisés.
Les chercheurs ont découvert que des attaquants pouvaient détourner ces flux de travail légitimes pour exfiltrer discrètement des données sensibles depuis l’environnement isolé, sans contourner directement les contrôles de sécurité d’OpenShell.
Ces résultats renforcent les préoccupations plus générales liées à la sécurité de la chaîne d’approvisionnement de l’IA et à l’évolution du modèle de confiance applicable aux agents autonomes.
Contrairement aux applications traditionnelles, qui opèrent dans des limites relativement prévisibles, les agents d’IA récupèrent fréquemment du code depuis des dépôts publics, installent dynamiquement des paquets et prennent en temps réel des décisions opérationnelles de manière autonome.
Ce comportement élargit la surface d’attaque et offre aux acteurs malveillants de nouvelles possibilités d’exploiter des flux de développement de confiance.
Des attaques de démonstration ont exploité des flux de travail de confiance
Les chercheurs ont décrit deux scénarios d’attaque de démonstration qui exploitaient des canaux de communication autorisés par les règles, plutôt qu’une vulnérabilité d’OpenShell lui-même.
Dans le premier scénario, un dépôt GitHub contrôlé par l’attaquant fournissait un script postinstall.sh malveillant lors d’un processus npm install de routine.
Le script utilisait une obfuscation fondée sur des émojis pour reconstruire à l’exécution un jeton GitHub encodé, ce qui lui permettait d’échapper à la fois aux protections de détection des secrets de GitHub et aux mécanismes de détection d’OpenClaw.
Une fois décodé, le jeton permettait au script d’utiliser les binaires git et gh autorisés pour créer une pull request contenant des fichiers sensibles dérobés à l’environnement isolé.
Les chercheurs ont identifié /sandbox/.openclaw/openclaw.json comme une cible particulièrement intéressante, car ce fichier stocke en clair les identifiants OpenClaw et les clés d’API.
Cependant, la surface d’attaque ne se limitait pas à un seul fichier.
Les chercheurs ont averti que des variables d’environnement, des jetons d’API, des identifiants cloud et des clés de plateformes d’IA pouvaient également être exfiltrés par des canaux sortants autorisés.
Exfiltration persistante et empoisonnement de la configuration de l’agent
Le deuxième scénario a montré comment des attaquants pouvaient établir une exfiltration persistante et manipuler à long terme l’agent d’IA lui-même au moyen d’un paquet NPM malveillant.
Après son installation, le paquet déployait une tâche cron qui sondait en continu les règles OpenShell afin d’identifier les binaires autorisés et les domaines autorisés pour les communications sortantes.
Le logiciel malveillant modifiait également le fichier de configuration SOUL.md de l’agent afin d’altérer son comportement futur — une technique que les chercheurs ont décrite comme un « empoisonnement de la configuration de l’agent ».
L’attaquant pouvait ainsi potentiellement influencer les décisions futures prises par l’agent d’IA, notamment en l’orientant vers des paquets malveillants ou en manipulant sa manière de répondre aux invites.
Point important : les attaques ont réussi sans enfreindre les règles OpenShell configurées.
Elles ont au contraire détourné des capacités que l’environnement isolé était précisément conçu pour autoriser dans le cadre des opérations normales de l’IA, notamment l’installation de dépendances, l’accès à GitHub, la gestion des paquets et la communication avec des API externes.
Cette recherche souligne une limite essentielle des modèles d’isolation fondés sur des règles : s’ils peuvent restreindre les destinations avec lesquelles un agent d’IA communique, ils ne peuvent pas déterminer l’intention qui sous-tend ses actions dès lors que des outils de confiance et des voies d’accès autorisées sont disponibles.
Comment les entreprises peuvent réduire les risques liés à l’IA
Les entreprises qui expérimentent avec des agents d’IA autonomes devraient éviter de considérer l’isolation comme un contrôle de sécurité autonome.
- Restreindre la connectivité sortante, les binaires et l’accès à Internet aux seules ressources nécessaires aux opérations autorisées des agents d’IA.
- Mettre en œuvre des contrôles d’accès fondés sur le principe du moindre privilège et stocker les identifiants dans des plateformes sécurisées de gestion des secrets, en utilisant des jetons à courte durée de vie plutôt que des clés en clair.
- Surveiller les environnements d’exécution de l’IA pour détecter tout comportement anormal, notamment les installations suspectes de paquets, les modifications de configuration non autorisées, les tentatives d’injection d’invites et les activités inhabituelles au niveau des API.
- Utiliser des dépôts internes contrôlés, la vérification des dépendances et la signature cryptographique afin de réduire les risques liés à la chaîne d’approvisionnement logicielle et aux paquets malveillants.
- Déployer des environnements isolés éphémères, une surveillance de l’intégrité des fichiers et une segmentation réseau afin de limiter les possibilités de persistance et de déplacement latéral.
- Exiger l’approbation humaine pour les actions sensibles telles que l’exécution de code, l’installation de dépendances, les modifications de dépôts et les changements apportés à l’infrastructure.
- Tester les plans de réponse aux incidents et utiliser des outils de simulation d’attaques avec des scénarios portant sur les attaques visant les agents d’IA.
Ensemble, ces mesures peuvent aider les entreprises à renforcer leur résilience face aux menaces visant les agents d’IA, tout en réduisant l’exposition inutile dans les environnements de développement autonomes.
Les environnements isolés d’IA montrent leurs limites
La recherche consacrée à NemoClaw reflète les évolutions plus larges actuellement à l’œuvre dans les domaines de l’IA et de la cybersécurité.
Les environnements isolés traditionnels ont été conçus pour des applications prévisibles opérant dans des limites définies.
Les agents d’IA autonomes posent de nouveaux défis, car ils interagissent régulièrement avec des outils externes, des dépôts et du code tiers tout en prenant des décisions de manière autonome et en temps réel.
À mesure que les assistants de programmation basés sur l’IA et les systèmes agentiques se généralisent, les entreprises s’appuient de plus en plus sur des flux de travail liés à des dépôts GitHub, aux paquets npm et à des intégrations externes.
Selon les chercheurs, cette évolution élargit la surface d’attaque potentielle et met en évidence les limites d’une sécurisation des environnements autonomes d’IA reposant uniquement sur une isolation fondée sur des règles.
Les résultats renforcent également la raison pour laquelle les entreprises s’appuient sur le modèle de confiance zéro afin de réduire les risques et d’améliorer la visibilité dans les environnements autonomes d’IA.