- Perangkat lunak AI membutuhkan karakteristik seperti sistem operasi yang melampaui sekadar pemanggilan model, dengan menyediakan keamanan, isolasi, skalabilitas, dan portabilitas, dan untuk itu diajukan konsep mesin virtual khusus model AI (MVM)
- Seperti Java Virtual Machine (JVM) yang memungkinkan keamanan memori dan “tulis sekali, jalankan di mana saja”, AI VM juga memisahkan model dan logika integrasi untuk menjamin kemampuan saling ganti dan interoperabilitas
- VM mendefinisikan set instruksi standar seperti pemanggilan model, pemanggilan tool, penyimpanan hasil, input pengguna, dan percabangan kondisional, sehingga perilaku model dapat dibatasi dan dilacak dengan aman
- Riset yang sudah ada seperti structured tool calling dari OpenAI, MCP dari Anthropic, FIDES/AC4A dari Microsoft, serta runtime open source telah menunjukkan arah standardisasi
- AI VM yang terdefinisi dengan baik dapat memungkinkan penguatan keamanan dan privasi, pemantauan kinerja, verifikasi output, serta pembangunan ekosistem lintas platform, dan berpotensi menjadi infrastruktur inti yang membuat sistem AI lebih tepercaya dan aman
Pengenalan
- Model AI digunakan dalam perangkat lunak untuk berbagai keperluan, seperti application copilot, integrasi IDE, dan penggunaan tool melalui protokol MCP
- Perkembangan ini meningkatkan kebutuhan untuk menjamin privasi, keamanan, dan operasi yang akurat
- Keamanan dan privasi harus dijamin sejak tahap perancangan sistem; menambahkannya belakangan tidaklah cukup
- Terinspirasi dari Java Virtual Machine (JVM), diajukan pentingnya mesin virtual terstandarisasi untuk model AI
- JVM menyediakan lingkungan eksekusi yang andal melalui keamanan memori, kontrol akses, dan verifikasi bytecode
- Dengan ini, “tulis sekali, jalankan di mana saja” menjadi mungkin
Peran Mesin Virtual Model AI (MVM)
- MVM berfungsi sebagai perangkat lunak perantara antara model AI dan lingkungan eksternal
- Contoh: ketika pengguna memasukkan prompt “pesan penerbangan”, MVM meneruskannya ke model (termasuk penambahan konteks)
- Jika model merespons dengan “gunakan tool pemesanan”, MVM memeriksa daftar tool yang diizinkan lalu memutuskan apakah tool tersebut akan dipanggil
- Ini memastikan model tidak melakukan pemanggilan yang tidak diizinkan
- Semua sistem AI komersial memerlukan perangkat lunak kontrol serupa
- MVM mendefinisikan set instruksi, misalnya:
- autentikasi, pemuatan, inisialisasi, dan pelepasan model
- pemanggilan model dengan menyertakan konteks
- parsing output model
- autentikasi, pemuatan, pemanggilan tool, parsing hasil, serta penyimpanan memori
- permintaan input pengguna, penambahan memori riwayat, kondisi, dan struktur kontrol lainnya
Riset yang Ada dan Kebutuhannya
- Protokol structured tool calling OpenAI: menyediakan integrasi tool yang jelas melalui Function Calling API berbasis JSON dan spesifikasi OpenAPI
- MCP (2024) dari Anthropic: protokol terbuka yang menghubungkan asisten AI dengan data eksternal
- Diibaratkan sebagai “port USB-C untuk aplikasi AI”, dan menyediakan antarmuka universal
- Sudah memiliki contoh adopsi cepat, termasuk oleh perusahaan besar
- Security orchestrator – FIDES & AC4A (2025):
- FIDES (Microsoft Research): menegakkan kebijakan aliran informasi, melacak label kerahasiaan data, dan menambahkan aksi “inspect”
- AC4A: mengelola tool dan data dalam struktur hierarkis ala OS, serta memaksakan mode operasi hak istimewa minimum
- Proyek-proyek ini menunjukkan kemungkinan MVM membangun keamanan dan kontrol akses secara bawaan
- Runtime agen open source: langchain, Semantic Kernel, llguidance menyediakan layanan runtime untuk mendukung pengembangan aplikasi AI yang stabil
- Spesifikasi MVM mengharuskan data pelatihan model mencerminkan spesifikasi antarmuka, sehingga diperlukan koevolusi antara model dan MVM
Manfaat MVM
- Pemisahan concern: memisahkan logika model dan logika integrasi sehingga model berubah menjadi komponen yang dapat dipertukarkan
- Interoperabilitas tetap terjaga saat mengganti ke model baru atau berpindah platform
- Keamanan dan tata kelola bawaan: MVM menjamin keamanan melalui pemeriksaan izin, audit log, dan pengaman
- Seperti AC4A, MVM dapat berperan sebagai gatekeeper untuk menekan perilaku tak terduga
- Pelacakan kinerja yang transparan: melalui diagnosis runtime, MVM menyediakan tingkat kinerja model, konsumsi sumber daya, dan akses data
- Melalui benchmark, akurasi, kegunaan, dan responsivitas dapat dibandingkan
- Verifikasi output model: teknologi seperti zero-knowledge proof dapat digunakan untuk memeriksa integritas output, memperkuat kepercayaan dan akuntabilitas
Kesimpulan
- Mesin virtual model AI diperlukan untuk mengurangi kompleksitas sistem AI dan meningkatkan interoperabilitas
- Ia memperkuat keamanan, privasi, portabilitas, dan keandalan, sekaligus meningkatkan kecepatan pengembangan dan skalabilitas ekosistem
- Berdasarkan riset dari perusahaan teknologi, startup, dan akademia, spesifikasi MVM dapat menyediakan standar agar model AI dapat berinteraksi dengan aman dan mulus
- Tujuannya adalah membangun konsensus bersama komunitas tentang perlunya spesifikasi MVM dan elemen-elemen yang harus disertakan
1 komentar
Komentar Hacker News
Menurut saya tulisan ini kurang penjelasan konkret, jadi tidak jelas apa sebenarnya yang diusulkan. VM (Virtual Machine) bagaimanapun berkaitan dengan instruction set, control flow, register, dan semacamnya, tetapi tulisan ini hanya fokus pada authorization. Pada akhirnya, ini tampak seperti membicarakan 'sesuatu yang mirip sandbox, jail, atau container yang memungkinkan model berinteraksi dengan dunia luar'
Saya bertanya-tanya apakah yang dimaksud benar-benar mesin eksekusi VM, atau Docker untuk LLM. Secara keseluruhan terasa seperti sekadar kemasan. Kalau desain sistem packaging buruk, itu bisa jadi bencana. Pengalaman packaging Python yang beragam saja sudah cukup menunjukkan hal itu
Saat melihat kata VM, saya langsung merasa itu cukup dekat dengan sandbox. Karena tulisan itu juga menyebut 'isolasi', saya tidak merasa istilahnya ambigu atau informasinya kurang. Hanya saja, argumen penulis terlalu jelas dan solusinya juga belum lengkap. Bahkan kalau dimasukkan ke sandbox level OS atau hardware, tetap bermasalah jika agen menemukan AWS CLI dengan konfigurasi IAM yang salah. Batas jarak jauh juga rumit. Saya tidak menemukan insight baru. Menurut saya masalahnya bukan pada pemilihan istilah
Kalau mengikuti definisi di tulisan itu, AI agent saat ini pun sebenarnya sudah bisa dianggap berjalan di dalam VM. Misalnya, di MCP host bisa diminta persetujuan pengguna untuk eksekusi, atau seperti Claude code bisa dibuat aturan yang otomatis menyetujui perintah dengan pola tertentu
Menurut saya, masalah intinya bukan alat apa yang akan diberikan ke LLM, melainkan tindakan apa yang boleh dilakukannya. Misalnya dalam skenario pemesanan tiket pesawat, kita ingin LLM membandingkan harga di berbagai situs lalu menyelesaikan pembayaran. Tapi kita tidak ingin ia malah memilih tiket 37 jam transit hanya karena 3 dolar lebih murah. Untuk melihat informasi tunjangan juga, ia seharusnya hanya bisa melihat milik sendiri, bukan milik rekan kerja. Bahkan dengan alat yang sama pun cakupan izinnya berbeda. Staf HR tentu bisa melihat data karyawan yang mereka kelola, tetapi di situ muncul isu tambahan seperti audit trail. Jadi, yang lebih penting daripada tindakan adalah intent. Idealnya, LLM diperlakukan sebagai perwakilan pengguna dan ditempatkan dalam kotak izin yang sama
Pada akhirnya ini adalah capability security model. Capability yang dapat diakses agen perangkat lunak harus diberikan secara eksplisit, dan tindakan di luar daftar itu harus dibuat tidak mungkin secara fisik. Tetapi tidak ada OS mainstream yang benar-benar menerapkan model ini. Ada banyak riset dan percobaan (contoh OS: EROS, Fuchsia, Sandstorm), tetapi tidak terlalu sukses di pasar. Karena itu, pendekatan yang paling mendekati di dunia nyata adalah memakai VM lalu hanya menaruh alat yang dibutuhkan di dalam VM. Ini tidak sempurna, karena alat itu sendiri terlalu umum dibanding capability yang sesungguhnya. Perangkat lunak yang dibangun dengan prinsip least privilege memang sering gagal di pasar
Yang penting bukan alat itu bisa melakukan tindakan apa, tetapi kombinasi data dan tindakan yang bisa diakses alat tersebut. Karena perilaku LLM tidak bisa diprediksi sempurna, kita tidak boleh mempercayainya. Misalnya, LLM boleh diizinkan mengakses situs pemesanan tiket pesawat, tetapi jangan diberi SSN, informasi rekening bank, dan semacamnya. Ini masalah provenance data dan izin. Semakin sensitif task yang memegang data, semakin banyak pembatasan yang dibutuhkan; sebaliknya, kalau kurang sensitif, lebih banyak tindakan bisa diizinkan. Data harus membawa informasi izin, dan mediator harus membatasi data maupun tindakan apa yang dapat dimiliki task baru yang di-spawn. Contoh: jika task perencanaan perjalanan me-spawn subtask pencarian tiket pesawat, mediator hanya meneruskan data non-sensitif seperti sebagian jadwal ke subtask itu, dan memblokir akses ke data sensitif
LLM agent bisa dipandang sebagai user lain yang setara dengan pengguna. Ia memiliki izin berbeda di tiap context. Misalnya, untuk satu folder source code ia punya izin baca/tulis, sedangkan untuk folder lain hanya baca. Untuk tiap proyek, izin LLM agent berbeda-beda, dan merupakan irisan atau subset dari izin pengguna. Pada dasarnya ada tiga jenis izin: Allow, Deny, dan Ask (minta izin), dan bila perlu ia menanyakan ke pengguna apakah boleh dilakukan. Masalahnya, izin OS saat ini serta izin aplikasi/data belum cukup rinci. Bahkan git pun seharusnya dirancang agar hanya mengizinkan perintah tertentu, bukan akses penuh. Sekarang aplikasi meniru pola ini sendiri-sendiri di userspace dengan cara yang canggung. Workflow-nya mirip sudo. Jika saya meluncurkan aplikasi dengan user LLM Agent saya, maka izin diberikan atau dibatasi sesuai context tersebut. Ia hanya boleh bertindak dalam batas izin saya saat saya memintanya. Tetapi saat ini setiap aplikasi agentic harus mengimplementasikan proses ini sendiri, jadi seharusnya ini dijadikan layanan OS yang sistematis. Sebagai solusi sementara, bisa diakali dengan membuat dan menghapus akun pengguna sementara untuk tiap context agent, lalu berkomunikasi hanya lewat IPC atau jaringan
Saya ragu model seperti ini benar-benar akan bekerja. Sekalipun LLM bisa melakukan sesuatu, situs web dapat mendeteksinya lalu menyesuaikan harga atau merusak decision tree. Kalau begitu, akan jauh lebih baik bila semua situs menyediakan API untuk LLM, atau memakai 'rss + json'. Seperti BBS atau sistem menu SMS, cukup memberikan data sederhana dan pilihan, dan itu juga optimal untuk LLM. Hal yang sama berlaku untuk iklan. Tidak ada gunanya menampilkan iklan ke LLM, malah iklan yang mencoba menipu LLM bisa jadi lebih efektif. Misalnya saat pencarian penerbangan, iklan dapat memancing LLM dan menipunya bahwa produk saya yang terbaik. Karena AI saat ini masih cukup sederhana, akan lucu kalau nanti muncul iklan khusus AI
Jika definisi dan penegakan atas “respons yang baik” memungkinkan, mungkin LLM itu sendiri tidak diperlukan. Dalam kasus staf HR, intent bisa ditanyakan secara langsung, tetapi bagi LLM ini sulit karena ia tidak punya intent
Dulu saya melihat postingan HN tentang John Carmack yang dianggap hanya membuang waktu dan uang saat membuat XROS di Meta. Tulisan yang saya baca hari ini justru sebaliknya, sangat menekankan perlunya OS baru. VM memang bukan OS lengkap, tetapi berbeda karena bisa dibuat ringan sambil tetap memanfaatkan OS dan codebase yang ada
Kedua tulisan itu sama sekali membicarakan hal yang berbeda. Bahkan saya juga tidak merasa tulisan ini benar-benar menekankan perlunya VM atau OS baru. Pada akhirnya ini hanya soal access control
Di XR, yang utama adalah performance dan developer experience, sedangkan di dunia LLM inti persoalannya memang bagaimana men-sandbox dan menyederhanakan akses tool/data. Ada banyak hal yang harus dilakukan agar LLM tidak merusak lingkungan eksekusi atau mengacaukan data, dan kalau ada standar, beban retraining bisa berkurang serta pemanfaatan model orang lain jadi lebih mudah. Di XR, kalau hanya sebatas SDK masih bisa diatasi lewat training, tetapi di AI biaya R&D dan compute jauh lebih besar
WebAssembly pada dasarnya sudah menyediakan sandbox, jadi menurut saya kita sudah setengah jalan. Yang tersisa adalah antarmuka yang jelas untuk memindahkan data/izin antar-instance, dan cara agar instance dapat saling membuat instance lain
Saya tidak merasa tulisan ini menjadi dasar untuk menulis OS baru. Membangun lingkungan eksekusi untuk AI dan merancang OS yang dioptimalkan untuk AI dari nol adalah dua hal yang sepenuhnya berbeda
Setelah membaca tulisan itu dengan cermat dan melihat tautan referensinya, saya merasa tulisan ini menyoroti masalah yang lebih mendasar daripada sekadar "VM untuk AI". VM saja tidak cukup untuk menjamin keamanan workflow LLM. Workflow tingkat atas perlu mengakses task dan data sensitif seperti jaringan, PII, credentials, dan LLM rentan terhadap prompt injection serta masalah konsistensi. Sekadar menaruh LLM di dalam VM tidak menyelesaikan ini. Diperlukan 'manajemen aliran informasi' yang mempartisi workflow, data, dan komputasi per unit kerja, sehingga hanya subtask minimum yang diberi akses ke informasi terbatas. Hanya subset yang menangani task sensitif yang harus dipercaya dan diverifikasi secara terpisah. Yang inti di sini adalah “Secure Orchestrators” yang disebut di tulisan itu, serta paper FIDES. Pada akhirnya, “VM” berarti menjalankan task di dalam container yang hanya diberi izin/data terbatas. Orchestrator harus membuat container ini, memberikan izin yang tepat, dan menempelkan label sensitivitas (taint-tracking) pada data hasilnya. Secara keseluruhan, menurut saya istilah seperti “partitioning” atau “isolation”, serta penekanan pada isu data, lebih tepat daripada ungkapan “VM for AI”
Terdengar mirip dengan Microsoft Wassette
Tujuan akhirnya seharusnya menghapus konsep workflow itu sendiri. Dalam kombinasi LLM+VM, memberikan tool ke LLM itu sendiri sudah merupakan workflow. Pendekatan ini memang sering bekerja cukup baik sekarang, tetapi punya keterbatasan untuk pekerjaan yang memerlukan tool atau penanganan pengecualian yang belum didefinisikan sebelumnya. Selain itu, pendekatan berbasis workflow pada akhirnya sulit lepas dari batas linearitasnya sendiri, meski memakai DAG atau loop. Langkah berikutnya adalah tidak lagi memberikan tool sama sekali, melainkan membiarkan LLM membuat tool yang dibutuhkannya secara on-the-fly saat perlu. Beberapa masalah memang membutuhkan pendekatan brute-force
Saat membaca tulisan ini, saya sampai merasa tulisan-tulisan belakangan seolah ditulis oleh AI. Dari sudut pandang hosting, sekadar menjalankan AI agent secara stabil di lingkungan apa pun saja sudah tantangan besar. Sebagai developer, saya memakai rootless docker devcontainer di wsl, dan meskipun beberapa malware mungkin bisa menembusnya, saya merasa pendekatan ini lebih aman daripada pendekatan VM. Selain itu ada keuntungan seperti reproduktibilitas dan isolasi lingkungan, dan jika AI merusak environment saya, saya tinggal membuat ulang container-nya, jadi beban mentalnya lebih kecil
Jika melihat metode deployment model yang paling maju secara komersial, hampir semua fitur yang disebut tulisan ini seperti isolasi pada dasarnya sudah diterapkan. Memang belum pada level OS penuh, tetapi fungsinya mirip. Namun bahkan itu pun belum cukup. Agar agen benar-benar berguna, ia harus punya akses ke resource penting, dan memberi izin persis secukupnya jauh lebih sulit daripada sekadar mengisolasi LLM itu sendiri. Model yang tepat untuk keamanan LLM adalah 'untrusted userspace'. Tidak perlu mendesain ulang seluruh OS
Saya setuju bahwa isolasi LLM harus dilakukan seteliti level desain VM. Alasannya sama seperti mengapa di OS tradisional perilaku semacam ini diterapkan dengan ketat. Baru-baru ini saya merangkum ide-ide ini di blog ini. Pendekatannya membandingkan cara kerja LLM dengan proses/task pada OS tradisional, dan abstraksi utamanya tidak sulit diimplementasikan — interface chat/tool dari 8 backend LLM bisa disatukan sehingga persetujuan tool dapat dikelola secara terpusat. Model capabilities memang belum saya implementasikan, tetapi dari pengalaman saya dulu dengan OS (VSTa), itu terasa sebagai pendekatan yang alami. Satu LLM juga harus bisa mendelegasikan subset izin yang dimilikinya ke LLM lain, dan saya sudah membuat alat delegasinya
Menurut saya, membuat mesin abstrak baru seperti VM justru hanya menambah kompleksitas. Yang dibutuhkan sudah cukup tercakup oleh akun, izin baca/tulis/eksekusi file, serta akses sementara atau jarak jauh lewat access token. Semua capability model menurut saya bisa diimplementasikan memadai dengan konsep-konsep ini. Saya lebih memilih menyederhanakan alat yang sudah ada. Karena semua orang saat ini sedang bereksperimen dengan hal-hal baru sambil berharap ada perubahan mendasar pada perangkat lunak secara keseluruhan, menurut saya justru ini harus menjadi masa untuk mengurangi kompleksitas yang tidak perlu dan membuat semuanya lebih sederhana. Misalnya, mengubah server MCP menjadi tool CLI sederhana dengan Claude hanya butuh 10 menit. Menurut saya itu sudah cukup berguna
Model keamanan desktop OS modern sangat tidak memadai untuk zaman sekarang. Menyerahkan semua izin tanpa peringatan atau konfirmasi yang berarti kepada pengguna itu nyaris gila. Jika pengguna benar-benar menginginkan lingkungan tanpa batasan, mereka seharusnya diberi pilihan, tetapi default-nya harus least privilege. Izin per program juga harus dibatasi per domain. Misalnya, alat untuk memvisualisasikan penggunaan disk mungkin perlu akses penuh ke filesystem, tetapi tidak perlu akses ke jaringan lokal atau internet
Kekuatan terbesar VM adalah membatasi radius kerusakan. Agen yang bagus bisa memanfaatkan zero day di dalam sistem dan menembusnya dengan mudah. Bahkan hanya dengan izin user pun sudah cukup berbahaya, dan sangat sulit membatasi pengetahuan agen dengan firewall karena ada banyak cara untuk mem-bypass-nya lewat internet. Sistem seperti ini akan menjadi sangat mahir dalam cracking sistem, jadi dibutuhkan perlindungan keamanan yang sangat kuat
Dalam lingkungan LLM, tidak ada yang namanya pembacaan sekali pakai ('temporary read'). Begitu data masuk ke context, kita harus menganggap data itu bisa bocor ke semua tempat yang terhubung sampai agen mati dan context dihapus. Ini berlaku baik dengan VM maupun tanpa VM, dan VM saja bukan solusi keamanan
Sebagian besar saya setuju. Banyak risiko keamanan tetap akan muncul baik ada VM maupun tidak. Ke depan defense in depth akan makin penting, tetapi saat ini terlalu banyak cara mudah bagi penyerang untuk memakai AI agent guna merugikan pengguna
Begitu tool pengeditan file diizinkan, pada dasarnya semua keamanan sudah hilang
Saya rasa Fuchsia bisa menjadi OS yang realistis untuk mengendalikan perilaku model AI. Karena ini object capability OS, tiap komponen (proses) hanya bisa mengakses capability yang diberikan secara eksplisit
Saat ChatGPT mengeksekusi kode (misalnya saat diminta memproses CSV), tampaknya ia berjalan di VM dengan akses hanya ke tool dan library tertentu, disk yang di-sandbox, serta tanpa koneksi internet. Jadi sebenarnya arahnya sudah mirip seperti ini
Devin dan OpenHands juga mirip. Dalam proyek pilot AI yang saya kerjakan beberapa bulan lalu pun, 'menjalankan agent di VM (default)' adalah elemen kunci
Bentuknya adalah Kubernetes berbasis AKS (Azure Kubernetes) dengan gvisor dan Jupyter di atasnya
Tidak juga. Misalnya, andaikan satu mesin menjalankan dua AI (seperti ChatGPT dan lainnya), tetap belum ada standar maupun interoperabilitas sama sekali terkait kolaborasi atau cara keduanya saling bekerja