- AI software को सिर्फ़ model call से आगे बढ़कर security·isolation·scalability·portability जैसी operating-system स्तर की विशेषताएँ चाहिए, और इसके लिए AI model-specific virtual machine (MVM) की अवधारणा प्रस्तावित की गई है
- जैसे Java Virtual Machine(JVM) ने memory safety और “एक बार लिखो, हर जगह चलाओ” संभव बनाया, वैसे ही AI VM model और integration logic को अलग करके replaceability और interoperability सुनिश्चित करता है
- VM, model call, tool call, result storage, user input, conditional branching जैसे standard instruction set को परिभाषित करता है, ताकि model behavior को सुरक्षित रूप से सीमित और trace किया जा सके
- OpenAI का structured tool calling, Anthropic का MCP, Microsoft का FIDES/AC4A, और open source runtimes जैसे मौजूदा शोध पहले ही standardization की दिशा दिखा रहे हैं
- एक अच्छी तरह परिभाषित AI VM security·privacy मज़बूती, performance monitoring, output verification, cross-platform ecosystem निर्माण को संभव बनाता है, और AI systems को अधिक भरोसेमंद और सुरक्षित बनाने वाली मुख्य infrastructure बन सकता है
परिचय
- AI models का उपयोग software में application copilots, IDE integration, MCP protocol के माध्यम से tool use जैसे कई कामों में हो रहा है
- ये प्रगति privacy, security और सही कामकाज सुनिश्चित करने की ज़रूरत को और बढ़ाती है
- Security और privacy को system design के शुरुआती चरण से ही सुनिश्चित किया जाना चाहिए; बाद में जोड़ना पर्याप्त नहीं है
- Java Virtual Machine(JVM) से प्रेरित होकर, AI models के लिए standardized virtual machine के महत्व का प्रस्ताव रखा गया है
- JVM memory safety, access control, और bytecode verification के माध्यम से भरोसेमंद execution environment देता है
- इसी से “एक बार लिखो और हर जगह चलाओ” संभव हुआ
AI model virtual machine(MVM) की भूमिका
- MVM AI model और बाहरी environment के बीच मध्यस्थ software की तरह काम करता है
- उदाहरण: जब user “flight booking” prompt दर्ज करता है, तो MVM उसे model तक पहुँचाता है, जिसमें context जोड़ना भी शामिल है
- अगर model “booking tool use” का जवाब देता है, तो MVM allowed tools list की जाँच करने के बाद तय करता है कि tool call की जाए या नहीं
- इससे यह सुनिश्चित होता है कि model unauthorized calls न करे
- सभी commercial AI systems को इसी तरह के control software की ज़रूरत होती है
- MVM instruction set को परिभाषित करता है, उदाहरण के लिए:
- model authentication, load, initialization, unload
- context सहित model call
- model output parsing
- tool authentication, load, call, result parsing और memory storage
- user input request, history memory जोड़ना, conditional statements जैसे control structures
मौजूदा शोध और आवश्यकता
- OpenAI का structured tool calling protocol: JSON-आधारित function calling API और OpenAPI specification के ज़रिए स्पष्ट tool integration प्रदान करता है
- Anthropic का MCP(2024): AI assistants और external data को जोड़ने वाला open protocol
- इसे “AI applications का USB-C port” कहा जाता है, जो universal interface देता है
- बड़ी कंपनियों सहित तेज़ adoption के उदाहरण मौजूद हैं
- Security orchestrator – FIDES & AC4A(2025):
- FIDES(Microsoft Research): information flow policies को enforce करता है, data confidentiality labels को track करता है और “inspect” action जोड़ता है
- AC4A: OS-style में tools और data को hierarchical structure में manage करता है, और least privilege operating mode को enforce करता है
- ये projects दिखाते हैं कि MVM में security और access control अंतर्निहित हो सकते हैं
- Open source agent runtimes: langchain, Semantic Kernel, llguidance runtime services देते हैं, जिससे स्थिर AI applications का development आसान होता है
- MVM specification के लिए ज़रूरी है कि model training data interface specification को प्रतिबिंबित करे, और model तथा MVM के बीच co-evolution हो
MVM के लाभ
- Separation of concerns: model logic और integration logic को अलग करके model को replaceable component में बदला जा सकता है
- नया model लगाने या platform बदलने पर भी interoperability बनी रहती है
- Built-in safety और governance: MVM permission checks, audit logs, और safety guards के माध्यम से सुरक्षा सुनिश्चित करता है
- AC4A की तरह MVM gatekeeper की भूमिका निभाकर unexpected behavior को दबा सकता है
- पारदर्शी performance tracking: runtime diagnostics के माध्यम से model performance, resource consumption, और data access level की जानकारी मिलती है
- benchmarks के ज़रिए accuracy, usefulness, और responsiveness की तुलना की जा सकती है
- Model output verification: zero-knowledge proofs जैसी तकनीकों से output integrity की पुष्टि की जा सकती है, जिससे trust और accountability बढ़ते हैं
निष्कर्ष
- AI model virtual machine AI systems की जटिलता घटाने और interoperability बढ़ाने के लिए आवश्यक है
- यह security, privacy, portability, और reliability को मज़बूत करता है, साथ ही development speed और ecosystem scalability बढ़ाता है
- tech companies, startups और academia के शोध के आधार पर MVM specification ऐसा standard दे सकता है जिससे AI models सुरक्षित और सहज रूप से interact कर सकें
- community के सहयोग से MVM specification की आवश्यकता और उसमें शामिल किए जाने वाले तत्वों पर consensus बनाना लक्ष्य है
1 टिप्पणियां
Hacker News की राय
मुझे लगता है कि इस लेख में ठोस व्याख्या की कमी है, इसलिए यह ठीक-ठीक क्या प्रस्तावित कर रहा है, यह समझना मुश्किल है। VM (Virtual Machine) तो किसी न किसी रूप में instruction set, control flow, register आदि से जुड़ा होता है, लेकिन यह लेख सिर्फ authorization पर केंद्रित है। अंततः यह शायद 'ऐसा कुछ जो sandbox, jail, container जैसा हो और मॉडल को बाहरी दुनिया के साथ इंटरैक्ट करने दे' की बात कर रहा है
यह सवाल भी है कि क्या यह सचमुच VM execution engine, या LLM के लिए Docker जैसी किसी चीज़ की बात कर रहा है। कुल मिलाकर यह मुझे सिर्फ पैकेजिंग की गई बात लगती है। अगर packaging system का design कमजोर हो, तो वह आपदा बन सकता है। Python की packaging का अनुभव ही काफी है यह समझने के लिए
मैंने VM शब्द देखते ही उसे sandbox के काफी करीब समझा। लेख में भी 'isolation' कहा गया है, इसलिए मुझे यह न तो अस्पष्ट लगा, न ही जानकारी की कमी वाली बात। लेकिन लेखक का दावा बहुत obvious है, और समाधान भी अधूरा है। OS या hardware-level sandbox में रखने पर भी, अगर agent को गलत IAM settings वाला AWS CLI मिल जाए तो समस्या होगी। remote boundary भी जटिल है। मुझे इसमें कोई नई insight नहीं मिली। मुझे नहीं लगता कि समस्या terminology की है
लेख की परिभाषा के हिसाब से देखें तो मौजूदा AI agent भी पहले से VM में चल रहे हैं, ऐसा कहा जा सकता है। उदाहरण के लिए MCP host उपयोगकर्ता से execution approval मांग सकता है, या Claude code की तरह कुछ command pattern को auto-approve करने वाले rules रखे जा सकते हैं
मुझे लगता है कि असली सवाल यह नहीं है कि LLM को कौन-से tools दिए जाएँ, बल्कि यह है कि उसे कौन-से actions करने दिए जाएँ। उदाहरण के लिए flight booking के scenario में, हम चाहते हैं कि LLM कई वेबसाइटों पर price compare करे और payment तक कर दे। लेकिन वह बेकार में सिर्फ 3 डॉलर सस्ती 37 घंटे वाली flight न चुन ले। benefits information भी सिर्फ अपनी देख सके, सहकर्मी की नहीं। वही tool हो सकता है, लेकिन permission का scope अलग होगा। HR प्रबंधक जिन कर्मचारियों को manage करता है, उनकी जानकारी देख सकता है, लेकिन उस स्थिति में audit log जैसी अतिरिक्त समस्याएँ आती हैं। यानी action से भी ज्यादा intent महत्वपूर्ण है। LLM को उपयोगकर्ता के प्रतिनिधि की तरह रखना और उसी permission box के भीतर सीमित करना बेहतर है
आखिरकार बात capability security model की ही हो रही है। software agent को जिन capabilities तक access मिलनी चाहिए, उन्हें explicitly देना होगा, और इस सूची के बाहर के actions शारीरिक रूप से असंभव होने चाहिए। लेकिन वास्तव में mainstream OS में इस model को लागू नहीं किया गया है। कुछ research (OS EXAMPLES: EROS, Fuchsia, Sandstorm) और कई प्रयास हुए, लेकिन वे बाज़ार में खास सफल नहीं हुए। इसलिए व्यवहार में सबसे निकट का तरीका VM का उपयोग करना है, और सिर्फ ज़रूरी tools को VM के भीतर रखना है। यह परफेक्ट नहीं है, क्योंकि tool खुद असली capability की तुलना में बहुत सामान्य होते हैं। least privilege principle पर बने software अक्सर बाज़ार में असफल हो जाते हैं
यह महत्वपूर्ण नहीं है कि tool कौन-सा action कर सकता है; इससे ज़्यादा महत्वपूर्ण है कि tool किन data और actions के संयोजन तक पहुँच सकता है। क्योंकि LLM के behavior का पूरी तरह अनुमान नहीं लगाया जा सकता, इसलिए उस पर भरोसा नहीं करना चाहिए। उदाहरण के लिए LLM को सिर्फ flight booking वेबसाइटों तक पहुँच दी जाए, लेकिन SSN या bank account information जैसी चीजें न दी जाएँ। यह data provenance और permission का सवाल है। जितना task अधिक sensitive data रखता है, उतने अधिक constraints चाहिए; और जितना कम sensitive हो, उतने अधिक actions अनुमति दिए जा सकते हैं। data के साथ permission information जुड़ी होनी चाहिए, और mediator को यह सीमित करना चाहिए कि newly spawned task किस data और action तक पहुँच पाए। उदाहरण: travel planning task अगर एक subtask के रूप में flight search spawn करे, तो mediator subtask को सिर्फ schedule का कुछ non-sensitive हिस्सा दे, और sensitive data तक पहुँच रोक दे
LLM agent को उपयोगकर्ता जैसा ही एक दूसरा user माना जा सकता है। हर context में उसकी अलग permissions होती हैं। उदाहरण के लिए किसी source code folder में read/write permission, और किसी दूसरे folder में सिर्फ read-only। हर project के हिसाब से LLM agent की permission अलग होगी, और यह उपयोगकर्ता की permissions का intersection या subset होगी। मूल रूप से तीन प्रकार की permissions होंगी: Allow, Deny, और Ask (अनुमति माँगना)। ज़रूरत पड़ने पर उपयोगकर्ता से approval लिया जाएगा। समस्या यह है कि मौजूदा OS तथा app/data permissions पर्याप्त रूप से fine-grained नहीं हैं। git को भी पूरे access के बजाय specific commands तक सीमित करने के हिसाब से design होना चाहिए। अभी applications user space में अपनी-अपनी तरह इसका नकली संस्करण awkward तरीके से बनाती हैं। workflow sudo जैसा है। अगर मैं अपने LLM Agent user के रूप में app launch करूँ, तो उस context के हिसाब से permission दी या रोकी जाएगी। वह सिर्फ मेरी request पर, मेरी अनुमति की सीमा के भीतर action कर सकेगा। लेकिन अभी हर agentic app को यह process खुद implement करनी पड़ती है, इसलिए इसे एक व्यवस्थित OS service बनना चाहिए। अस्थायी रूप से agent context के हिसाब से temporary user account बनाकर/मिटाकर, और IPC या network के जरिए ही संवाद करके workaround किया जा सकता है
मुझे संदेह है कि यह model सही से काम भी करेगा या नहीं। मान लें LLM कुछ कर भी सकता है, तब भी वेबसाइटें इसे detect करके कीमतें बदल सकती हैं या decision tree बिगाड़ सकती हैं। उस स्थिति में बेहतर होगा कि सभी साइटें LLM के लिए API, या 'rss + json' जैसा कुछ दें। BBS या SMS menu system की तरह, अगर सिर्फ सरल data और choices दिए जाएँ, तो वह LLM के लिए भी आदर्श होगा। यही बात ads पर भी लागू होती है। LLM को ads दिखाने की ज़रूरत ही नहीं, बल्कि LLM को धोखा देने वाले ads अधिक प्रभावी होंगे। उदाहरण के लिए flight search में ad, LLM को फुसलाकर मेरे product को सर्वश्रेष्ठ बता सकता है। सच कहूँ तो AI अभी इतना सरल है कि AI-specific ads आएँ तो मज़ेदार होगा
अगर “अच्छे response” की परिभाषा और उसका enforcement संभव है, तो शायद LLM की ज़रूरत ही न हो। HR प्रबंधक के मामले में intention सीधे पूछा जा सकता है, लेकिन LLM के पास खुद की intent नहीं होती, इसलिए मामला कठिन है
पहले मैंने John Carmack के Meta में XROS बनाते समय सिर्फ समय और पैसा बर्बाद करने वाली HN पोस्ट देखी थी। आज पढ़े इस लेख में इसके उलट 'नए OS की आवश्यकता' की बात काफ़ी ज़ोर से आती दिखती है। VM पूर्ण OS नहीं है, लेकिन मौजूदा OS/codebase का उपयोग करके हल्का बनाया जा सकता है, यही अंतर है
दोनों लेख पूरी तरह अलग बात कर रहे हैं। वास्तव में मुझे यह लेख VM या नए OS की ज़रूरत को बहुत ज़ोर से रखता हुआ भी नहीं लगता। अंततः यह access control की ही बात है
XR में performance और developer experience केंद्र में थे, जबकि LLM की दुनिया में tool/data access को कैसे sandbox और simplify किया जाए, यही असली मुद्दा है। LLM execution environment को खराब न करे या data corrupt न करे, इसके लिए बहुत काम चाहिए; और अगर standard हो, तो retraining का बोझ घटेगा और दूसरों के models इस्तेमाल करना भी आसान होगा। XR में SDK-स्तर की चीजें training से संभल सकती हैं, लेकिन AI में R&D और compute cost कहीं अधिक है
WebAssembly मूल रूप से sandbox देता है, इसलिए मुझे लगता है कि हम आधी दूरी तय कर चुके हैं। अब बाकी है instances के बीच data/permission transfer के लिए स्पष्ट interface, और instances के बीच परस्पर creation का तरीका
मुझे नहीं लगता कि यह लेख नया OS लिखने का आधार देता है। AI के लिए execution environment बनाना और AI के लिए optimized OS को शून्य से design करना, दोनों बिल्कुल अलग बातें हैं
लेख को ध्यान से पढ़ने और उसके reference links देखने के बाद मुझे लगा कि यह सिर्फ "AI के लिए VM" की बात नहीं कर रहा, बल्कि इससे भी अधिक बुनियादी समस्या की ओर इशारा कर रहा है। सिर्फ VM, LLM workflow security की जिम्मेदारी लेने के लिए पर्याप्त नहीं है। top-level workflow को network, PII, credentials जैसी sensitive चीजों और operations तक पहुँच चाहिए, और LLM prompt injection तथा consistency समस्याओं के प्रति कमजोर है। सिर्फ LLM को VM में डाल देने से बात नहीं बनेगी। ज़रूरत है workflow, data और computation को task-level पर partition करने की, ताकि सिर्फ न्यूनतम subtask को सीमित जानकारी तक पहुँच मिले — यानी 'information-flow management' की। जो subset sensitive tasks संभाले, उसी को अलग से trust और verify करना होगा। इस लेख में जिस “Secure Orchestrators” और FIDES paper का उल्लेख है, वही असली केंद्र है। “VM” आखिरकार सिर्फ इतना है कि task को ऐसे container में चलाया जाए जिसे सीमित permissions/data दिए गए हों। orchestrator को यह container बनाना होगा, उसे उपयुक्त permissions देनी होंगी, और output data पर भी sensitivity (taint-tracking) labels लगाने होंगे। कुल मिलाकर “VM for AI” से ज़्यादा सही अभिव्यक्ति “partitioning” या “isolation” होगी, और data issues पर ज़ोर होना चाहिए
यह Microsoft Wassette जैसा लगता है
लक्ष्य यह होना चाहिए कि workflow की अवधारणा ही समाप्त हो जाए। LLM+VM संयोजन में LLM को tool देना अपने-आप में workflow है। यह तरीका पहले से कई बार अच्छी तरह काम करता है, लेकिन जिन कामों में पहले से परिभाषित न किए गए exceptions या tools चाहिए होते हैं, वहाँ इसकी सीमा है। साथ ही workflow-based तरीका हमेशा linear (या DAG, loop सहित) सीमाओं में फँसा रहता है। अगला चरण यह होगा कि tools पहले से दिए ही न जाएँ, बल्कि LLM ज़रूरत पड़ते ही मौके पर खुद tool बना ले। कुछ समस्याओं में brute-force शैली का approach चाहिए होता है
यह लेख पढ़ते हुए मुझे लगा कि आजकल कई लेख ऐसे लगते हैं जैसे AI ने लिखे हों। hosting के नज़रिए से देखें तो किसी भी environment में AI agent को स्थिर रूप से चलाना ही बहुत बड़ी चुनौती है। एक developer के रूप में मैं wsl का rootless docker devcontainer इस्तेमाल कर रहा हूँ; कुछ malware शायद इसे तोड़ सकें, लेकिन फिर भी यह VM approach से अधिक सुरक्षित महसूस होता है। ऊपर से reproducibility, environment separation जैसे फायदे भी हैं, और अगर AI मेरा environment खराब कर दे तो मैं बस container दोबारा खड़ा कर सकता हूँ, इसलिए चिंता कम होती है
व्यावसायिक रूप से सबसे उन्नत model deployment तरीकों को देखें, तो isolation सहित इस लेख में बताई गई लगभग सारी विशेषताएँ पहले से लागू हैं। OS के शुद्ध स्तर तक तो नहीं, लेकिन functionality काफ़ी मिलती-जुलती है। फिर भी यह पर्याप्त नहीं है। agent को ठीक से काम करने के लिए महत्वपूर्ण resources तक access चाहिए, और वह access सिर्फ आवश्यक सीमा तक देना, LLM को isolate करने से कहीं अधिक कठिन है। LLM security के लिए अधिक सटीक मॉडल 'untrusted userspace' है। पूरे OS को design करने की ज़रूरत नहीं है
मैं इस बात से सहमत हूँ कि LLM isolation को VM design स्तर की कठोरता से लेना चाहिए। पारंपरिक OS में भी इन्हीं कारणों से इस तरह की सख्ती लागू की जाती है। हाल में मैंने इस ब्लॉग में कुछ विचार लिखे थे। मैंने LLM के काम करने के तरीके की तुलना पारंपरिक OS process/task से करके सोचा, और मुख्य abstractions को लागू करना कठिन नहीं है — 8 LLM backends के chat/tool interface को एकीकृत करके tool approval को centrally manage किया जा सकता है। capabilities model अभी लागू नहीं किया है, लेकिन पुराने OS (VSTa) के अनुभव से यह स्वाभाविक दिशा लगती है। एक LLM के पास जो permissions हों, उनका subset दूसरे LLM को delegate किया जा सके, इसके लिए delegation tool भी बना लिया है
VM जैसा नया abstract machine बनाना मुझे सिर्फ जटिलता बढ़ाने वाला कदम लगता है। account, file read/write/execute permissions, और temporary या remote access को access token से पहले ही पर्याप्त रूप से संभाला जा सकता है। मुझे लगता है कि हर capability model इन अवधारणाओं से लागू किया जा सकता है। मेरे हिसाब से बेहतर यह होगा कि पहले से मौजूद tools को सरल बनाया जाए। अभी सभी लोग कुछ नया प्रयोग कर रहे हैं, लेकिन मेरा मानना है कि यह पूरा समय अनावश्यक जटिलता घटाकर चीजें सरल करने में लगना चाहिए, न कि software में किसी मौलिक क्रांति की प्रतीक्षा में। उदाहरण के लिए MCP server को Claude के लिए एक साधारण CLI tool में बदलने में 10 मिनट लगते हैं। इतना ही काफी उपयोगी महसूस होता है
आधुनिक desktop OS का security model आज के समय के हिसाब से हास्यास्पद रूप से अपर्याप्त है। बिना किसी ढंग की warning या confirmation के उपयोगकर्ता की सारी permissions सौंप देना लगभग पागलपन है। अगर उपयोगकर्ता सचमुच बिना किसी restriction वाला environment चाहता हो तो उसे विकल्प मिलना चाहिए, लेकिन default least privilege होना चाहिए। program के हिसाब से domain-specific permissions दी जानी चाहिए। जैसे disk usage visualize करने वाले tool को filesystem तक full access चाहिए हो सकता है, लेकिन local network या internet access की कोई ज़रूरत नहीं है
VM की सबसे बड़ी ताकत damage radius को सीमित करना है। एक अच्छा agent zero day का उपयोग करके आसानी से system तोड़ सकता है। सिर्फ user-level permissions भी काफ़ी खतरनाक होती हैं, और agent के ज्ञान को firewall की तरह सीमित करना बहुत कठिन है, क्योंकि internet पर bypass के अनेक रास्ते मौजूद हैं। ऐसे systems cracking में agent बहुत सक्षम हो जाएँगे, इसलिए बेहद मज़बूत सुरक्षा तंत्र चाहिए
LLM environment में one-time read ('temporary read') जैसी चीज़ वास्तव में संभव नहीं है। एक बार data context में चला गया, तो जब तक agent मर नहीं जाता और context delete नहीं हो जाता, तब तक मानना चाहिए कि वह सभी connected जगहों तक leak हो सकता है। यह VM हो या न हो, दोनों स्थितियों में सच है, इसलिए VM अकेले security solution नहीं है
मैं अधिकांश बातों से सहमत हूँ। कई security risks VM होने या न होने से स्वतंत्र हैं। आगे defense in depth और महत्वपूर्ण होगा, लेकिन अभी हमलावरों के लिए AI agent का उपयोग कर users को नुकसान पहुँचाने के बहुत आसान तरीके मौजूद हैं
जैसे ही सिर्फ file editing tool की अनुमति दी जाती है, व्यवहार में लगभग सारी security खत्म हो जाती है
मुझे लगता है कि Fuchsia, AI model behavior control के लिए एक व्यावहारिक OS बन सकता है। यह object capability OS है, इसलिए हर component (process) सिर्फ उन्हीं capabilities तक पहुँच सकता है जो उसे explicitly दी गई हों
जब ChatGPT code execute करता है (जैसे CSV processing request), तो ऐसा लगता है कि वह ऐसे VM में चलता है जहाँ सिर्फ कुछ specific tools और libraries उपलब्ध हैं, disk sandboxed है, और internet access नहीं है। यानी हम पहले से ही कुछ हद तक इसी दिशा में जा रहे हैं
Devin और OpenHands भी इसी तरह हैं। कुछ महीने पहले किए गए मेरे AI pilot project में भी ‘agent को VM में चलाना (default)’ एक मुख्य तत्व था
यह AKS (Azure Kubernetes) आधारित Kubernetes पर gvisor और Jupyter चढ़े होने जैसा है
ज़रूरी नहीं। उदाहरण के लिए मान लें कि एक मशीन पर दो AI (जैसे ChatGPT आदि) चल रहे हों, तो उनके सहयोग या interoperability के लिए अभी कोई standards या interoperability मौजूद ही नहीं है।