- AI yazılımları, yalnızca model çağırmanın ötesinde güvenlik, izolasyon, ölçeklenebilirlik ve taşınabilirlik sağlayan işletim sistemi benzeri özelliklere ihtiyaç duyar; bunun için AI modellere özel sanal makine (MVM) kavramı öneriliyor
- Java Virtual Machine(JVM) bellek güvenliğini ve “bir kez yaz, her yerde çalıştır” yaklaşımını mümkün kıldığı gibi, AI VM de model ile entegrasyon mantığını ayırarak değiştirilebilirlik ve birlikte çalışabilirlik sağlar
- VM, model çağrısı, araç çağrısı, sonuç kaydetme, kullanıcı girdisi, koşullu dallanma gibi standart bir komut kümesi tanımlayarak model davranışını güvenli biçimde sınırlamayı ve izlemeyi mümkün kılar
- OpenAI’nin yapılandırılmış araç çağırma, Anthropic’in MCP’si, Microsoft’un FIDES/AC4A’sı, açık kaynak çalışma zamanları gibi mevcut araştırmalar zaten standartlaşma yönünü gösteriyor
- İyi tanımlanmış bir AI VM; güvenlik ve gizliliğin güçlendirilmesi, performans izleme, çıktı doğrulama ve platformlar arası ekosistem kurulumu sağlar ve AI sistemlerini daha güvenilir ve güvenli hale getiren temel bir altyapı olabilir
Giriş
- AI modelleri, uygulama copilotu, IDE entegrasyonu, MCP protokolü üzerinden araç kullanımı gibi çeşitli amaçlarla yazılım içinde kullanılıyor
- Bu gelişmeler, gizliliği, güvenliği ve doğru çalışmayı garanti etme ihtiyacını artırıyor
- Güvenlik ve gizlilik, sistem tasarımının en başından itibaren sağlanmalı; sonradan eklenmesi yeterli değil
- Java Virtual Machine(JVM)’den ilhamla, AI modelleri için standartlaştırılmış bir sanal makinenin önemi ortaya konuyor
- JVM, bellek güvenliği, erişim denetimi ve bytecode doğrulaması yoluyla güvenilir bir çalıştırma ortamı sunuyordu
- Bu sayede “bir kez yaz ve her yerde çalıştır” mümkün oldu
AI model sanal makinesinin (MVM) rolü
- MVM, AI modeli ile dış ortam arasında çalışan bir aracı yazılım görevi görür
- Örnek: Kullanıcı “uçuş rezervasyonu” istemini girerse, MVM bunu modele iletir (bağlam ekleme dahil)
- Model “rezervasyon aracını kullan” diye yanıt verirse, MVM izin verilen araçlar listesini kontrol edip aracın çağrılıp çağrılmayacağına karar verir
- Bu, modelin yetkisiz çağrılar yapmamasını garanti eder
- Tüm ticari AI sistemleri buna benzer bir kontrol yazılımına ihtiyaç duyar
- MVM, bir komut kümesi tanımlar; örneğin:
- model kimlik doğrulama, yükleme, başlatma, kaldırma
- bağlam içeren model çağrısı
- model çıktısını ayrıştırma
- araç kimlik doğrulama, yükleme, çağırma, sonuç ayrıştırma ve belleğe kaydetme
- kullanıcı girdisi isteme, geçmiş belleği ekleme, koşul ifadeleri gibi kontrol yapıları
Mevcut araştırmalar ve gereklilik
- OpenAI’nin yapılandırılmış araç çağırma protokolü: JSON tabanlı function calling API ve OpenAPI tanımları üzerinden net araç entegrasyonu sunuyor
- Anthropic’in MCP’si (2024): AI asistanlarını dış veriye bağlayan açık bir protokol
- “AI uygulamalarının USB-C portu” olarak benzetiliyor ve evrensel bir arayüz sunuyor
- Büyük şirketler dahil hızlı benimsenme örneklerine sahip
- Güvenlik orkestratörleri – FIDES ve AC4A (2025):
- FIDES (Microsoft Research): bilgi akışı politikalarını zorunlu kılıyor, veri gizlilik etiketlerini izliyor ve “inspection” eylemi ekliyor
- AC4A: Araçları ve verileri işletim sistemi tarzında hiyerarşik olarak yönetiyor, en düşük ayrıcalık çalışma modunu zorunlu kılıyor
- Bu projeler, MVM’in güvenlik ve erişim denetimini yerleşik olarak barındırabileceğini gösteriyor
- Açık kaynak ajan çalışma zamanları: langchain, Semantic Kernel, llguidance çalışma zamanı hizmetleri sunarak kararlı AI uygulamaları geliştirmeyi destekliyor
- MVM spesifikasyonu, model eğitim verisinin arayüz spesifikasyonunu yansıtmasını gerektirir; model ile MVM arasında ortak evrim gerekir
MVM’in faydaları
- Sorumlulukların ayrılması: model mantığı ile entegrasyon mantığını ayırarak modeli değiştirilebilir bir bileşene dönüştürür
- Yeni bir modelle değiştirme veya başka bir platforma taşıma durumunda birlikte çalışabilirlik korunur
- Yerleşik güvenlik ve yönetişim: MVM, izin kontrolü, denetim kayıtları ve güvenlik önlemleriyle güvenliği sağlar
- AC4A gibi, MVM de kapı bekçisi rolü oynayarak beklenmedik davranışları bastırır
- Şeffaf performans takibi: Çalışma zamanı tanılaması ile model performansı, kaynak tüketimi ve veri erişim seviyesi görünür hale gelir
- Benchmark ile doğruluk, kullanışlılık ve yanıt verebilirlik karşılaştırılabilir
- Model çıktısının doğrulanması: sıfır bilgi ispatı gibi tekniklerle çıktı bütünlüğü doğrulanabilir; bu da güveni ve hesap verebilirliği güçlendirir
Sonuç
- AI model sanal makinesi, AI sistemlerinin karmaşıklığını azaltmak ve birlikte çalışabilirliği artırmak için gereklidir
- Güvenliği, gizliliği, taşınabilirliği ve güvenilirliği güçlendirir; geliştirme hızını ve ekosistemin ölçeklenebilirliğini artırır
- Teknoloji şirketleri, startup’lar ve akademideki araştırmalara dayanarak MVM spesifikasyonu, AI modellerinin güvenli ve sorunsuz etkileşime girebileceği bir standart sağlayabilir
- Toplulukla iş birliği içinde, MVM spesifikasyonunun gerekliliği ve hangi unsurları içermesi gerektiği konusunda uzlaşı oluşturmak hedefleniyor
1 yorum
Hacker News görüşleri
Bu yazının somut açıklamalardan yoksun olduğunu, bu yüzden tam olarak ne önerdiğinin anlaşılamadığını düşünüyorum. VM (Virtual Machine) sonuçta komut kümesi, kontrol akışı, register’lar gibi şeylerle ilişkilidir ama bu yazı sadece yetkilendirmeye odaklanıyor. Sonuçta burada anlatılan şey, "modelin dış dünyayla etkileşime girmesini sağlayan sandbox, jail ya da container benzeri bir şey" gibi görünüyor
Gerçekten bir VM yürütme motorundan ya da LLM’ler için Docker benzeri bir şeyden mi söz ediliyor diye düşünüyorum. Genel olarak süslenip paketlenmiş bir anlatı gibi duruyor. Paketleme sistemi kötü tasarlanırsa felaket olabilir. Bunu Python’un çeşitli paketleme deneyimlerinden bile görmek mümkün
“VM” kelimesini görünce bunu hemen sandbox’a oldukça yakın hissettim. Yazıda da “izolasyon” dendiği için muğlak ya da yetersiz bilgi verildiğini düşünmedim. Ama yazarın iddiası fazla bariz ve çözüm de eksik. Onu OS ya da donanım seviyesinde bir sandbox’a koysanız bile, ajan yanlış yapılandırılmış IAM ayarlarına sahip bir AWS CLI bulursa yine sorun olur. Uzak sınırlar da karmaşık. Yeni bir içgörü göremedim. Sorunun terim seçimi olduğunu sanmıyorum
Yazıdaki tanıma göre bakarsak, bugünkü AI agent’ların zaten VM içinde çalıştığı bile söylenebilir. Örneğin bir MCP host, çalıştırma onayı için kullanıcıya sorabilir ya da Claude code gibi belli komut kalıplarını otomatik onaylayan kurallar koyabilir
Mesele LLM’e hangi araçların verileceği değil, hangi eylemleri yapmasına izin verileceği diye düşünüyorum. Örneğin uçak bileti rezervasyonu senaryosunda, LLM’in farklı sitelerde fiyat karşılaştırması yapıp ödemeye kadar ilerlemesini isterim. Ama gereksiz yere 3 dolar daha ucuz diye 37 saatlik bir uçuş seçmesini istemem. Yan haklar bilgisini sorgularken de yalnızca kendi bilgilerimi görebilmeli, iş arkadaşımınkileri görememeli. Aynı araç olsa bile yetki kapsamı farklıdır. İK sorumlusuysa yönettiği çalışanların bilgilerini tabii ki görebilir ama o durumda denetim kaydı gibi ek meseleler ortaya çıkar. Yani eylemden çok niyet (intent) önemlidir. LLM’i kullanıcının temsilcisi yapıp aynı yetki kutusunun içine koymak daha doğru olur
Sonuçta anlatılan şey capability security model. Yazılım ajanına erişebileceği capability’lerin açıkça verilmesi ve bu listenin dışındaki eylemleri fiziksel olarak yapamaması gerekir. Ama pratikte ana akım işletim sistemleri arasında bunu uygulayan yok. Bazı araştırmalar ve girişimler var (OS örnekleri: EROS, Fuchsia, Sandstorm) ama piyasada pek başarılı olamadılar. Bu yüzden pratikte en yakın yöntem, VM kullanıp sadece gerekli araçları o VM’in içine koymak. Bu kusursuz değil çünkü araçların kendisi gerçek capability’lere kıyasla fazla genel kalıyor. En az yetki ilkesiyle inşa edilmiş yazılımlar piyasada sık sık başarısız oluyor
Önemli olan aracın hangi eylemleri yapabildiği değil, aracın erişebildiği veri ile eylemlerin birleşimi. LLM’in davranışını tam olarak öngöremediğimiz için ona güvenmemek gerekir. Örneğin LLM’e sadece uçak bileti rezervasyon sitelerine erişim verilmeli ama SSN ya da banka hesap bilgileri verilmemeli. Burada verinin kaynağı (provenance) ve yetki meselesi var. Hassas veriler içeren görevler ne kadar çoksa o kadar fazla kısıtlama gerekir; daha az hassassa daha fazla eyleme izin verilebilir. Verinin yetki bilgisini taşıması gerekir ve mediator, yeni spawn edilen görevlerin hangi veri ve eylemlere sahip olacağını sınırlamalıdır. Örneğin seyahat planlama görevi, alt görev olarak uçuş araması spawn ederse, mediator alt göreve takvimin bir kısmı gibi hassas olmayan verileri vermeli, hassas veri erişimini ise engellemelidir
LLM agent, kullanıcıyla aynı seviyede başka bir kullanıcı gibi görülebilir. Bağlama (context) göre farklı yetkilere sahip olur. Örneğin bir kaynak kod klasöründe okuma/yazma yetkisi varken başka bir klasörde sadece okuma yetkisi olabilir. Her projede LLM agent’ın sahip olduğu yetkiler farklıdır ve bunlar kullanıcının yetkilerinin kesişimi ya da alt kümesidir. Temelde üç tür izin vardır: Allow, Deny ve Ask (izin iste). Gerekirse kullanıcıya izin verip vermeyeceği sorulur. Sorun, mevcut OS’lerin ve uygulama/veri izinlerinin yeterince ayrıntılı olmaması. Örneğin git, tüm erişim yerine yalnızca belirli komutlara izin verecek şekilde tasarlanmalı. Bugün uygulamalar bunu kullanıcı alanında taklit ediyor ve bunu da biraz tuhaf yollarla yapıyor. İş akışı sudo’ya benziyor. Uygulamayı benim LLM Agent kullanıcım olarak başlatırsam, o bağlama göre yetkiler veriliyor ya da kısıtlanıyor. Ben talep ettiğimde, yalnızca bana tanınmış izin aralığında hareket edebiliyor. Ama bugün her agentic uygulamanın bu süreci kendisinin uygulaması gerekiyor; bunun sistematik bir OS hizmeti olması gerekirdi. Geçici çözüm olarak, agent bağlamı başına geçici kullanıcı hesapları oluşturup silerek ve sadece IPC ya da ağ üzerinden iletişim kurarak dolaşmak mümkün
Böyle bir modelin gerçekten işe yarayıp yaramayacağından emin değilim. LLM bir şey yapabiliyor olsa bile, web siteleri bunu tespit edip fiyatları değiştirebilir ya da karar ağaçlarını bozabilir. O durumda tüm sitelerin doğrudan LLM API’si ya da “rss + json” kullanması çok daha iyi olur. BBS ya da SMS menü sistemleri gibi yalnızca basit veri ve seçenekler sunulursa, bu LLM’ler için de ideal olur. Reklam tarafı da aynı. LLM’e boş yere reklam göstermeye gerek yok; hatta LLM’i kandırmaya çalışan reklamlar daha etkili olabilir. Örneğin uçuş aramasında reklamlar LLM’i etkileyip kendi ürününün en iyisi olduğuna inandırabilir. AI hâlâ basit olduğu için, AI’ye özel reklamların çıkması ilginç olabilir
Eğer “iyi yanıt”ın ne olduğu tanımlanabiliyor ve uygulanabiliyorsa, belki de LLM’in kendisine hiç gerek yoktur. İK örneğinde niyet doğrudan sorulabilir ama LLM’in bir niyeti olmadığı için iş zorlaşıyor
Daha önce John Carmack’ın Meta’da XROS yaparken sadece zaman ve para harcadığını söyleyen bir HN yazısı görmüştüm. Bugün okuduğum bu yazı ise tersine, “yeni bir OS ihtiyacını” güçlü biçimde savunuyor gibi geldi. VM tam anlamıyla bir OS olmasa da, mevcut OS’leri ve kod tabanlarını kullanarak daha hafif yapılabilmesi bakımından farklı
İki yazı tamamen farklı şeylerden söz ediyor. Aslında bu yazının VM ya da yeni bir OS gereksinimini güçlü biçimde savunduğunu da düşünmüyorum. Sonunda bütün mesele erişim kontrolüne çıkıyor
XR tarafında performans ve geliştirici deneyimi merkezdeyken, LLM tarafında araç ve veri erişimini nasıl sandbox içine alıp sadeleştireceğimiz asıl mesele. LLM’in çalışma ortamını bozmasını ya da veriyi tahrip etmesini önlemek için yapılacak çok şey var ve bir standart olursa yeniden eğitim yükü azalır, başkalarının modelleri kullanması da kolaylaşır. XR tarafında iş bir SDK düzeyindeyse eğitimle çözülebilir ama AI tarafında Ar-Ge ve compute maliyetleri çok daha yüksek
WebAssembly zaten doğası gereği sandbox sağlıyor, dolayısıyla yolun yarısı alınmış sayılır. Geriye instance’lar arasında veri ve yetki aktarımı için net arayüzler ve instance’ların birbirini nasıl oluşturacağı kalıyor
Bunun yeni bir OS yazmak için yeterli gerekçe olduğunu düşünmüyorum. AI için bir çalışma ortamı kurmakla, AI’ye optimize edilmiş bir OS’yi sıfırdan tasarlamak tamamen farklı şeyler
Yazıyı dikkatlice okuyup referans linklerine baktıktan sonra, bunun sadece “AI için VM” meselesinden daha temel bir soruna işaret ettiğini düşündüm. Sadece VM, LLM iş akışının güvenliğini sağlamak için yeterli değil. En üst düzey iş akışı ağ, PII, credentials gibi hassas görev ve verilere erişmek zorunda kalıyor ve LLM’ler prompt injection ile tutarlılık sorunlarına açık. LLM’i sadece bir VM içine koymak bunu çözmüyor. Görev bazında iş akışını, veriyi ve hesaplamayı bölümlere ayırıp yalnızca en az yetkili alt görevlerin sınırlı bilgiye erişmesini sağlayan bir “bilgi akışı yönetimi” gerekiyor. Hassas işleri yapan alt kümenin ayrıca güvenilmesi ve doğrulanması gerekiyor. Yazının söz ettiği “Secure Orchestrators” ve FIDES makalesi bence burada kilit nokta. “VM” sonuçta sınırlı yetki ve veri verilmiş bir container içinde görevi çalıştırmak demek. Orchestrator bu container’ı oluşturmalı, uygun yetkileri vermeli ve çıktı verilerine de hassasiyet (taint-tracking) etiketleri eklemeli. Genel olarak “VM for AI” ifadesinden ziyade “partitioning” ya da “isolation” ve veri meselelerini vurgulamak daha doğru olur gibi geliyor
Microsoft Wassette benzeri geliyor
Asıl hedef, “iş akışı” kavramını tamamen ortadan kaldırmak olmalı. LLM+VM birleşiminde, LLM’e araç vermek zaten başlı başına bir iş akışı demek. Bu yaklaşım çoğu zaman işe yarıyor ama önceden tanımlanmamış istisnalar ya da yeni araç gerektiren görevlerde sınırlı kalıyor. Ayrıca iş akışı temelli yapıların doğrusal kalıptan (ya da DAG ve loop’lar içeren türevlerinden) çıkması zor. Bir sonraki adım, araçları önceden vermek yerine LLM’in ihtiyaç duyduğunda aracı anlık olarak kendisinin üretmesi olabilir. Bazı problemler brute-force tarzı yaklaşım gerektirir
Bunu okurken son dönemdeki bazı yazıların AI tarafından yazılmış gibi hissettirdiğini düşündüm. Hosting tarafında bakınca, hangi ortam olursa olsun AI agent’ı stabil şekilde ayağa kaldırmak bile büyük mesele. Geliştirici olarak rootless docker devcontainer’lı WSL kullanıyorum; bazı kötü amaçlı yazılımlar bunu aşabilir belki ama yine de VM yaklaşımından daha güvenli hissettiriyor. Ayrıca yeniden üretilebilirlik ve ortam izolasyonu gibi avantajları var; AI benim ortamımı bozarsa container’ı yeniden ayağa kaldırırım, o kadar, bu da işi daha az stresli yapıyor
Ticari olarak en gelişmiş model dağıtım yöntemlerine bakarsanız, izolasyon dahil bu yazıda sözü geçen özelliklerin neredeyse hepsinin zaten uygulandığını görürsünüz. OS seviyesinde olmasa da işlevler benzer. Ama bu bile yeterli değil. Ajanın gerçekten iş yapabilmesi için önemli kaynaklara erişimi olmalı ve bu erişimi tam gerektiği kadar dar vermek, LLM’i izole etmekten çok daha zor. LLM güvenliği için doğru model “untrusted userspace”tir. Tüm bir OS tasarlamaya gerek yok
LLM izolasyonunun VM tasarımı seviyesinde titizlikle yapılması gerektiği görüşüne katılıyorum. Bu, geleneksel OS’lerde bu tür davranışların neden sıkı şekilde uygulandığıyla aynı sebebe dayanıyor. Yakın zamanda şu blog yazısında bazı fikirleri toparlamıştım. LLM davranış biçimini geleneksel OS process/task yapısıyla karşılaştırarak ele aldım ve temel soyutlamaları uygulamak zor değil — 8 farklı LLM backend’inin chat/tool arayüzünü birleştirip araç onayını merkezi olarak yönetmek mümkün. Henüz capability model’i uygulamadım ama geçmişte OS (VSTa) deneyimim olduğu için bana doğal geliyor. Bir LLM’in sahip olduğu yetkilerin bir alt kümesini başka bir LLM’e devredebilmesi gerekir ve bunun için delegation aracını da yaptım
VM gibi yeni bir soyut makine yaratmanın işleri daha da karmaşıklaştırdığını düşünüyorum. Zaten hesaplar, dosya okuma/yazma/çalıştırma izinleri ve geçici ya da uzak erişim için access token’lar yeterince kapsayıcı. Bütün capability model’lerin bu kavramlarla uygulanabileceğini düşünüyorum. Ben mevcut araçları sadeleştirmenin daha doğru yaklaşım olduğunu düşünüyorum. Herkes bugün yeni şeyler deniyor ama bunu yazılımı kökten değiştirme beklentisiyle değil, gereksiz karmaşıklığı azaltıp sistemi sadeleştirme dönemi olarak görmek lazım. Örneğin bir MCP sunucusunu Claude ile basit bir CLI aracına dönüştürmek 10 dakika sürüyor. Bu bence gayet kullanılabilir bir seviye
Modern masaüstü OS’lerin güvenlik modeli bu çağ için inanılmaz derecede yetersiz. Kullanıcıya doğru düzgün uyarı ya da onay bile göstermeden bütün yetkileri vermek delilik gibi. Kullanıcı gerçekten sınırsız bir ortam istiyorsa buna seçenek olarak izin verilebilir ama varsayılan en az yetki olmalı. Programlara alan bazında yetki verilmeli. Örneğin disk kullanımını görselleştiren bir aracın dosya sistemine tam erişmesi gerekebilir ama yerel ağa ya da internete erişmesi gerekmez
VM’in en büyük gücü, hasarın kapsamını sınırlaması. İyi bir agent, sistemdeki bir zero day’den yararlanarak kolayca sistemi kırabilir. Sadece kullanıcı yetkileri bile yeterince tehlikeli; üstelik agent’ın bilgisini bir güvenlik duvarıyla sınırlamak çok zor ve internette her zaman dolanma yolları var. Bu tür sistemleri kırma konusunda çok yetenekli hale gelecekleri için çok sağlam güvenlik önlemleri şart
LLM ortamında tek seferlik okuma (“temporary read”) diye bir şey yok. Veri bir kez context’e girdi mi, agent ölünceye ve context silininceye kadar bağlı olduğu her yere sızabilir diye varsaymak gerekir. Bu VM olsa da olmasa da geçerli; VM tek başına bir güvenlik çözümü değil
Büyük ölçüde katılıyorum. Birçok güvenlik riski VM olsun olmasın ortaya çıkıyor. Bundan sonra defense in depth daha da önemli olacak ama şu an saldırganların AI agent’ları kullanarak insanlara zarar vermesi için fazla kolay yol var
Dosya düzenleme aracına izin verdiğiniz anda, pratikte bütün güvenliği kaybetmiş oluyorsunuz
Fuchsia’nın AI model davranışını kontrol etmek için gerçekçi bir OS olabileceğini düşünüyorum. Çünkü object capability OS; her bileşen (process), sadece kendisine açıkça verilmiş capability’lere erişebiliyor
ChatGPT kod çalıştırdığında (örneğin CSV işleme isteğinde), yalnızca belirli araç ve kütüphanelere erişebilen bir VM, sandbox edilmiş disk ve internete kapalı bir ortamda çalışıyor gibi görünüyor. Yani aslında şimdiden buna benzer bir yapıya gidiliyor
Devin ve OpenHands de benzer. Birkaç ay önce yürüttüğüm bir AI pilot projesinde de temel unsur “agent’ı VM içinde çalıştırmak (varsayılan)” olmuştu
AKS (Azure Kubernetes) üzerinde çalışan Kubernetes’e gvisor ve Jupyter eklenmiş bir yapı
O kadar da değil. Örneğin aynı makinede iki AI’yı (ChatGPT vb.) çalıştırdığınızı varsayın; iş birliği ya da birlikte çalışabilirlik konusunda hiçbir standart yok.