Exécuter du code généré par l’IA : Ray et gVisor renforcent l’isolation

Google Cloud et Anyscale proposent une bibliothèque expérimentale qui intègre des environnements gVisor aux clusters Ray. L’objectif est précis : permettre à des agents, des pipelines de post-entraînement ou des systèmes de génération de code d’exécuter des opérations dynamiques sans donner à ce code un accès direct à l’hôte qui le reçoit.

Pourquoi l’exécution de code change le niveau de risque

Un assistant qui résume un document et un agent qui lance une commande ne présentent pas la même surface d’attaque. Dès qu’un modèle peut produire puis exécuter du Python, manipuler des fichiers, appeler un outil système ou installer une dépendance, il faut traiter le résultat comme du code non fiable. Une consigne malveillante cachée dans une page, une erreur de génération ou une dépendance compromise peut conduire l’agent à effectuer une action qui n’était pas prévue.

Le conteneur classique apporte un premier niveau d’organisation et d’isolation, mais partage généralement le noyau de l’hôte. Exposer le socket Docker à un processus dynamique est particulièrement dangereux, car cela revient souvent à lui donner un pouvoir très étendu sur la machine. Le projet présenté évite cette dépendance et ajoute une frontière entre la charge et le noyau hôte.

Ray transforme la sandbox en ressource distribuée

Ray est utilisé pour coordonner des calculs distribués : moteurs d’inférence, travailleurs de rollout, entraînement par renforcement et pipelines multimodaux. Plutôt que d’ajouter un système d’isolation totalement séparé, la nouvelle bibliothèque représente chaque sandbox sous la forme d’un acteur Ray. Le planificateur choisit le nœud, réserve le processeur et la mémoire, puis l’acteur gère le cycle de vie de l’environnement.

À partir de Ray 2.58, les auteurs de frameworks et les équipes de recherche peuvent utiliser les mêmes modèles de programmation que pour leurs autres charges. L’API annoncée permet notamment de créer un environnement depuis une image OCI, fixer des limites de CPU et de mémoire, définir un répertoire de travail, contrôler le réseau, exécuter des commandes, transférer des fichiers, lire l’état puis terminer ou supprimer la sandbox.

Ce choix est intéressant pour les charges agentiques : une sandbox devient une ressource que l’on peut placer, redémarrer, dimensionner et détruire comme les autres composants du cluster. Il devient également possible de construire des pools locaux afin d’éviter de recréer un environnement complet pour chaque opération courte.

Le rôle de gVisor dans cette isolation

gVisor est un noyau applicatif open source développé par Google. Il implémente en espace utilisateur une part importante de l’interface des appels système Linux. Les appels d’une application ne parviennent donc pas directement au noyau de l’hôte de la même manière que dans un conteneur ordinaire. Cette couche supplémentaire réduit l’exposition du système sous-jacent.

Le runtime reste compatible avec les images OCI courantes. Il n’impose pas d’ouvrir un démon Docker ni son socket à l’intérieur de l’environnement. Google met aussi en avant un démarrage inférieur à la seconde et une faible surcharge mémoire par sandbox, deux caractéristiques nécessaires lorsque les environnements doivent être créés à la demande et en grand nombre.

Il ne faut pas interpréter cette couche comme une garantie absolue. Une sandbox fait partie d’une stratégie de défense en profondeur : limitation réseau, permissions minimales, secrets éphémères, journalisation, quotas et destruction systématique de l’environnement restent nécessaires.

Des cas d’usage qui dépassent le simple interpréteur Python

Le besoin apparaît dans le post-entraînement, lorsque des modèles apprennent à résoudre des tâches au travers d’essais exécutés dans des environnements contrôlés. Il concerne aussi les assistants de développement, les outils d’analyse de données, les navigateurs automatisés et les agents capables d’interagir avec une ligne de commande.

Une entreprise peut également isoler des traitements fournis par des utilisateurs : conversion de fichiers, calculs personnalisés, validation d’un paquet ou exécution d’un test. La même architecture peut ainsi servir à protéger une plateforme SaaS qui accepte du contenu exécutable, indépendamment de l’utilisation d’un grand modèle.

Les contrôles à prévoir avant une mise en production

• Interdire par défaut les sorties réseau et ouvrir seulement les domaines indispensables à la tâche.
• Injecter des identifiants temporaires, limités à une ressource et à une durée courte.
• Limiter processeur, mémoire, stockage, durée d’exécution et nombre de processus.
• Monter les systèmes de fichiers en lecture seule chaque fois que possible.
• Conserver les traces de création, de commande, de transfert et de destruction sans enregistrer les secrets.
• Tester les scénarios d’évasion, de saturation, de téléchargement malveillant et d’exfiltration.

Ce que l’annonce ne résout pas à elle seule

L’isolation de l’exécution ne décide pas si une action est légitime. Elle ne remplace ni l’autorisation métier ni la confirmation humaine pour une opération sensible. Un agent correctement enfermé pourrait encore supprimer une donnée via une API si le jeton fourni lui en donne le droit. La sécurité doit donc suivre toute la chaîne : intention, politique, identité, outil, environnement d’exécution et audit.

La bibliothèque est présentée comme expérimentale. Google et Anyscale prévoient d’étendre ultérieurement le support à d’autres runtimes, notamment Agent Substrate ou Kata Containers. Les équipes intéressées doivent donc l’évaluer comme une brique en évolution, avec des tests de compatibilité et de charge propres à leur environnement.

Une architecture plus saine pour les agents opérants

Le progrès majeur tient moins à une nouvelle syntaxe qu’à la séparation explicite des responsabilités. Ray orchestre le travail distribué ; gVisor restreint l’environnement qui l’exécute ; Kubernetes et GKE fournissent les politiques, l’infrastructure et la supervision autour du cluster. Cette composition rend plus réaliste l’exécution de milliers de tâches courtes sans confondre rapidité de prototypage et accès illimité au système.

Pour un projet métier, la bonne question n’est donc pas « peut-on faire exécuter du code par l’IA ? », mais « quel code, dans quel environnement, avec quelle identité, quelles limites et quelle preuve de ce qui a été fait ? ». La sandbox apporte une partie essentielle de cette réponse.

Lire l’annonce technique Google Cloud et Anyscale ↗ · Voir l’approche architecture et sécurité de SDX →