Monty – Leichter Python-Interpreter zum sicheren Ausführen von AI-generiertem Code

 (github.com/pydantic)
8 Punkte von GN⁺ 2026-02-08 | 1 Kommentare | Auf WhatsApp teilen
  • Ein leichtgewichtiger, Rust-basierter Python-Interpreter, der für die sichere Ausführung von AI-generiertem Code entwickelt wurde und die Komplexität sowie Latenz von Container-Sandboxes beseitigt
  • Dateisystem-, Umgebungsvariablen- und Netzwerkzugriffe werden vollständig blockiert; aufrufbar sind nur externe Funktionen, die Entwickler explizit freigeben
  • Bietet eine Startzeit von unter 1 Mikrosekunde und eine Ausführungsleistung ähnlich zu CPython; aufrufbar aus Rust, Python und JavaScript
  • Der Ausführungszustand kann bytegenau als Snapshot gespeichert und wiederhergestellt werden, sodass Unterbrechung und Fortsetzung prozessübergreifend möglich sind
  • Soll die Funktion Code Mode von Pydantic AI antreiben und als zentrale Komponente für die sichere Ausführung von von LLMs geschriebenem Python-Code dienen

Überblick über Monty

  • Monty ist ein in Rust geschriebener experimenteller Python-Interpreter als Werkzeug zur sicheren Ausführung von AI-generiertem Code
    • Vermeidet Kosten, Latenz und Komplexität containerbasierter Sandboxes und kann von LLMs geschriebenen Python-Code direkt ausführen
    • Die Startzeit liegt im Bereich von wenigen Mikrosekunden und ist damit deutlich schneller als die typischen mehreren hundert Millisekunden bei Containern
  • Mögliche Funktionen
    • Unterstützt die Ausführung von Teilen der Python-Syntax, einschließlich statischer Typprüfung auf Basis von Type Hints
    • Host-Zugriff vollständig blockiert; externe Funktionen können nur aufgerufen werden, wenn sie vom Entwickler ausdrücklich erlaubt wurden
    • Aufrufbar aus Rust, Python und JavaScript; mit integrierter Verfolgung und Begrenzung des Ressourcenverbrauchs
    • Unterstützt Erfassung von stdout/stderr, Ausführung asynchronen Codes sowie Speichern und Wiederherstellen von Snapshots
  • Einschränkungen
    • In der Standardbibliothek sind nur sys, typing, asyncio, dataclasses(geplant) und json(geplant) verfügbar
    • Klassendefinitionen und match-Anweisungen werden derzeit noch nicht unterstützt
    • Third-Party-Bibliotheken werden nicht unterstützt
  • Das Design verfolgt nur ein Ziel: von Agenten geschriebenen Code sicher auszuführen

Integration mit Pydantic AI

  • Monty treibt den Code Mode von Pydantic AI an
    • Das LLM schreibt Python-Code statt Tool-Aufrufen, und Monty führt ihn sicher aus
    • Im Beispiel werden funktionale Tools wie get_weather und get_population definiert, und das LLM schreibt Code, der diese aufruft

Vergleich mit Alternativen

  • Monty ist bei der Vollständigkeit der Sprache eingeschränkt, überzeugt aber bei Sicherheit, Geschwindigkeit und Einfachheit
    • Startlatenz 0,06 ms, kostenlos, einfache Installation, unterstützt Snapshots
  • Kurzvergleich mit anderen Technologien:
    • Docker: vollständige CPython-Umgebung, gute Sicherheit, aber Startlatenz von 195 ms
    • Pyodide: WASM-basiert, schwächere Sicherheit und Startlatenz von 2800 ms
    • starlark-rust: sehr eingeschränkte Sprache, schnell, aber nicht Python
    • Sandboxing-Services: starke Sicherheit, aber Kosten, Latenz und komplexe Einrichtung
    • YOLO Python(exec/subprocess): schnell, aber ohne jegliche Sicherheit
  • Mit Dateizugriffskontrolle, Ressourcenlimits und snapshotbasierter Unterbrechung/Fortsetzung bietet Monty eine
    sichere Python-Umgebung für die Ausführung von AI-Code

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-08
Hacker-News-Kommentare

  • Ich habe eine mit WebAssembly gebaute Version ausprobiert. Dafür wurde ein Web-Playground erstellt, den man direkt testen kann
    Klassenunterstützung gibt es noch nicht, aber wenn ein LLM versucht, Klassen zu verwenden, sieht es den Fehler und schreibt den Code selbst in eine Version ohne Klassen um
    Ein Beitrag, der den Build-Prozess zusammenfasst, ist hier zu finden

    • Das stimmt zwar, aber wenn sich solche kleinen Unannehmlichkeiten auf einer niedrigeren Abstraktionsebene ansammeln, leidet die Performance auf höherer Ebene. Das LLM verwendet dann Ressourcen darauf, Schwächen des Python-Interpreters zu umgehen, statt das eigentliche Problem zu lösen
    • Cooles Projekt, aber mir fällt kein konkreter Anwendungsfall ein. Ist das für einen Code-Mode gedacht, der MCP-Aufrufe durch Monty-Funktionen ersetzt, oder für Anfrage-Vor-/Nachverarbeitung oder eine CaMeL-Implementierung?
      Die Stärke von Terminal-Agenten ist doch der Zugriff auf Netzwerk und Dateisystem; dann wirkt ein Sandbox-Container wie die naheliegende Erweiterung
    • Ehrlich gesagt verstehe ich nicht, warum das nötig ist. Meine Modelle schreiben schon jetzt problemlos Code in mehreren Sprachen, warum sollte ich mich absichtlich auf eingeschränktes Python festlegen?
      TypeScript, C# und Python funktionieren alle ohne Probleme
    • Die Aussage „schreibt den Code in eine Version ohne Klassen um“ heißt letztlich, dass das nur funktioniert, wenn es in den Trainingsdaten genug solchen Code gibt. Zum Glück gibt es viel Code von Stack Overflow, also könnte das reichen

  • Das erinnert mich an die Zeit, als ich vor dem Wechsel zu Git noch Mercurial genutzt habe. Damals war Git zwar der Trend und schien das zu sein, was alle verwendeten, aber ich fand die UX von Mercurial deutlich besser
    Heute schreiben alle agent exec in Python, aber ich habe das Gefühl, dass TypeScript/JS besser geeignet ist. Schnell, sicher und dank Typen mit höherer Informationsdichte. Aber vermutlich werde ich auch diesmal verlieren

    • Ich finde Python aus drei Gründen besser als JS
      1. die umfangreiche Standardbibliothek (CSV, sqlite3, json usw.)
      2. von LLMs geschriebener Code läuft meistens direkt. Bei JS gibt es viele Unsicherheitsfaktoren wie die Trennung zwischen Node und Deno, Verwirrung bei der Import-Syntax und top-level await
      3. das Ökosystem für Datenverarbeitung ist viel stärker (csv/pandas usw.)
    • Ich benutze seit über 10 Jahren Python und JS, und jedes Mal musste ich mich mit seltsamer Exception-Behandlung oder null/undefined-Prüfungen herumschlagen. Deshalb würde ich jeden Tag Python wählen
    • Historisch ist Python stark im Wissenschafts- und AI-Ökosystem. Das liegt an Bibliotheken wie numpy, scipy und PyTorch
      Persönlich mag ich das statische Typsystem von TypeScript lieber, aber bei Geschwindigkeit oder Sicherheit liegen beide Sprachen auf einem ähnlichen Niveau
    • Wenn ein Agent Code ausführen kann, kann er Daten direkt verarbeiten und so den Kontext verkleinern.
      Python hat dafür ein gutes Datenverarbeitungs-Ökosystem, und mit Tools wie Pyodide oder ty lassen sich Sicherheitsprobleme ebenfalls abmildern
    • Dank AI steht selbst CPython inzwischen unter Druck, endlich JIT eingebaut zu bekommen. Auch auf der GPU-Seite gibt es viele JITs auf Basis von Python-DSLs, sodass der tatsächliche Performance-Unterschied nicht groß ist.
      Inzwischen unterstützt sogar NVIDIA offiziell das Schreiben von Kerneln in Python

  • Dieses Projekt ist ein interessanter Ansatz für das Sandboxing-Problem. In einem früheren Experiment namens jsrun wurde V8 in Python eingebettet, um JS sicher auszuführen
    Monty scheint ein ähnliches Ziel zu haben. Mit einem minimalen Interpreter zu beginnen, passt gut zu AI-Workloads, aber die lange Liste seltener Python-Syntaxfälle abzudecken, ist nicht einfach
    Wichtig ist ein Gleichgewichtspunkt, bei dem man die Angriffsfläche zugunsten von Sicherheit und Vorhersagbarkeit reduziert und trotzdem genug Funktionen bietet, um auch komplexeren, von LLMs erzeugten Code zu verarbeiten

    • Das Ziel ist, Code-Mode oder externe Funktionsaufrufe zu vereinfachen. Kurzfristig dürften class, dataclass, datetime und json schon ausreichen
    • Aber in Umgebungen, in denen Sicherheit wichtig ist, halte ich letztlich VM-basierte Isolation für unverzichtbar. Ein Ansatz wie Monty hat viele praktische Einschränkungen (Meinung eines E2B-Mitarbeiters)

  • Etwas abseits vom Thema, aber ich musste an das Buch Monty Roberts' The Man Who Listens to Horses denken.
    Es geht darum, die Sprache von Tieren zu lernen, und hier sind ein Buchlink und ein Video

  • Die Beschreibung „führt von LLMs geschriebenen Python-Code superschnell und sicher aus“ fand ich interessant.
    Allerdings brauchen selbst Rust-basierte Runtimes wie uv mindestens etwa 10 ms, daher wirken Mikrosekunden unrealistisch
    Trotzdem gefällt mir die Idee eines Mini-Interpreters ohne Standardbibliothek. Auch aus AI-Sandboxing-Sicht ist das neu, und ich hätte nicht erwartet, dass so etwas von Pydantic kommt

    • Pydantic und FastAPI sind derzeit eines der spannendsten Python-Teams. Sie bringen ständig neue Projekte heraus
    • Zur Klarstellung: uv ist eine in Rust geschriebene Runtime

  • Ich denke, statt bestehende Sprachen wiederzuverwenden, wäre es besser, eine strenge Sprache speziell für AI zu entwickeln
    AI versteht Spezifikationen gut, also braucht sie keine lockere Syntax wie Menschen.
    Im Gegenteil, eine Sprache, die präzise Struktur und konsistente Formate erzwingt, wäre besser geeignet.
    Ich experimentiere selbst mit so einer Sprache und denke, dass man bei AI-Codegenerierung mehr Disziplin verlangen kann als von Menschen

    • Das Problem ist aber die Lernmenge. Damit ein Modell eine neue Sprache lernt, braucht es enorme Datenmengen.
      Es ist viel realistischer, ein Modell, das Python bereits gut beherrscht, einfach auf „verwende nur diese Funktionen“ zu beschränken

  • Der von jstanley angesprochene Punkt mit den kleinen Unannehmlichkeiten (papercuts) stimmt zwar, aber umgekehrt ist beim großflächigen Ausführen von AI-generiertem Code das Sicherheitsrisiko größer
    Dateizugriffe, Netzwerk und subprocess in einem vollständigen CPython zu öffnen, ist riskant
    Die Klassenbeschränkung wirkt allerdings seltsam. Mit Sicherheit hat sie nichts zu tun, sie macht den Code nur unsauberer.
    Wahrscheinlich ist es einfach ein Ansatz nach dem Motto „mit minimaler Funktionalität beginnen und schrittweise erweitern“

    • Genau, die Einschränkung bei Klassen dient nicht der Sicherheit, sondern ist einfach noch nicht implementiert

  • Statt die gesamte Funktionalität von CPython nachzuahmen, ist der Ansatz interessant, einen minimalen Interpreter nur für AI-Code zu bauen
    Eine vollständige Runtime hat eine viel zu große Angriffsfläche, aber ein eingeschränktes Subset ist sicherer
    Auch die Strategie, das LLM sich über Fehler-Feedback selbst an die eingeschränkte Syntax anpassen zu lassen, wirkt praxisnah.
    In den meisten Tool-Use-Szenarien braucht man weder Metaklassen noch dynamische Imports

  • Eine einfache Frage: Reicht es nicht, mit seccomp Systemaufrufe zu beschränken?
    Wenn man Dateizugriffe blockieren will, könnte man die entsprechenden Syscalls sperren; warum braucht man dann überhaupt einen separaten Interpreter?

    • Projekte wie bvisor gehen in genau diese Richtung
    • Das ist ein sinnvoller Ansatz, aber wenn die Basis-Runtime zu mächtig ist, gibt es viele Umgehungsmöglichkeiten.
      Wenn man stattdessen von Anfang an mit einer extrem einfachen Runtime startet, ist die Angriffsfläche klein und damit deutlich sicherer

  • Das Projekt selbst wirkt vernünftig, aber bei der Formulierung „ultraschnelles Tool für AI“ muss ich trotzdem lachen
    Die Denkgeschwindigkeit von AI ist ohnehin so langsam, dass selbst extrem schnelle Codeausführung am subjektiven Gesamttempo kaum etwas ändert
    Es fühlt sich an, als würde man zusammen mit einem Kollegen ausliefern, der sich neben einem mit der Geschwindigkeit eines wandernden Gletschers bewegt