Monty - interpretador Python leve para executar com segurança código gerado por IA

• Interpretador Python leve baseado em Rust projetado para executar com segurança código gerado por IA, eliminando a complexidade e a latência de sandboxes em contêineres
• Bloqueia completamente o acesso ao sistema de arquivos, variáveis de ambiente e rede, permitindo chamar apenas funções externas especificadas pelo desenvolvedor
• Oferece tempo de inicialização inferior a 1 microssegundo e desempenho de execução semelhante ao do CPython, podendo ser chamado de Rust, Python e JavaScript
• O estado de execução pode ser salvo e restaurado por snapshot em nível de byte, permitindo interrupção e retomada entre processos
• Deve alimentar o recurso Code Mode do Pydantic AI e será usado como componente central para executar com segurança código Python escrito por LLMs

---

Visão geral do Monty

• Monty é um interpretador Python experimental escrito em Rust, uma ferramenta para executar com segurança código gerado por IA
  • Evita o custo, a latência e a complexidade de sandboxes baseadas em contêiner, permitindo executar diretamente código Python escrito por LLMs
  • O tempo de inicialização fica na faixa de alguns microssegundos, muito mais rápido que as centenas de milissegundos de contêineres comuns
• Recursos disponíveis
  • Suporte à execução de parte da sintaxe do Python, incluindo checagem estática de tipos baseada em type hints
  • Bloqueio total de acesso ao host, com chamadas de funções externas permitidas apenas para funções explicitamente autorizadas pelo desenvolvedor
  • Pode ser chamado de Rust, Python e JavaScript e traz recursos nativos para rastrear e limitar o uso de recursos
  • Suporte a coleta de stdout/stderr, execução de código assíncrono e salvar/restaurar snapshots
• Limitações
  • A biblioteca padrão permite apenas sys, typing, asyncio, dataclasses(planejado) e json(planejado)
  • Definições de classe e instruções match ainda não são compatíveis
  • Bibliotecas de terceiros não são suportadas
• O objetivo do design é um só: executar com segurança código escrito por agentes

Integração com o Pydantic AI

• O Monty alimenta o Code Mode do Pydantic AI
  • Em vez de chamadas de ferramenta, o LLM escreve código Python, e o Monty o executa com segurança
  • No exemplo, são definidas ferramentas funcionais como get_weather e get_population, e o LLM escreve código que as chama

Comparação com tecnologias alternativas

• O Monty tem completude de linguagem limitada, mas se destaca em segurança, velocidade e simplicidade
  • Latência de inicialização de 0,06 ms, gratuito, instalação simples e suporte a snapshots
• Resumo da comparação com outras tecnologias:
  • Docker: ambiente CPython completo, boa segurança, mas latência de inicialização de 195 ms
  • Pyodide: baseado em WASM, segurança fraca e latência de inicialização de 2800 ms
  • starlark-rust: linguagem muito limitada, rápida, mas diferente de Python
  • serviços de sandboxing: segurança forte, mas com custo, latência e configuração complexa
  • YOLO Python(exec/subprocess): rápido, mas sem nenhuma segurança
• O Monty fornece um ambiente Python seguro para execução de código de IA por meio de controle de acesso a arquivos, limites de recursos e interrupção/retomada baseada em snapshots

[GN⁺]

Comentários do Hacker News

• Testei uma versão compilada para WebAssembly. Foi criado um playground web para testar diretamente
  Ainda não há suporte a classes, mas quando o LLM tenta usar classes, ele vê o erro e reescreve sozinho o código para não usar classes
  Há um texto resumindo o processo de build aqui

  • Faz sentido, mas esses pequenos incômodos em níveis mais baixos de abstração vão se acumulando e reduzem o desempenho em níveis superiores. O LLM acaba gastando recursos contornando limitações do interpretador Python em vez de resolver o problema em si
  • Projeto legal, mas não consigo imaginar bem um caso de uso concreto. É para um modo de código que substitui chamadas MCP por funções do Monty, ou para pré/pós-processamento de consultas ou implementação de CaMeL?
    O ponto forte de agentes de terminal é o acesso à rede e ao sistema de arquivos, então nesse caso um contêiner sandbox parece uma extensão mais natural
  • Sinceramente não entendo por que isso é necessário. Meus modelos já escrevem código bem em várias linguagens, então por que eu teria que usar só Python limitado?
    Estou usando Typescript, C# e Python sem problemas
  • Dizer que “reescreve para um código sem classes” significa, no fim das contas, que isso só é possível quando há dados de treinamento suficientes com esse tipo de código. Felizmente pode ser que haja bastante código do Stack Overflow para isso

• Isso me lembra da época em que eu usava Mercurial antes de migrar para Git. Na época Git estava na moda e parecia que todo mundo usava, mas eu achava a UX do Mercurial muito melhor
  Agora todo mundo escreve exec de agent em Python, mas eu sinto que TypeScript/JS é mais adequado. É rápido, seguro e, por causa dos tipos, tem densidade de informação maior. Mas acho que dessa vez eu também vou perder

  • Tenho três razões para achar Python melhor que JS
    1. biblioteca padrão rica (CSV, sqlite3, json etc.)
    2. O código escrito pelo LLM quase sempre funciona de cara. Em JS há muitos fatores instáveis, como divisão entre Node/Deno, confusão com sintaxe de import e top-level await
    3. O ecossistema de processamento de dados é muito mais forte (csv/pandas etc.)
  • Uso Python e JS há mais de 10 anos, e sempre sofri com tratamento de exceções esquisito ou com problemas de verificação de null/undefined. Então eu escolheria Python todos os dias
  • Historicamente, Python é forte no ecossistema científico e de IA. Isso se deve a bibliotecas como numpy, scipy e PyTorch
    Pessoalmente eu prefiro o sistema de tipos estáticos do TypeScript, mas em termos de velocidade e segurança as duas linguagens estão em nível parecido
  • Se o agente consegue executar código, ele pode processar dados diretamente, o que reduz o contexto necessário.
    Python tem um bom ecossistema para esse tipo de processamento, e ferramentas como Pyodide ou ty também ajudam a mitigar questões de segurança
  • Graças à IA, até o CPython finalmente está sofrendo pressão para ter JIT embutido. No lado de GPU também há muitos JITs baseados em DSL de Python, então a diferença real de desempenho não é tão grande.
    Agora até a NVIDIA oferece suporte oficial para escrever kernels em Python

• Este projeto é uma abordagem interessante para o problema de sandboxing. Em um experimento antigo chamado jsrun, já colocaram o V8 dentro do Python para executar JS com segurança
  O Monty parece ter um objetivo parecido. Começar com um interpretador mínimo faz sentido para workloads de IA, mas lidar com a cauda longa da sintaxe do Python não é fácil
  É importante encontrar o ponto de equilíbrio entre reduzir a superfície por segurança e previsibilidade, mas ainda oferecer funcionalidade suficiente para lidar até com código complexo gerado por LLMs

  • O objetivo é simplificar code mode ou chamadas de função externas. No curto prazo, parece que bastaria suportar class, dataclass, datetime e json
  • Mas em ambientes onde segurança é crítica, no fim acho que isolamento baseado em VM é indispensável. Uma abordagem como a do Monty tem muitas limitações práticas (opinião de alguém da E2B)

• É um pouco fora do assunto, mas isso me lembrou do livro Monty Roberts, The Man Who Listens to Horses.
  É sobre aprender a linguagem dos animais, e há um link do livro e um vídeo

• Achei interessante a descrição “executar com segurança, em altíssima velocidade, código Python escrito por LLM”.
  Mas até runtimes baseados em Rust como uv levam pelo menos uns 10 ms, então escala de microssegundos parece difícil
  Ainda assim, a ideia de um mini-interpretador sem biblioteca padrão é boa. Também é algo novo do ponto de vista de sandboxing para IA, e eu não esperava ver isso vindo da Pydantic

  • Pydantic e FastAPI são hoje a equipe Python mais interessante. Estão sempre lançando projetos novos
  • Só para constar, uv é um runtime escrito em Rust

• Acho melhor criar uma linguagem estrita voltada para IA do que reaproveitar linguagens existentes
  A IA entende bem especificações, então não precisa de sintaxe frouxa como humanos precisam.
  Pelo contrário, uma linguagem que imponha estrutura exata e formato consistente parece mais adequada.
  Também estou experimentando algo assim, e acho que para geração de código por IA dá para exigir um nível de disciplina maior do que se exigiria de humanos

  • Mas o problema é a quantidade de aprendizado. Para um modelo aprender uma nova linguagem, seria preciso uma quantidade enorme de dados.
    É muito mais realista restringir um modelo que já conhece bem Python com algo do tipo “use apenas estas funções”

• O ponto dos “pequenos incômodos” mencionado por jstanley faz sentido, mas por outro lado, ao executar em larga escala código gerado por IA, o risco de segurança é maior
  É perigoso abrir recursos como I/O de arquivos, rede e subprocess para um CPython completo
  Mas a restrição de classes é estranha. Isso não tem relação com segurança, só deixa o código mais feio.
  Provavelmente é uma abordagem de “começar com o mínimo e expandir gradualmente”

  • Sim, a limitação de classes não é por segurança, e sim porque isso ainda não foi implementado

• Em vez de tentar imitar toda a funcionalidade do CPython, é interessante a abordagem de criar um interpretador mínimo com apenas o necessário para código de IA
  Um runtime completo tem uma superfície de ataque grande demais, mas um subconjunto restrito é seguro
  A estratégia de usar feedback de erro para levar o LLM a se adaptar sozinho à sintaxe limitada também é realista.
  Na maioria dos cenários de uso de ferramentas, não há necessidade de metaclasses nem import dinâmico

• Pergunta simples: por que não restringir syscalls com seccomp?
  Se a ideia é bloquear acesso a arquivos, não bastaria bloquear as syscalls relacionadas? Fiquei curioso sobre por que seria necessário um interpretador separado

  • Projetos como bvisor estão indo nessa direção
  • É uma abordagem válida, mas se o runtime base for poderoso demais, há muitas possibilidades de contorno.
    Se você começa com um runtime extremamente simples desde o início, a superfície de ataque é pequena e fica muito mais seguro

• O projeto em si parece razoável, mas a expressão “ferramenta ultrarrápida para IA” me fez rir
  A velocidade de raciocínio da IA é tão lenta que, por mais rápida que seja a execução do código, a diferença na sensação de velocidade total não é grande
  É como fazer entregas ao lado de um colega que trabalha na velocidade de uma geleira se movendo