Les modèles d’IA ont besoin d’une machine virtuelle

 (blog.sigplan.org)
3 points par GN⁺ 2025-09-01 | 1 commentaires | Partager sur WhatsApp
  • Les logiciels d’IA ont besoin de caractéristiques de type système d’exploitation qui vont au-delà du simple appel de modèle, en fournissant sécurité, isolation, scalabilité et portabilité ; d’où la proposition du concept de machine virtuelle dédiée aux modèles d’IA (MVM)
  • De la même manière que la Java Virtual Machine (JVM) a rendu possible la sûreté mémoire et le principe « écrire une fois, exécuter partout », une VM pour l’IA garantit aussi l’interchangeabilité et l’interopérabilité en séparant le modèle de la logique d’intégration
  • La VM définit un jeu d’instructions standard pour les appels de modèle, les appels d’outils, l’enregistrement des résultats, les entrées utilisateur et les branchements conditionnels, afin de contraindre et de tracer en toute sécurité le comportement du modèle
  • Les travaux existants, comme les appels d’outils structurés d’OpenAI, le MCP d’Anthropic, FIDES/AC4A de Microsoft et des runtimes open source, montrent déjà une orientation vers la standardisation
  • Une VM d’IA bien définie peut permettre un renforcement de la sécurité et de la confidentialité, le monitoring des performances, la vérification des sorties et la création d’un écosystème cross-platform, et s’imposer comme une infrastructure clé pour rendre les systèmes d’IA plus fiables et plus sûrs

Introduction

  • Les modèles d’IA sont utilisés dans les logiciels pour divers usages, notamment comme copilotes applicatifs, pour l’intégration dans les IDE et pour l’usage d’outils via le protocole MCP
    • Cette évolution accroît la nécessité de garantir la confidentialité, la sécurité et un fonctionnement correct
  • La sécurité et la confidentialité doivent être assurées dès la phase de conception du système ; les ajouter après coup ne suffit pas
  • En s’inspirant de la Java Virtual Machine (JVM), l’article propose l’importance d’une machine virtuelle standardisée pour les modèles d’IA
    • La JVM fournit un environnement d’exécution fiable grâce à la sûreté mémoire, au contrôle d’accès et à la vérification du bytecode
    • Cela a rendu possible le principe « écrire une fois, exécuter partout »

Rôle de la machine virtuelle pour modèles d’IA (MVM)

  • La MVM agit comme un logiciel intermédiaire entre le modèle d’IA et l’environnement externe
    • Exemple : lorsqu’un utilisateur saisit le prompt « réserver un vol », la MVM le transmet au modèle, y compris avec ajout de contexte
    • Si le modèle répond « utiliser l’outil de réservation », la MVM vérifie la liste des outils autorisés avant de décider d’effectuer ou non l’appel
    • Cela garantit que le modèle n’effectue pas d’appels non autorisés
  • Tous les systèmes d’IA commerciaux ont besoin d’un logiciel de contrôle similaire
  • La MVM définit un jeu d’instructions, par exemple :
    • authentification, chargement, initialisation et déchargement du modèle
    • appel du modèle avec contexte
    • parsing de la sortie du modèle
    • authentification, chargement et appel des outils, parsing des résultats et stockage en mémoire
    • demande d’entrée utilisateur, ajout à la mémoire d’historique, structures de contrôle comme les conditions, etc.

Travaux existants et nécessité

  • Protocole d’appel d’outils structurés d’OpenAI : intégration claire des outils via une API d’appel de fonctions basée sur JSON et les spécifications OpenAPI
  • MCP d’Anthropic (2024) : protocole ouvert reliant les assistants IA à des données externes
    • Il est comparé à un « port USB-C pour les applications d’IA » et fournit une interface universelle
    • Il bénéficie d’une adoption rapide, y compris dans de grandes entreprises
  • Orchestrateurs de sécurité – FIDES & AC4A (2025) :
    • FIDES (Microsoft Research) : applique des politiques de flux d’information, suit les labels de confidentialité des données et ajoute une action d’« inspection »
    • AC4A : gère outils et données dans une hiérarchie de style OS et impose un mode de fonctionnement selon le principe du moindre privilège
    • Ces projets montrent que la MVM pourrait intégrer nativement la sécurité et le contrôle d’accès
  • Runtimes d’agents open source : langchain, Semantic Kernel, llguidance fournissent des services d’exécution qui facilitent le développement d’applications d’IA robustes
  • Les spécifications d’une MVM exigent que les données d’entraînement du modèle reflètent les spécifications d’interface, ce qui implique une coévolution entre le modèle et la MVM

Avantages de la MVM

  • Séparation des responsabilités : la logique du modèle et la logique d’intégration sont dissociées, ce qui transforme le modèle en composant remplaçable
    • L’interopérabilité est préservée lors du remplacement par un nouveau modèle ou d’un changement de plateforme
  • Sécurité et gouvernance intégrées : la MVM garantit la sûreté via la vérification des autorisations, les journaux d’audit et des garde-fous
    • Comme AC4A, la MVM peut jouer un rôle de gatekeeper pour freiner les comportements inattendus
  • Suivi transparent des performances : les diagnostics à l’exécution fournissent des informations sur les performances du modèle, la consommation de ressources et le niveau d’accès aux données
    • Des benchmarks permettent de comparer précision, utilité et réactivité
  • Vérification des sorties du modèle : des techniques comme les preuves à divulgation nulle de connaissance permettent de vérifier l’intégrité des sorties, renforçant la confiance et la responsabilité

Conclusion

  • Une machine virtuelle pour modèles d’IA est nécessaire pour réduire la complexité des systèmes d’IA et accroître l’interopérabilité
  • Elle renforce la sécurité, la confidentialité, la portabilité et la fiabilité, tout en accélérant le développement et en améliorant la scalabilité de l’écosystème
  • En s’appuyant sur les recherches des entreprises technologiques, des startups et du monde académique, une spécification de MVM peut fournir un standard permettant aux modèles d’IA d’interagir de manière sûre et fluide
  • L’objectif est de construire, avec la communauté, un consensus sur la nécessité d’une spécification MVM et sur les éléments qu’elle doit inclure

À lire aussi

1 commentaires

 
GN⁺ 2025-09-01
Commentaires sur Hacker News

  • J’ai l’impression que cet article manque de détails concrets, au point qu’on ne sache pas exactement ce qu’il propose. Une VM (Virtual Machine), quoi qu’il en soit, est liée à des choses comme un jeu d’instructions, le flot de contrôle, les registres, etc., alors que cet article se concentre uniquement sur l’authorization. Au final, on dirait qu’il parle de « quelque chose de similaire à un sandbox, une jail ou un container qui permet au modèle d’interagir avec le monde extérieur »

    • Je me demande s’il est vraiment question d’un moteur d’exécution de VM, ou d’un Docker pour les LLM. Dans l’ensemble, ça ressemble à une idée surtout bien emballée. Si la conception du système de packaging est médiocre, ça peut tourner à la catastrophe. Il suffit de voir les nombreuses expériences de packaging en Python pour s’en rendre compte

    • En voyant le mot VM, j’ai immédiatement pensé à quelque chose d’assez proche d’un sandbox. Comme l’article parle aussi d’« isolation », je ne l’ai pas trouvé ambigu ni insuffisamment informatif. En revanche, l’argument de l’auteur est trop évident et la solution incomplète. Même si on met ça dans un sandbox au niveau OS ou matériel, ça devient problématique si l’agent trouve par exemple un AWS CLI avec une configuration IAM incorrecte. Les frontières à distance sont elles aussi complexes. Je n’y ai trouvé aucun insight nouveau. À mon avis, le problème n’est pas le choix du terme

    • Si on suit la définition donnée dans l’article, on peut considérer que les agents IA actuels s’exécutent déjà dans des VM. Par exemple, dans un hôte MCP, on peut demander l’accord de l’utilisateur avant l’exécution, ou définir des règles qui approuvent automatiquement certaines commandes, comme avec Claude code

  • À mon avis, la vraie question n’est pas quels outils donner à un LLM, mais quelles actions l’autoriser à effectuer. Par exemple, dans un scénario de réservation de vol, on veut que le LLM compare les prix sur différents sites et aille jusqu’au paiement. Mais on ne veut pas qu’il choisisse stupidement un billet 3 dollars moins cher qui dure 37 heures. Pour la consultation des avantages sociaux, il ne devrait pouvoir voir que les siens, pas ceux de ses collègues. Avec un même outil, l’étendue des autorisations diffère. Un responsable RH peut évidemment consulter les informations des employés qu’il gère, mais cela introduit alors d’autres enjeux comme les journaux d’audit. Autrement dit, l’intention est encore plus importante que l’action. Il serait souhaitable de placer le LLM dans le même périmètre d’autorisations que l’utilisateur, comme son mandataire

    • Au fond, ce qui est décrit ici, c’est un capability security model. Il faut transmettre explicitement au logiciel agent les capabilities auxquelles il a accès, et il faut l’empêcher physiquement d’agir en dehors de cette liste. Mais dans la pratique, aucun OS grand public ne met vraiment en œuvre ce modèle. Il y a eu beaucoup de recherches (EXEMPLES D’OS : EROS, Fuchsia, Sandstorm) et de tentatives, mais elles n’ont pas vraiment percé sur le marché. Du coup, l’approche la plus proche en pratique consiste à utiliser une VM avec uniquement les outils nécessaires à l’intérieur. Ce n’est pas parfait, notamment parce que les outils eux-mêmes sont trop génériques par rapport à de véritables capabilities. Les logiciels conçus selon le principe du moindre privilège échouent souvent sur le marché

    • Ce qui importe, ce n’est pas seulement quelles actions un outil peut exécuter, mais la combinaison entre les données auxquelles il a accès et les actions qu’il permet. Comme il est impossible de prédire parfaitement le comportement d’un LLM, il ne faut pas lui faire confiance. Par exemple, on peut autoriser un LLM à accéder uniquement à des sites de réservation de vols, mais sans lui transmettre des SSN, des informations de compte bancaire, etc. C’est un problème de provenance des données et d’autorisations. Plus une tâche manipule des données sensibles, plus elle doit être contrainte ; inversement, si elle est moins sensible, on peut lui permettre davantage d’actions. Les données devraient porter des informations d’autorisation, et un médiateur devrait limiter quelles données et quelles actions une nouvelle tâche lancée peut posséder. Exemple : si une tâche de planification de voyage lance en sous-tâche une recherche de vol, le médiateur ne devrait transmettre à cette sous-tâche que des données non sensibles comme une partie de l’itinéraire, tout en bloquant l’accès aux données sensibles

    • On peut voir l’agent LLM comme un autre utilisateur identique à l’utilisateur humain, mais avec des droits différents selon le contexte. Par exemple, il peut avoir des droits de lecture/écriture sur un dossier de code source, et seulement un droit de lecture sur un autre. Les autorisations de l’agent LLM diffèrent selon le projet, et constituent une intersection ou un sous-ensemble des autorisations de l’utilisateur. En gros, il existe trois types d’autorisations : Allow, Deny et Ask (demande d’autorisation), et si nécessaire on demande à l’utilisateur s’il autorise l’action. Le problème, c’est que les autorisations existantes au niveau de l’OS, des applications et des données ne sont pas assez granulaires. Même git devrait être conçu pour n’autoriser que certaines commandes, au lieu d’un accès global. Aujourd’hui, les applications imitent chacune cela dans leur espace utilisateur, de manière maladroite. Le workflow ressemble à sudo. Si je lance une application en tant que mon utilisateur LLM Agent, les permissions sont accordées ou restreintes selon ce contexte. Il ne peut agir dans les limites que j’ai autorisées que lorsque je le demande. Mais aujourd’hui, chaque application agentique doit implémenter ce processus elle-même ; il faudrait donc en faire un service d’OS structuré. À défaut, on peut contourner le problème en créant et supprimant des comptes utilisateur temporaires selon le contexte de l’agent, qui ne communiquent que via IPC ou le réseau

    • Je doute qu’un tel modèle fonctionne vraiment. Même si un LLM peut accomplir certaines choses, les sites web peuvent le détecter, ajuster leurs prix ou casser les arbres de décision. Dans ce cas, il vaudrait bien mieux que tous les sites proposent directement une API pour LLM, ou du moins du « rss + json ». Comme les BBS ou les systèmes de menus SMS, si on fournit simplement des données et des choix, c’est aussi optimal pour un LLM. Même chose pour la publicité. Il n’y a aucune raison de montrer des pubs à un LLM ; au contraire, des pubs conçues pour tromper le LLM seraient encore plus efficaces. Par exemple, lors d’une recherche de vol, une pub pourrait séduire le LLM et lui faire croire que son produit est le meilleur. Comme l’IA reste encore simple, l’arrivée de pubs dédiées aux IA serait presque amusante à voir

    • S’il est possible de définir et de faire appliquer ce qu’est une « bonne réponse », alors on n’a peut-être même pas besoin du LLM lui-même. Dans le cas d’un responsable RH, on peut lui demander directement son intention, mais avec un LLM c’est difficile puisqu’il n’a pas d’intention

  • J’avais vu auparavant un post HN disant que John Carmack n’avait fait que gaspiller du temps et de l’argent chez Meta en développant XROS. L’article d’aujourd’hui semble au contraire défendre fortement la nécessité d’un « nouvel OS ». Une VM n’est pas un OS complet, mais la différence est qu’elle peut rester légère tout en réutilisant des OS et des bases de code existants

    • Ces deux textes parlent de choses totalement différentes. En fait, je n’ai même pas l’impression que celui-ci défende fortement le besoin d’une VM ou d’un nouvel OS. Au final, tout tourne autour du contrôle d’accès

    • Dans le XR, le cœur du sujet était la performance et la developer experience, alors que du côté des LLM, la question centrale est précisément de savoir comment sandboxer et simplifier l’accès aux outils et aux données. Il reste beaucoup à faire pour éviter qu’un LLM dégrade son environnement d’exécution ou corrompe des données, et l’existence d’un standard réduirait le coût de réapprentissage tout en facilitant l’utilisation des modèles des autres. Pour le XR, si ce n’est qu’un SDK, on peut s’en sortir par l’entraînement ; mais pour l’IA, les coûts de R&D et de compute sont bien plus élevés

    • WebAssembly fournit déjà un sandbox par défaut, donc on a fait la moitié du chemin. Ce qu’il reste, c’est une interface claire pour transférer données et autorisations entre instances, ainsi qu’un moyen pour qu’elles se créent mutuellement

    • Je ne pense pas que cet article justifie l’écriture d’un nouvel OS. Construire un environnement d’exécution pour l’IA et concevoir from scratch un OS optimisé pour l’IA, ce sont deux sujets complètement distincts

  • Après avoir lu attentivement l’article et ses liens de référence, j’ai eu l’impression qu’il pointait un problème plus fondamental qu’une simple « VM pour l’IA ». Une VM seule ne suffit pas à assurer la sécurité d’un workflow LLM. Le workflow de plus haut niveau doit avoir accès à des tâches et des données sensibles comme le réseau, les PII ou les credentials, et les LLM sont vulnérables au prompt injection et aux problèmes de cohérence. Mettre simplement un LLM dans une VM ne résout pas cela. Il faut une « gestion des flux d’information » qui partitionne, unité de travail par unité de travail, le workflow, les données et les calculs, afin que seuls les sous-tâches minimaux puissent accéder à des informations limitées. Seul le sous-ensemble chargé des tâches sensibles doit être spécifiquement de confiance et vérifié. Les « Secure Orchestrators » mentionnés dans l’article, ainsi que le papier FIDES, sont le vrai cœur du sujet. Au final, le terme « VM » désigne ici l’exécution d’une tâche dans un conteneur ne disposant que de permissions et de données restreintes. L’orchestrateur doit créer ce conteneur, lui attribuer les bonnes autorisations, et apposer aussi des labels de sensibilité (taint-tracking) sur les données produites. Globalement, je pense qu’il est plus juste de mettre en avant des notions comme « partitioning » ou « isolation », ainsi que les enjeux liés aux données, plutôt que de parler de « VM for AI »

    • Cela ressemble à Microsoft Wassette

    • L’objectif devrait être de faire disparaître la notion même de workflow. Dans une combinaison LLM+VM, le simple fait de fournir des outils au LLM constitue déjà un workflow. Cette approche fonctionne déjà souvent bien, mais elle atteint ses limites dès qu’il faut gérer des exceptions non définies à l’avance ou des tâches nécessitant de nouveaux outils. En plus, une approche fondée sur le workflow a toujours du mal à dépasser les limites d’un enchaînement linéaire (ou d’un DAG, même avec des boucles). L’étape suivante consiste à ne plus fournir d’outils du tout, et à laisser le LLM créer lui-même à la volée l’outil dont il a besoin. Certains problèmes nécessitent une approche de type brute-force

  • En lisant l’article, j’ai fini par avoir l’impression que beaucoup de textes récents semblent écrits par une IA. Du point de vue de l’hébergement, le simple fait de faire tourner de manière fiable un agent IA dans n’importe quel environnement est déjà un énorme défi. Comme développeur, j’utilise un devcontainer Docker rootless sous WSL ; certains malwares pourraient peut-être le percer, mais je trouve cette approche plus sûre qu’une approche VM. En plus, elle apporte la reproductibilité, l’isolation de l’environnement, etc., et si l’IA casse mon environnement, il suffit de recréer le conteneur, ce qui est beaucoup moins pénible

  • Si on regarde les méthodes de déploiement de modèles les plus avancées commercialement, on constate que presque toutes les caractéristiques mentionnées ici, comme l’isolation, sont déjà implémentées. Ce n’est pas au niveau de l’OS lui-même, mais fonctionnellement c’est similaire. Pourtant, même cela ne suffit pas. Pour qu’un agent fasse réellement son travail, il doit avoir accès à des ressources importantes, et lui accorder exactement le bon niveau d’accès est bien plus difficile que d’isoler le LLM lui-même. Le bon modèle pour la sécurité des LLM, c’est « untrusted userspace ». Il n’est pas nécessaire de redessiner tout l’OS

    • Je pense que la notion d’« untrusted userspace » est juste. Ce genre de mécanismes peut peut-être aider un peu côté sécurité, mais je ne suis pas d’accord avec l’exagération des auteurs lorsqu’ils parlent de « garanties ». Ils ont comparé l’accès aux outils aux permissions de fichiers, mais en pratique le bilan de l’OS sur les permissions de fichiers n’est pas particulièrement bon. Si on vérifie si un outil de réservation est autorisé, au final cet outil est quand même un navigateur web. Or un navigateur est à la fois un outil générique et une cible potentielle pour des attaques de type jailbreak. Le point important, c’est qu’il faut de nouvelles mesures de sécurité pour empêcher un modèle d’IA de se comporter de manière malveillante même sous ces contraintes de machine virtuelle. En fin de compte, la morale simple est qu’il faudra nécessairement résoudre le problème de l’alignement

  • Je suis d’accord avec l’idée qu’il faut traiter l’isolation des LLM avec autant de rigueur qu’au niveau de la conception d’une VM. C’est exactement pour la même raison que les OS traditionnels appliquent strictement ce type de séparation. J’ai d’ailleurs résumé récemment quelques idées dans ce blog. J’ai abordé le sujet en comparant le fonctionnement des LLM à celui des processus et tâches des OS traditionnels, et les principales abstractions ne sont pas difficiles à implémenter — on peut unifier les interfaces chat/tool de 8 backends LLM pour gérer centralement l’approbation des outils. Je n’ai pas encore implémenté le capabilities model, mais d’après mon expérience passée sur des OS (VSTa), c’est une approche naturelle. Un LLM devrait pouvoir déléguer à un autre LLM un sous-ensemble des autorisations qu’il détient, et j’ai déjà construit un outil de délégation pour cela

  • Je pense que créer une nouvelle machine abstraite comme une VM ne fait qu’ajouter de la complexité. On peut déjà couvrir l’essentiel avec les comptes, les permissions de lecture/écriture/exécution sur les fichiers, et les accès temporaires ou distants via des access tokens. À mon avis, tous les capability models peuvent être implémentés avec ces concepts. Je préfère simplifier les outils existants. Tout le monde expérimente de nouvelles choses en espérant une transformation radicale du logiciel, mais je pense qu’il faudrait plutôt profiter de cette période pour réduire la complexité inutile et revenir à plus de simplicité. Par exemple, transformer simplement un serveur MCP en outil CLI pour Claude prend 10 minutes. Et c’est déjà largement utilisable

    • Le modèle de sécurité des OS de bureau modernes est ridiculement insuffisant à notre époque. Donner tous les pouvoirs à une application sans pratiquement aucun avertissement ni confirmation à l’utilisateur relève de la folie. Si un utilisateur veut vraiment un environnement sans aucune contrainte, il devrait pouvoir en avoir le choix, mais le défaut devrait être le moindre privilège. Il faudrait accorder à chaque programme uniquement des permissions spécifiques à son domaine. Par exemple, un outil de visualisation de l’usage disque peut avoir besoin d’un accès complet au système de fichiers, mais certainement pas d’un accès au réseau local ou à Internet

    • Le plus grand atout d’une VM, c’est de limiter l’étendue des dégâts. Un bon agent peut exploiter des zero day présents dans le système pour le compromettre facilement. Même avec de simples permissions utilisateur, le danger est déjà réel, et limiter les connaissances de l’agent par un pare-feu est extrêmement difficile, d’autant plus qu’il existe quantité de contournements sur Internet. Ces systèmes vont devenir très compétents pour compromettre des machines, donc il faut des mécanismes de sécurité extrêmement solides

    • Dans un environnement LLM, la notion de lecture ponctuelle (« temporary read ») n’existe pas vraiment. Une fois qu’une donnée entre dans le contexte, il faut partir du principe qu’elle peut fuiter vers tout ce à quoi l’agent est connecté jusqu’à ce qu’il meure et que le contexte soit supprimé. C’est vrai avec ou sans VM, et une VM à elle seule ne constitue donc pas une solution de sécurité

    • Je suis d’accord dans l’ensemble. Beaucoup de risques de sécurité existent avec ou sans VM. La defense in depth va devenir encore plus importante, mais aujourd’hui il y a déjà bien trop de moyens faciles pour un attaquant d’utiliser un agent IA contre l’utilisateur

    • À partir du moment où l’on autorise simplement un outil d’édition de fichiers, on perd en réalité presque toute la sécurité

  • Je pense que Fuchsia pourrait être un OS réaliste pour contrôler le comportement des modèles d’IA. C’est un object capability OS, donc chaque composant (processus) ne peut accéder qu’aux capabilities qui lui ont été explicitement accordées

    • J’aime la conception de Fuchsia et j’y adhère, mais je ne pense pas qu’elle se concrétisera réellement. Plutôt que de créer un nouvel OS, je pense qu’on ira plus probablement vers un modèle à la Fuchsia fondé sur des composants WASM/WASI, hébergeable partout, du cloud au mobile

  • Quand ChatGPT exécute du code (par exemple pour traiter un CSV), il semble le faire dans une VM avec accès uniquement à certains outils et bibliothèques, avec un disque sandboxé et sans accès à Internet. En pratique, on se dirige donc déjà vers quelque chose de très proche de cette architecture

    • Devin et OpenHands font quelque chose de similaire. Dans un projet pilote IA que j’ai mené il y a quelques mois, le fait de « faire tourner l’agent dans une VM (par défaut) » était un élément clé

    • C’est une pile Kubernetes basée sur AKS (Azure Kubernetes), avec gVisor et Jupyter par-dessus

    • Pas nécessairement. Par exemple, si l’on suppose qu’on fait tourner deux IA (comme ChatGPT) sur une même machine, il n’existe absolument aucun standard ni aucune interopérabilité pour leur collaboration ou leur fonctionnement mutuel.