Les frictions entre l’IA haute performance et les frontières de sécurité traditionnelles apparaissent comme un défi majeur dans le développement open source.
L’industrie du logiciel considère le sandboxing de l’IA agentique comme la réponse au déploiement en toute sécurité de systèmes autonomes. Cependant, les approches actuelles sont fondamentalement incomplètes et ne fonctionnent pas lorsque les entreprises les mettent en production à grande échelle.
Alex Zenla, fondateur et directeur technique de la société de sécurité cloud native Edera, considère cette situation comme la pièce manquante de l’histoire du passage de l’expérimentation de l’IA au déploiement dans le monde réel. Edera adopte une approche différente pour sécuriser les environnements d’IA open source.
Alors que d’autres intègrent le sandboxing aux agents d’IA après coup, Edera a construit une couche d’isolation native basée sur un hyperviseur et un conteneur qui offre les mêmes garanties de sécurité et s’adapte à une infrastructure multi-locataires et gourmande en GPU. L’approche de l’entreprise suppose que les systèmes seront compromis et impose une isolation au niveau de l’exécution avec une surcharge proche de zéro.
Edera s’associe à des fournisseurs de cloud de nouvelle génération et à des équipes d’infrastructure d’IA pour déterminer comment opérationnaliser l’IA en toute sécurité sans introduire de risque catastrophique.
« Ce que nous avons construit est ce que nous appelons un environnement d’exécution renforcé – une isolation qui suppose un compromis dès le départ – de sorte que lorsqu’un agent fait quelque chose d’inattendu, le rayon d’explosion est déjà contenu », a déclaré Zenla à LinuxInsider.
Correction des limites d’isolement de l’espace utilisateur
La plupart des sandboxing IA actuels reposent sur l’isolation de l’espace utilisateur ou sur des conteneurs de base. Cette approche échoue lorsqu’un agent dispose d’autorisations de haut niveau ou d’un accès à des ensembles d’outils sensibles.
Zenla a expliqué que l’espace utilisateur et l’isolation de base des conteneurs reposent sur les primitives du noyau Linux : espaces de noms, groupes de contrôle, LSM. Un bug critique dans le noyau Linux peut compromettre l’isolation des processus et des conteneurs, ainsi que toute autre défense d’exécution du conteneur telle que eBPF, seccomp et AppArmor.
« Les agents sont très capables de trouver des bugs. Si vous demandez à un agent de sortir d’un conteneur, il peut trouver les bugs pour le faire », a-t-elle déclaré.
Pour prouver ce point, Zenla a cité un test papier SandboxEscapeBench de neuf modèles de langage larges frontières (LLM) par rapport à 18 scénarios d’évasion de conteneurs. Claude Opus 4.5 et GPT-5 ont chacun échappé aux conteneurs environ la moitié du temps dans des environnements de test contrôlés. Dans les erreurs de configuration courantes telles que les sockets Docker exposés, les conteneurs privilégiés et les supports d’hôte inscriptibles, les modèles Frontier ont atteint un taux d’échappement de 100 %.
Les Frontier LLM sont les modèles d’IA de pointe les plus performants disponibles aujourd’hui. Leurs performances sont caractérisées par des capacités à grande échelle et à usage général en matière de raisonnement, de codage et de compréhension multimodale.
Où le sandboxing s’arrête à grande échelle
Un scénario d’échec courant se produit lorsqu’un développeur tente de déplacer un agent IA en bac à sable d’une expérience mono-utilisateur vers un environnement de production avec des milliers de sessions simultanées et multi-locataires. En production, les environnements multi-locataires s’appuient sur le noyau Linux comme frontière de sécurité entre les locataires.
« Chaque agent partage le même noyau, donc lors de milliers de sessions simultanées, chaque co-tenant devient un autre attaquant contre le même noyau », a ajouté Zenla.
La soi-disant clé du royaume de la sécurité réside en production dans la mémoire d’un conteneur – et donc du noyau Linux, a-t-elle expliqué.
« Un seul bug exploité dans le noyau partagé a un rayon d’action qui affecte chaque secret, clé de chiffrement et données client sur l’ensemble d’un nœud. Souvent, ces secrets conduisent à une prise de contrôle de l’ensemble de l’environnement du cluster », a averti Zenla.
Les organisations fonctionnant à grande échelle ont besoin d’une fourniture continue de calcul. Cette fonctionnalité nécessite d’exécuter des charges de travail d’inférence sans interruption, même lorsqu’un agent est compromis.
« C’est impossible lorsque votre limite de sécurité est le noyau partagé », a-t-elle déclaré.
Cette limitation devient encore plus prononcée dans les environnements gourmands en GPU. Le relais GPU (unité de traitement graphique) permet à une machine virtuelle d’accéder directement à un GPU PCIe physique, en contournant le système d’exploitation hôte pour fournir des performances quasi natives.
La sécurité du GPU est à la traîne par rapport aux processeurs
Selon Zenla, la sécurité des GPU a dix ans de retard sur la virtualisation des CPU (unité centrale de traitement) aujourd’hui. Les fournisseurs de cloud s’empressent de déployer des capacités GPU sans les primitives d’isolation correspondantes.
« Edera pour GPU a été spécialement conçu pour combler cette lacune, en apportant une isolation matérielle aux charges de travail GPU de la même manière que les hyperviseurs ont transformé la sécurité du processeur », a-t-elle proposé.
Pour ce faire, Edera utilise un hyperviseur de type 1 qui s’exécute directement sur le matériel afin de réduire le nombre de sauts requis pour activer le relais. Cette approche simplifie la configuration et la configuration du GPU.
Edera contrôle également l’accès à l’unité de gestion de la mémoire d’E/S (IOMMU) à un niveau bas, permettant des temps de démarrage plus rapides et une réduction des frais généraux. Ce composant matériel traduit les adresses virtuelles visibles par l’appareil en adresses physiques.
« En faisant cela dans la couche hyperviseur plutôt que sur le système hôte et dans l’espace utilisateur, nous maintenons d’excellentes performances tout en fonctionnant sur une très petite surface d’attaque. Vous n’avez plus une grande surface d’attaque comme QEMU dans le processus de gestion du GPU », a ajouté Zenla.
Réduire les risques liés aux locataires multiples
Dans un monde où les agents IA partagent une infrastructure physique, la couche basée sur l’hyperviseur d’Edera répond à un élément de sécurité clé que les méthodes de sandboxing actuelles négligent. Les attaques par voisins bruyants ou par canal secondaire se produisent lorsqu’un locataire dans un environnement partagé (multi-tenant) monopolise les ressources, dégradant ainsi les performances des autres utilisateurs de la même infrastructure.
Zenla a noté qu’un locataire malveillant peut déduire ce que font les autres locataires en observant l’état partagé. L’allocation des ressources de l’hyperviseur atténue ces problèmes. Tout agent accidentel ou malveillant qui commence à consommer des ressources de calcul se heurte à des barrières d’allocation de processeur virtuel et de mémoire qui saturent la charge de travail sans impacter le reste des ressources du locataire.
« Avec Edera, nous éliminons cette classe d’attaque car chaque charge de travail possède son propre noyau. Un hyperviseur peut épingler les locataires sur des cœurs de processeur spécifiques et leur fournir leur propre noyau Linux. Cela atténue les attaques de cache entre locataires et de prédicteurs de branche », a-t-elle déclaré.
Risques cachés dans l’infrastructure d’IA
Zenla a averti que, alors que les fournisseurs de cloud se précipitent pour mettre en place une infrastructure d’IA, le compromis de sécurité qu’ils acceptent tranquillement est que l’isolation du GPU est moins mature que l’isolation du CPU. Les fournisseurs s’empressent de fournir des capacités GPU pour l’IA, et les GPU sont essentiellement leurs propres systèmes distribués qui contournent les protections standard du système d’exploitation.
Lorsqu’elle entend des descriptions de produits prétendant contourner le processeur et le système d’exploitation, Zenla note l’absence de protections de base, notamment la protection de la mémoire virtuelle, les contrôles de sécurité du noyau, les pare-feu, les politiques réseau et la visibilité eBPF. En plus de cela, de nombreux pilotes GPU fonctionnent comme de gros composants propriétaires à source fermée avec des privilèges au niveau du noyau (anneau 0), le niveau de privilège le plus élevé sur le processeur.
« Un bug dans l’un de ces modules du noyau donne à un attaquant un accès complet à la mémoire du noyau sur l’hôte », a-t-elle conclu.
