Monty - un intérprete ligero de Python para ejecutar de forma segura código generado por IA

 (github.com/pydantic)
8 puntos por GN⁺ 2026-02-08 | 1 comentarios | Compartir por WhatsApp
  • Intérprete ligero de Python basado en Rust diseñado para ejecutar de forma segura código generado por IA, eliminando la complejidad y la latencia de los sandboxes con contenedores
  • Bloquea por completo el acceso al sistema de archivos, variables de entorno y red, y solo permite llamar funciones externas que el desarrollador haya autorizado
  • Ofrece un tiempo de arranque inferior a 1 microsegundo y un rendimiento de ejecución similar a CPython, además de poder invocarse desde Rust, Python y JavaScript
  • El estado de ejecución puede guardarse y restaurarse como snapshot a nivel de bytes, lo que permite pausar y reanudar entre procesos
  • Está previsto que impulse la función Code Mode de Pydantic AI, y se usará como componente clave para ejecutar de forma segura código Python escrito por LLMs

Resumen de Monty

  • Monty es un intérprete experimental de Python escrito en Rust, creado para ejecutar de forma segura código generado por IA
    • Evita el costo, la latencia y la complejidad de los sandboxes basados en contenedores, y permite ejecutar directamente código Python escrito por LLMs
    • Su tiempo de arranque está en el orden de unos pocos microsegundos, mucho más rápido que los cientos de milisegundos típicos de un contenedor
  • Funciones disponibles
    • Soporta la ejecución de parte de la sintaxis de Python, incluida la verificación estática de tipos basada en type hints
    • Bloqueo total del acceso al host; las llamadas a funciones externas solo son posibles para aquellas que el desarrollador haya permitido explícitamente
    • Puede invocarse desde Rust, Python y JavaScript, e incluye funciones integradas para rastrear y limitar el uso de recursos
    • Soporta recolección de stdout/stderr, ejecución de código asíncrono y guardado y restauración de snapshots
  • Limitaciones
    • La biblioteca estándar disponible se limita a sys, typing, asyncio, dataclasses(próximamente), json(próximamente)
    • Las definiciones de clases y la sentencia match aún no son compatibles
    • Las bibliotecas de terceros no están contempladas
  • El objetivo de diseño es uno solo: ejecutar de forma segura código escrito por agentes

Integración con Pydantic AI

  • Monty impulsa Code Mode de Pydantic AI
    • En lugar de llamadas a herramientas, el LLM escribe código Python, y Monty lo ejecuta de forma segura
    • En el ejemplo, se definen herramientas funcionales como get_weather y get_population, y el LLM escribe código que las llama

Comparación con tecnologías alternativas

  • Monty tiene una completitud de lenguaje limitada, pero destaca en seguridad, velocidad y simplicidad
    • Latencia de arranque de 0.06 ms, gratis, instalación sencilla y soporte de snapshots
  • Resumen comparativo con otras tecnologías:
    • Docker: entorno CPython completo, buena seguridad pero latencia de arranque de 195 ms
    • Pyodide: basado en WASM, seguridad débil y latencia de arranque de 2800 ms
    • starlark-rust: lenguaje muy limitado, rápido pero distinto de Python
    • servicios de sandboxing: seguridad sólida pero con costo, latencia y configuración compleja
    • YOLO Python(exec/subprocess): rápido pero sin ninguna seguridad
  • Monty proporciona un entorno seguro de Python para ejecutar código de IA mediante funciones de control de acceso a archivos, límites de recursos y pausa/reanudación basada en snapshots

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-02-08
Comentarios en Hacker News

  • Probé ejecutar una versión compilada con WebAssembly. Hice un playground web donde se puede probar directamente
    Todavía no hay soporte para clases, pero cuando el LLM intenta usarlas, ve el error y reescribe el código por su cuenta para no usar clases
    Hay un artículo que resume el proceso de compilación aquí

    • Es cierto, pero si se acumulan estas pequeñas molestias en niveles bajos de abstracción, el rendimiento en niveles superiores baja. El LLM termina gastando recursos en esquivar las limitaciones del intérprete de Python en vez de resolver el problema original
    • El proyecto está bueno, pero no se me ocurren bien casos de uso concretos. ¿Es para un modo código donde se reemplazan llamadas MCP por funciones de Monty, o para pre/postprocesamiento de consultas, o para implementar CaMeL?
      Si la ventaja de un agente de terminal es el acceso a red y sistema de archivos, entonces un contenedor sandbox se siente como una extensión más natural
    • Sinceramente no entiendo por qué sería necesario. Mis modelos ya escriben bien código en varios lenguajes, así que no veo por qué habría que forzarlos a usar solo Python limitado
      Uso Typescript, C# y Python sin problemas
    • Decir que “lo reescribe para no usar clases” significa que eso solo es posible cuando en los datos de entrenamiento ya hay suficiente código de ese estilo. Por suerte, quizá haya bastante código de Stack Overflow para eso

  • Me hizo recordar la época en que usaba Mercurial antes de pasarme a Git. En ese entonces Git era lo que todos usaban porque estaba de moda, pero yo sentía que el UX de Mercurial era mucho mejor
    Ahora todos escriben exec de agentes en Python, pero a mí me parece que TypeScript/JS encaja mejor. Es rápido, seguro y, gracias a los tipos, tiene mayor densidad de información. Pero esta vez también siento que me va a tocar perder

    • Hay tres razones por las que creo que Python es mejor que JS
      1. Una biblioteca estándar muy rica (CSV, sqlite3, json, etc.)
      2. El código escrito por LLM casi siempre funciona de inmediato. En JS hay demasiados factores inestables, como la división Node/Deno, la confusión con la sintaxis de imports y cosas como top-level await
      3. El ecosistema de procesamiento de datos es muchísimo más fuerte (csv/pandas, etc.)
    • Llevo más de 10 años usando Python y JS, y siempre termino sufriendo por manejo raro de excepciones o por problemas con chequeos de null/undefined. Por eso elegiría Python todos los días
    • Históricamente Python ha sido fuerte en el ecosistema científico y de IA. Eso viene de librerías como numpy, scipy y PyTorch
      Personalmente me gusta más el sistema de tipos estáticos de TypeScript, pero en velocidad o seguridad ambos lenguajes están más o menos en el mismo nivel
    • Si el agente puede ejecutar código, puede procesar datos directamente y así reducir el contexto.
      Python tiene muy buen ecosistema para este tipo de procesamiento, y con herramientas como Pyodide o ty también se pueden mitigar los problemas de seguridad
    • Gracias a la IA, CPython por fin está recibiendo presión para traer un JIT integrado. En GPU también hay muchos JIT basados en DSLs de Python, así que en la práctica la diferencia de rendimiento no es tan grande.
      Ahora hasta NVIDIA da soporte oficial para escribir kernels en Python

  • Este proyecto es una aproximación interesante al problema del sandboxing. Hace tiempo, en un experimento llamado jsrun, metieron V8 dentro de Python para ejecutar JS de forma segura
    Monty parece apuntar a algo parecido. Empezar con un intérprete mínimo encaja bien con cargas de trabajo de IA, pero lidiar con la larga cola de la sintaxis de Python no es fácil
    El punto de equilibrio importante está en reducir la superficie por seguridad y previsibilidad, sin dejar de ofrecer suficiente funcionalidad como para manejar el código complejo que generan los LLM

    • La meta es simplificar el modo código o las llamadas a funciones externas. A corto plazo, con soportar class, dataclass, datetime y json probablemente sería suficiente
    • Pero en entornos donde la seguridad importa de verdad, igual creo que el aislamiento basado en VM termina siendo indispensable. Un enfoque como Monty tiene muchas limitaciones prácticas (opinión de alguien que trabaja en E2B)

  • Esto ya es otra cosa, pero me hizo pensar en el libro de Monty Roberts, The Man Who Listens to Horses.
    Trata sobre aprender el lenguaje de los animales, y dejo el link del libro y un video

  • Me llamó la atención la descripción de “ejecutar de forma segura y ultrarrápida código Python escrito por LLM”.
    Aun así, incluso runtimes basados en Rust como uv tardan como mínimo unos 10 ms, así que lo de microsegundos suena difícil
    De todas formas, la idea de un mini intérprete sin biblioteca estándar está buena. También es novedosa desde el punto de vista del sandboxing para IA, y no esperaba algo así de Pydantic

    • Pydantic y FastAPI son de los equipos de Python más interesantes hoy. Siempre están sacando proyectos nuevos
    • Como referencia, uv es un runtime escrito en Rust

  • Yo creo que sería mejor crear un lenguaje estricto dedicado a IA en vez de reciclar lenguajes existentes
    La IA entiende bien las especificaciones, así que no necesita una gramática flexible pensada para humanos.
    Al contrario, un lenguaje que obligue a una estructura precisa y un formato consistente sería más adecuado.
    Yo mismo estoy experimentando con algo así, porque creo que a la generación de código por IA se le puede exigir más disciplina que a los humanos

    • Pero el problema es la cantidad de aprendizaje. Para que un modelo aprenda un lenguaje nuevo hace falta una cantidad enorme de datos.
      Es mucho más realista tomar un modelo que ya sabe bien Python y limitarlo con algo como “usa solo esta función”

  • El punto de jstanley sobre las pequeñas molestias (papercuts) es válido, pero por otro lado, cuando se ejecuta a gran escala código generado por IA, el riesgo de seguridad es todavía mayor
    Abrirle a un CPython completo cosas como I/O de archivos, red o subprocess es peligroso
    Igual la restricción con clases es rara. No tiene que ver con seguridad, solo hace que el código quede más desprolijo.
    Probablemente sea un enfoque de “arrancar con la mínima funcionalidad e ir expandiendo poco a poco”

    • Sí, la limitación con clases no es por seguridad, sino simplemente porque todavía no está implementado

  • Es interesante el enfoque de construir el intérprete mínimo necesario para código de IA, en vez de intentar imitar toda la funcionalidad de CPython
    Un runtime completo tiene una superficie de ataque demasiado grande, pero un subconjunto limitado es más seguro
    También suena realista la estrategia de usar la retroalimentación de errores para que el LLM se adapte por sí solo a una sintaxis limitada.
    En la mayoría de los escenarios de uso de herramientas no hacen falta metaclases ni imports dinámicos

  • Pregunta simple: ¿no bastaría con limitar las llamadas al sistema usando seccomp?
    Si se quiere bloquear el acceso a archivos, debería alcanzar con bloquear los syscalls relacionados, así que me pregunto por qué haría falta un intérprete aparte

    • Proyectos como bvisor van en esa dirección
    • Es un enfoque válido, pero si el runtime base es demasiado poderoso hay muchas más posibilidades de evasión.
      Si se empieza desde el principio con un runtime extremadamente simple, la superficie de ataque es pequeña y resulta mucho más seguro

  • El proyecto en sí parece razonable, pero eso de “herramienta ultrarrápida para IA” me causa gracia
    La velocidad de pensamiento de la IA ya es tan lenta que, por más rápido que sea ejecutar el código, la diferencia total percibida no cambia mucho
    Es como hacer entregas junto a un compañero que trabaja al lado tuyo a la velocidad de un glaciar moviéndose