Monty - Interpreter Python ringan untuk menjalankan kode buatan AI dengan aman

 (github.com/pydantic)
8 poin oleh GN⁺ 2026-02-08 | 1 komentar | Bagikan ke WhatsApp
  • Interpreter Python ringan berbasis Rust yang dirancang untuk menjalankan kode buatan AI dengan aman, menghilangkan kompleksitas dan latensi sandbox container
  • Sepenuhnya memblokir akses ke filesystem, environment variable, dan jaringan, dan hanya mengizinkan pemanggilan fungsi eksternal yang ditentukan pengembang
  • Menawarkan waktu startup di bawah 1 mikrodetik dan performa eksekusi yang mirip CPython, serta bisa dipanggil dari Rust, Python, dan JavaScript
  • Status eksekusi dapat disimpan dan dipulihkan sebagai snapshot pada level byte, sehingga dapat dihentikan dan dilanjutkan antarproses
  • Akan menjadi penggerak fitur Code Mode di Pydantic AI, dan digunakan sebagai komponen inti untuk menjalankan kode Python yang ditulis LLM dengan aman

Ikhtisar Monty

  • Monty adalah interpreter Python eksperimental yang ditulis dalam Rust, sebagai alat untuk menjalankan kode buatan AI dengan aman
    • Menghindari biaya, latensi, dan kompleksitas sandbox berbasis container, serta memungkinkan kode Python yang ditulis LLM dijalankan secara langsung
    • Waktu startup berada di kisaran beberapa mikrodetik, jauh lebih cepat dibanding container umum yang memerlukan ratusan milidetik
  • Kemampuan yang tersedia
    • Mendukung eksekusi sebagian sintaks Python, termasuk static type checking berbasis type hint
    • Akses ke host diblokir sepenuhnya, dan pemanggilan fungsi eksternal hanya dimungkinkan untuk fungsi yang secara eksplisit diizinkan pengembang
    • Dapat dipanggil dari Rust, Python, dan JavaScript, serta memiliki fitur bawaan untuk pelacakan dan pembatasan penggunaan resource
    • Mendukung pengumpulan stdout/stderr, eksekusi kode asinkron, serta penyimpanan dan pemulihan snapshot
  • Keterbatasan
    • Standard library yang dapat digunakan saat ini hanya sys, typing, asyncio, dataclasses(akan datang), dan json(akan datang)
    • Definisi class dan pernyataan match masih belum didukung
    • Library pihak ketiga tidak didukung
  • Tujuan desainnya hanya satu, yaitu menjalankan kode yang ditulis agen dengan aman

Integrasi dengan Pydantic AI

  • Monty akan menjalankan Code Mode milik Pydantic AI
    • LLM menulis kode Python alih-alih melakukan tool calling, lalu Monty mengeksekusinya dengan aman
    • Dalam contoh, didefinisikan tool berbentuk fungsi seperti get_weather dan get_population, lalu LLM menulis kode untuk memanggilnya

Perbandingan dengan teknologi alternatif

  • Monty memiliki kelengkapan bahasa yang terbatas, tetapi unggul dalam keamanan, kecepatan, dan kesederhanaan
    • Latensi startup 0.06ms, gratis, mudah dipasang, dan mendukung fitur snapshot
  • Ringkasan perbandingan dengan teknologi lain:
    • Docker: lingkungan CPython penuh, keamanan baik tetapi latensi startup 195ms
    • Pyodide: berbasis WASM, keamanan lemah dan latensi startup 2800ms
    • starlark-rust: bahasa sangat terbatas, cepat tetapi berbeda dari Python
    • layanan sandboxing: keamanan kuat tetapi mahal, lambat, dan konfigurasi rumit
    • YOLO Python(exec/subprocess): cepat tetapi tanpa keamanan sama sekali
  • Monty menyediakan lingkungan Python aman untuk eksekusi kode AI melalui fitur kontrol akses file, pembatasan resource, dan penghentian/pelanjutan berbasis snapshot

Bacaan terkait

1 komentar

 
GN⁺ 2026-02-08
Komentar Hacker News

  • Saya sempat menjalankan versi yang dibangun dengan WebAssembly. Mereka juga membuat web playground untuk dicoba langsung
    Saat ini memang belum ada dukungan class, tetapi ketika LLM mencoba memakai class, ia melihat error lalu menulis ulang sendiri menjadi kode yang tidak memakai class
    Tulisan yang merangkum proses build ada di sini

    • Itu memang benar, tetapi jika gangguan kecil di level abstraksi rendah seperti ini menumpuk, performa di level yang lebih tinggi akan menurun. LLM jadi memakai sumber daya untuk mengakali keterbatasan interpreter Python alih-alih menyelesaikan masalah aslinya
    • Proyek yang keren, tetapi saya belum terlalu bisa membayangkan use case yang spesifik. Apakah ini untuk code mode yang mengganti pemanggilan MCP dengan fungsi Monty, atau untuk pra/pasca-pemrosesan kueri dan implementasi CaMeL?
      Kekuatan agen terminal justru ada pada akses jaringan dan filesystem, jadi kalau begitu sandbox container terasa seperti perluasan yang lebih alami
    • Sejujurnya saya tidak paham kenapa ini diperlukan. Model saya sudah bisa menulis kode dengan baik dalam banyak bahasa, jadi kenapa harus memakai Python yang dibatasi?
      Typescript, C#, dan Python semuanya berjalan tanpa masalah
    • Kalimat “menulis ulang menjadi kode yang tidak memakai class” pada akhirnya hanya mungkin jika di data pelatihan memang ada cukup banyak contoh kode semacam itu. Untungnya mungkin ada banyak kode dari Stack Overflow, jadi bisa saja tetap berhasil

  • Ini mengingatkan saya pada masa dulu memakai Mercurial sebelum pindah ke Git. Waktu itu Git sedang tren sehingga semua orang tampak memakainya, tetapi menurut saya UX Mercurial jauh lebih baik
    Sekarang semua orang menulis agent exec dengan Python, tetapi saya merasa TypeScript/JS lebih cocok. Lebih cepat, lebih aman, dan berkat tipe, kepadatan informasinya juga lebih tinggi. Tapi sepertinya kali ini pun saya akan kalah

    • Ada tiga alasan mengapa saya menganggap Python lebih baik daripada JS
      1. Pustaka standar yang kaya (CSV, sqlite3, json, dll.)
      2. Kode yang ditulis LLM biasanya langsung jalan. Di JS ada banyak unsur yang tidak stabil seperti perbedaan Node/Deno, kebingungan sintaks import, dan top-level await
      3. Ekosistem pemrosesan data jauh lebih kuat (csv/pandas, dll.)
    • Saya sudah memakai Python dan JS lebih dari 10 tahun, dan setiap kali selalu kerepotan dengan penanganan exception yang aneh atau masalah pengecekan null/undefined. Jadi saya akan memilih Python setiap hari
    • Secara historis, Python kuat dalam ekosistem sains dan AI. Itu berkat library seperti numpy, scipy, dan PyTorch
      Secara pribadi saya lebih suka sistem tipe statis di TypeScript, tetapi dari sisi kecepatan maupun keamanan, kedua bahasa itu kurang lebih setara
    • Jika agen bisa mengeksekusi kode, ia bisa memproses data secara langsung sehingga konteks bisa dikurangi.
      Python punya ekosistem pemrosesan data yang matang, dan dengan alat seperti Pyodide atau ty, masalah keamanan juga bisa dikurangi
    • Berkat AI, CPython akhirnya juga mendapat tekanan untuk menyertakan JIT. Di sisi GPU pun banyak JIT berbasis DSL Python, jadi perbedaan performa nyata tidak terlalu besar.
      Sekarang bahkan NVIDIA secara resmi mendukung penulisan kernel dengan Python

  • Proyek ini adalah pendekatan yang menarik terhadap masalah sandboxing. Dulu ada eksperimen bernama jsrun yang menanamkan V8 ke dalam Python untuk menjalankan JS dengan aman
    Monty tampaknya punya tujuan serupa. Memulai dari interpreter yang minimal cocok untuk workload AI, tetapi menangani ekor panjang sintaks Python bukan hal mudah
    Titik pentingnya adalah menemukan keseimbangan: mengurangi permukaan fitur demi keamanan dan prediktabilitas, sambil tetap menyediakan cukup kemampuan untuk menangani kode kompleks yang dihasilkan LLM

    • Tujuannya adalah menyederhanakan code mode atau pemanggilan fungsi eksternal. Dalam jangka pendek, sepertinya cukup jika mendukung class, dataclass, datetime, dan json
    • Namun di lingkungan yang sangat mementingkan keamanan, saya tetap berpikir isolasi berbasis VM pada akhirnya wajib. Pendekatan seperti Monty punya banyak keterbatasan nyata (pendapat pekerja E2B)

  • Cerita yang agak berbeda, tetapi ini mengingatkan saya pada buku Monty Roberts, The Man Who Listens to Horses.
    Isinya tentang mempelajari bahasa hewan, dan ada tautan buku serta video

  • Deskripsi “menjalankan kode Python yang ditulis LLM dengan aman pada kecepatan super tinggi” terasa menarik.
    Hanya saja, runtime berbasis Rust seperti uv pun minimal butuh sekitar 10 ms, jadi skala mikrodetik tampak sulit
    Meski begitu, ide interpreter mini tanpa pustaka standar ini bagus. Dari sudut pandang sandboxing AI juga terasa baru, dan saya tidak menyangka hal seperti ini akan keluar dari Pydantic

    • Pydantic dan FastAPI adalah tim Python yang paling menarik belakangan ini. Mereka selalu merilis proyek baru
    • Sebagai catatan, uv adalah runtime yang ditulis dengan Rust

  • Saya merasa daripada mendaur ulang bahasa yang sudah ada, akan lebih baik membuat bahasa ketat khusus AI
    AI memahami spesifikasi dengan baik, jadi tidak membutuhkan sintaks longgar seperti manusia.
    Justru bahasa yang memaksakan struktur presisi dan format yang konsisten akan lebih cocok.
    Saya sendiri sedang bereksperimen dengan bahasa seperti itu, karena menurut saya generasi kode AI bisa menuntut disiplin yang lebih tinggi daripada manusia

    • Tetapi masalahnya adalah jumlah pembelajaran. Agar model belajar bahasa baru, dibutuhkan data dalam jumlah sangat besar.
      Jauh lebih realistis membatasi model yang sudah mahir Python dengan aturan seperti “pakai fungsi ini saja”

  • Poin “gangguan kecil (papercut)” yang disampaikan jstanley memang benar, tetapi di sisi lain, saat menjalankan kode buatan AI dalam skala besar, risiko keamanan jauh lebih besar
    Membuka fitur seperti file I/O, jaringan, dan subprocess ke CPython penuh itu berbahaya
    Tetapi pembatasan class memang terasa aneh. Itu tidak ada hubungannya dengan keamanan, hanya membuat kode jadi lebih berantakan.
    Mungkin ini pendekatan “mulai dari fitur minimum lalu diperluas bertahap”

    • Betul, pembatasan class bukan untuk tujuan keamanan, hanya karena memang belum diimplementasikan

  • Daripada meniru seluruh fitur CPython, pendekatan membuat interpreter minimal yang hanya dibutuhkan kode AI terasa menarik
    Runtime penuh punya permukaan serangan yang terlalu luas, tetapi subset yang terbatas lebih aman
    Strategi memanfaatkan umpan balik error agar LLM beradaptasi sendiri dengan sintaks terbatas juga terasa realistis.
    Dalam kebanyakan skenario penggunaan tool, metaclass atau dynamic import memang tidak dibutuhkan

  • Pertanyaan sederhana, tetapi apakah tidak cukup membatasi system call dengan seccomp?
    Jika ingin memblokir akses file, bukankah cukup memblokir syscall terkait? Saya penasaran kenapa perlu interpreter terpisah

    • Proyek seperti bvisor bergerak ke arah itu
    • Itu pendekatan yang benar, tetapi kalau runtime dasarnya terlalu kuat, peluang untuk mengakalinya juga banyak.
      Jika sejak awal mulai dari runtime yang sangat sederhana, permukaan serangannya kecil dan jauh lebih aman

  • Proyeknya sendiri masuk akal, tetapi frasa “tool super cepat untuk AI” tetap terasa lucu
    Kecepatan berpikir AI sendiri sangat lambat, jadi secepat apa pun eksekusi kodenya, pengaruhnya pada kecepatan yang benar-benar terasa tidak akan besar
    Rasanya seperti mengantar barang bersama rekan kerja di sebelah yang bergerak dengan kecepatan gletser