Luisa Crawford
30 janvier 2026 16h35
L'équipe AI Red Team de NVIDIA publie des contrôles de sécurité obligatoires pour les agents d'IA de codage, abordant les attaques par injection de prompt et les vulnérabilités d'échappement de sandbox.
L'équipe AI Red Team de NVIDIA a publié le 30 janvier un cadre de sécurité complet ciblant un angle mort croissant dans les flux de travail des développeurs : les agents d'IA de codage fonctionnant avec les permissions complètes de l'utilisateur. Cette directive arrive alors que le marché de la sandbox de sécurité réseau atteint 368 milliards de dollars et que des vulnérabilités récentes comme CVE-2025-4609 rappellent à tous que les échappements de sandbox restent une menace réelle.
Le problème principal ? Les assistants de codage pilotés par l'IA comme Cursor, Claude et GitHub Copilot exécutent des commandes avec les accès dont dispose le développeur. Un attaquant qui empoisonne un dépôt, glisse des instructions malveillantes dans un fichier .cursorrules ou compromet une réponse de serveur MCP peut détourner entièrement les actions de l'agent.
Trois Contrôles Non Négociables
Le cadre de NVIDIA identifie trois contrôles que l'équipe Red Team considère comme obligatoires — pas des suggestions, mais des exigences :
Verrouillage de sortie réseau. Bloquer toutes les connexions sortantes sauf vers les destinations explicitement approuvées. Cela empêche l'exfiltration de données et les shells inversés. L'équipe recommande l'application d'un proxy HTTP, des résolveurs DNS désignés et des listes de refus au niveau entreprise que les développeurs individuels ne peuvent pas outrepasser.
Écritures de fichiers uniquement dans l'espace de travail. Les agents ne doivent toucher à rien en dehors du répertoire de projet actif. Écrire dans ~/.zshrc ou ~/.gitconfig ouvre des portes pour des mécanismes de persistance et des échappements de sandbox. NVIDIA veut une application au niveau du système d'exploitation ici, pas des promesses au niveau applicatif.
Protection des fichiers de configuration. Celui-ci est intéressant — même les fichiers à l'intérieur de l'espace de travail nécessitent une protection s'ils sont des fichiers de configuration d'agent. Les hooks, définitions de serveur MCP et scripts de compétences s'exécutent souvent en dehors des contextes de sandbox. La directive est claire : aucune modification d'agent de ces fichiers, point final. Modifications manuelles de l'utilisateur uniquement.
Pourquoi Les Contrôles Au Niveau Applicatif Échouent
L'équipe Red Team présente un argument convaincant pour l'application au niveau du système d'exploitation plutôt que les restrictions au niveau applicatif. Une fois qu'un agent génère un sous-processus, l'application parente perd la visibilité. Les attaquants enchaînent régulièrement des outils approuvés pour atteindre ceux qui sont bloqués — appelant une commande restreinte via un wrapper plus sûr.
macOS Seatbelt, Windows AppContainer et Linux Bubblewrap peuvent appliquer des restrictions sous la couche applicative, capturant les chemins d'exécution indirects que les listes d'autorisation manquent.
Les Recommandations Plus Difficiles
Au-delà du trio obligatoire, NVIDIA décrit des contrôles pour les organisations avec une tolérance au risque plus faible :
Virtualisation complète — VM, conteneurs Kata ou unikernels — isole le noyau sandbox de l'hôte. Les solutions à noyau partagé comme Docker laissent les vulnérabilités du noyau exploitables. La surcharge est réelle mais souvent éclipsée par la latence d'inférence LLM de toute façon.
Injection de secrets plutôt qu'héritage. Les machines des développeurs sont chargées de clés API, d'identifiants SSH et de tokens AWS. Démarrer des sandboxes avec des ensembles d'identifiants vides et injecter uniquement ce qui est nécessaire pour la tâche actuelle limite le rayon d'explosion.
La gestion du cycle de vie empêche l'accumulation d'artefacts. Les sandboxes de longue durée collectent des dépendances, des identifiants en cache et du code propriétaire que les attaquants peuvent réutiliser. Les environnements éphémères ou la destruction planifiée résolvent ce problème.
Ce Que Cela Signifie Pour Les Équipes De Développement
Le timing compte. Les agents d'IA de codage sont passés de nouveauté à nécessité pour de nombreuses équipes, mais les pratiques de sécurité n'ont pas suivi le rythme. L'approbation manuelle de chaque action crée une habituation — les développeurs valident automatiquement les demandes sans les lire.
L'approche à plusieurs niveaux de NVIDIA offre une voie médiane : des listes de refus d'entreprise qui ne peuvent pas être outrepassées, lecture-écriture d'espace de travail sans friction, des listes d'autorisation spécifiques pour l'accès externe légitime, et refus par défaut avec approbation au cas par cas pour tout le reste.
Le cadre évite explicitement d'aborder la précision de sortie ou la manipulation adversariale des suggestions d'IA — celles-ci restent des responsabilités de développeur. Mais pour le risque d'exécution qui vient du fait de donner aux agents d'IA un accès système réel ? C'est la directive publique la plus détaillée disponible de l'équipe de sécurité d'un fournisseur majeur.
Source de l'image : Shutterstock
Source : https://blockchain.news/news/nvidia-ai-agent-security-framework-sandbox-controls
