Monty - un interpréteur Python léger pour exécuter en toute sécurité le code généré par l’IA

 (github.com/pydantic)
8 points par GN⁺ 2026-02-08 | 1 commentaires | Partager sur WhatsApp
  • Interpréteur Python léger basé sur Rust conçu pour exécuter en toute sécurité le code généré par l’IA, en éliminant la complexité et la latence des sandbox de conteneurs
  • Blocage complet de l’accès au système de fichiers, aux variables d’environnement et au réseau, avec possibilité d’appeler uniquement les fonctions externes explicitement autorisées par le développeur
  • Offre un temps de démarrage inférieur à 1 microseconde et des performances d’exécution proches de CPython, tout en étant callable depuis Rust, Python et JavaScript
  • L’état d’exécution peut être sauvegardé et restauré sous forme de snapshot au niveau de l’octet, ce qui permet l’interruption et la reprise entre processus
  • Doit faire fonctionner la fonctionnalité Code Mode de Pydantic AI, et sera utilisé comme composant clé pour exécuter en toute sécurité le code Python écrit par un LLM

Présentation de Monty

  • Monty est un interpréteur Python expérimental écrit en Rust, conçu pour exécuter en toute sécurité le code généré par l’IA
    • Il évite le coût, la latence et la complexité des sandbox basées sur des conteneurs, et permet d’exécuter directement le code Python écrit par un LLM
    • Son temps de démarrage se mesure en quelques microsecondes, bien plus rapide que les centaines de millisecondes généralement observées avec les conteneurs
  • Fonctionnalités disponibles
    • Prise en charge de certaines syntaxes de Python, avec vérification statique des types basée sur les annotations de type
    • Aucun accès à l’hôte, et les appels à des fonctions externes sont limités à celles explicitement autorisées par le développeur
    • Appelable depuis Rust, Python et JavaScript, avec suivi et limitation de l’utilisation des ressources intégrés
    • Prise en charge de la capture de stdout/stderr, de l’exécution de code asynchrone et de la sauvegarde/restauration par snapshot
  • Limites
    • La bibliothèque standard se limite à sys, typing, asyncio, dataclasses (prévu) et json (prévu)
    • Les définitions de classes et l’instruction match ne sont pas encore prises en charge
    • Les bibliothèques tierces ne sont pas prises en charge
  • L’objectif de conception est unique : exécuter en toute sécurité le code écrit par des agents

Intégration à Pydantic AI

  • Monty alimente le Code Mode de Pydantic AI
    • Le LLM écrit du code Python au lieu d’effectuer des appels d’outils, et Monty l’exécute en toute sécurité
    • Dans l’exemple, des outils sous forme de fonctions comme get_weather et get_population sont définis, puis le LLM écrit le code qui les appelle

Comparaison avec les technologies alternatives

  • Monty a une complétude du langage limitée, mais se distingue par sa sécurité, sa vitesse et sa simplicité
    • Latence de démarrage de 0,06 ms, gratuit, installation simple, prise en charge des snapshots
  • Résumé de la comparaison avec d’autres technologies :
    • Docker : environnement CPython complet, sécurité correcte mais latence de démarrage de 195 ms
    • Pyodide : basé sur WASM, sécurité faible et latence de démarrage de 2800 ms
    • starlark-rust : langage très limité, rapide mais différent de Python
    • services de sandboxing : sécurité forte mais coût, latence et complexité de configuration élevés
    • YOLO Python(exec/subprocess) : rapide mais sans aucune sécurité
  • Grâce au contrôle d’accès aux fichiers, à la limitation des ressources et aux fonctions d’interruption/reprise basées sur les snapshots, Monty fournit un environnement Python sécurisé pour l’exécution de code IA

À lire aussi

1 commentaires

 
GN⁺ 2026-02-08
Commentaires sur Hacker News

  • J’ai essayé d’exécuter une version compilée en WebAssembly. J’ai aussi créé un playground web pour la tester directement
    Il n’y a pas encore de prise en charge des classes, mais quand le LLM essaie d’utiliser des classes, il voit l’erreur et réécrit lui-même le code sans classes
    Un billet qui récapitule le processus de build est disponible ici

    • C’est vrai, mais si ce genre de petites frictions à bas niveau d’abstraction s’accumule, les performances au niveau supérieur en souffrent. Le LLM finit par dépenser ses ressources à contourner les limites de l’interpréteur Python au lieu de résoudre le vrai problème
    • Beau projet, mais j’ai du mal à voir des cas d’usage concrets. Est-ce pour un mode code où les appels MCP seraient remplacés par des fonctions Monty, ou pour le pré/post-traitement des requêtes, ou encore pour implémenter CaMeL ?
      La force d’un agent terminal, c’est l’accès au réseau et au système de fichiers, donc dans ce cas un conteneur sandboxé semble être l’extension naturelle
    • Franchement, je ne vois pas pourquoi c’est nécessaire. Mes modèles écrivent déjà très bien du code dans plusieurs langages, alors pourquoi se limiter à du Python restreint ?
      J’utilise TypeScript, C# et Python sans problème
    • Dire qu’il “réécrit en code sans classes” signifie au fond que ce n’est possible que si les données d’entraînement contiennent suffisamment d’exemples de ce genre. Heureusement, il y a beaucoup de code Stack Overflow, donc ça peut peut-être passer

  • Ça me rappelle l’époque où j’utilisais Mercurial avant de passer à Git. À l’époque, Git était à la mode et tout le monde semblait l’utiliser, mais je trouvais l’UX de Mercurial bien meilleure
    Aujourd’hui, tout le monde écrit des exec d’agent en Python, mais j’ai le sentiment que TypeScript/JS est plus adapté. C’est rapide, sûr, et le typage augmente la densité d’information. Mais cette fois encore, j’ai l’impression que c’est moi qui vais perdre

    • Il y a trois raisons pour lesquelles je pense que Python est meilleur que JS
      1. une bibliothèque standard très riche (CSV, sqlite3, json, etc.)
      2. le code écrit par le LLM fonctionne le plus souvent immédiatement. En JS, il y a trop d’éléments instables : séparation Node/Deno, confusion autour de la syntaxe des imports, top-level await, etc.
      3. l’écosystème de traitement de données est bien plus solide (csv/pandas, etc.)
    • J’utilise Python et JS depuis plus de dix ans, et à chaque fois j’ai souffert des gestions d’exceptions bizarres ou des problèmes de vérification null/undefined. Donc je choisirais Python tous les jours
    • Historiquement, Python est fort grâce à l’écosystème scientifique et IA. C’est dû à des bibliothèques comme numpy, scipy et PyTorch
      Personnellement, je préfère le système de types statiques de TypeScript, mais en matière de performance ou de sécurité, les deux langages se valent à peu près
    • Si un agent peut exécuter du code, il peut traiter directement les données, ce qui réduit le contexte nécessaire.
      Python a un excellent écosystème pour ce genre de traitement, et des outils comme Pyodide ou ty peuvent aussi atténuer les problèmes de sécurité
    • Grâce à l’IA, CPython subit enfin une pression pour intégrer un JIT natif. Côté GPU aussi, il existe beaucoup de JIT basés sur des DSL Python, donc en pratique l’écart de performance n’est pas si grand.
      Désormais, NVIDIA prend officiellement en charge l’écriture de kernels en Python

  • Ce projet propose une approche intéressante du problème du sandboxing. J’avais déjà fait une expérimentation avec jsrun, où V8 était embarqué dans Python pour exécuter du JS de façon sûre
    Monty semble viser un objectif similaire. Commencer avec un interpréteur minimal est bien adapté aux workloads IA, mais gérer la longue traîne de la syntaxe Python n’est pas simple
    Le point d’équilibre est crucial : réduire la surface pour garantir sécurité et prévisibilité, tout en offrant assez de fonctionnalités pour exécuter le code complexe généré par les LLM

    • L’objectif est de simplifier le mode code ou les appels de fonctions externes. À court terme, prendre en charge class, dataclass, datetime et json devrait déjà suffire
    • Mais dans des environnements sensibles sur le plan de la sécurité, je pense qu’une isolation basée sur VM reste indispensable au final. Une approche comme Monty a beaucoup de contraintes pratiques (avis d’un employé d’E2B)

  • Rien à voir, mais ça m’a rappelé le livre Monty Roberts, The Man Who Listens to Horses.
    C’est à propos de l’apprentissage du langage des animaux ; voici un lien vers le livre et une vidéo

  • La description “exécuter en toute sécurité et à très haute vitesse du code Python écrit par un LLM” m’a intrigué.
    Cela dit, même un runtime Rust comme uv prend au minimum environ 10 ms, donc des temps à l’échelle de la microseconde paraissent difficiles
    Cela reste une bonne idée, ce mini-interpréteur sans bibliothèque standard. C’est nouveau du point de vue du sandboxing pour l’IA, et je ne m’attendais pas à voir ça venir de Pydantic

    • Pydantic et FastAPI sont aujourd’hui l’équipe Python la plus intéressante. Ils sortent sans arrêt de nouveaux projets
    • Pour info, uv est un runtime écrit en Rust

  • Je pense qu’au lieu de recycler des langages existants, il vaudrait mieux créer un langage strict dédié à l’IA
    L’IA comprend bien les spécifications, donc elle n’a pas besoin d’une syntaxe souple pensée pour les humains.
    Au contraire, un langage qui impose une structure précise et un format cohérent serait plus adapté.
    J’expérimente moi-même ce type de langage, et je pense qu’on peut exiger plus de discipline d’une IA que d’un humain pour la génération de code

    • Mais le problème, c’est l’apprentissage. Pour qu’un modèle apprenne un nouveau langage, il faut une quantité énorme de données.
      Il est bien plus réaliste de restreindre un modèle qui connaît déjà bien Python avec des consignes du type “n’utilise que cette fonction”

  • Le point de jstanley sur les petites frictions (papercuts) est juste, mais à l’inverse, quand on exécute à grande échelle du code généré par l’IA, le risque de sécurité est plus important
    Donner à un CPython complet l’accès aux fichiers, au réseau ou aux subprocess est dangereux
    En revanche, la limitation sur les classes est étrange. Ça n’a rien à voir avec la sécurité, ça rend simplement le code plus sale.
    C’est sans doute une approche du type “on commence avec le minimum, puis on étend progressivement”

    • Oui, la limitation sur les classes n’a pas un but de sécurité, c’est juste que ce n’est pas encore implémenté

  • Plutôt que d’essayer d’imiter toutes les fonctionnalités de CPython, l’idée de construire l’interpréteur minimal nécessaire au code d’IA est intéressante
    Un runtime complet a une surface d’attaque bien trop large, alors qu’un sous-ensemble limité est plus sûr
    La stratégie consistant à laisser le LLM s’adapter lui-même à la syntaxe restreinte via les retours d’erreur semble aussi réaliste.
    Dans la plupart des scénarios d’usage d’outils, on n’a pas besoin de métaclasses ni d’imports dynamiques

  • Question simple : pourquoi ne pas utiliser seccomp pour restreindre les appels système ?
    Si l’on veut bloquer l’accès aux fichiers, il suffirait de bloquer les syscalls correspondants ; je me demande donc pourquoi un interpréteur séparé est nécessaire

    • Des projets comme bvisor vont dans cette direction
    • C’est une approche valable, mais si le runtime de base est trop puissant, il existe beaucoup de possibilités de contournement.
      En partant dès le départ d’un runtime extrêmement simple, la surface d’attaque est réduite et c’est bien plus sûr

  • Le projet en lui-même est raisonnable, mais l’expression “outil ultra-rapide pour l’IA” me fait sourire
    La vitesse de réflexion de l’IA est tellement lente que, même si l’exécution du code est très rapide, la différence perçue sur la vitesse globale reste faible
    Ça donne l’impression de faire des livraisons avec un collègue qui travaille à côté à la vitesse d’un glacier