Microsoft ने 13 अक्टूबर 2026 को नेटवर्क घटनाएँ संभालने वाले AI एजेंट का इंजीनियरिंग विवरण प्रकाशित किया। इसमें पहचान, अनुमतियों, उपकरणों और मानवीय मंजूरी की सीमाएँ हैं। Azure Networking के प्रमुख इंजीनियर Arun Malik ने निदान में सहायता से आगे बढ़कर चालू परिवेश में कार्रवाई करने का अनुभव बताया। उनका मुख्य संदेश है कि कोई एक सुरक्षा उपाय स्वायत्तता को सुरक्षित नहीं बनाता।
यह इंजीनियरिंग अनुभव का साझा विवरण है, किसी नए उत्पाद की सामान्य उपलब्धता की घोषणा नहीं। इसकी अहमियत उस सवाल में है जो AI को कार्य प्रणालियों से जोड़ने वाली हर संस्था के सामने आता है: क्या समाधान समझाने की क्षमता एजेंट को उसे लागू करने की अनुमति भी देती है? जवाब अनुमति प्रणाली में तय होना चाहिए, मॉडल की प्रभावशाली भाषा पर निर्भर नहीं।
सुझाव और हो चुके बदलाव में अंतर
जानकारी एकत्र करने वाला एजेंट कर्मचारी को अलग-अलग स्क्रीन खोलने से बचा सकता है। लेकिन जब वह सेटिंग बदल सकता हो, डेटा मिटा सकता हो या प्रक्रिया शुरू कर सकता हो, तब गलत उत्तर संचालन संबंधी गलती बन सकता है। यह बात बिना हमलावर वाली साधारण खराबी में भी महत्वपूर्ण है: संदर्भ गलत समझना गलत जगह कार्रवाई के लिए पर्याप्त हो सकता है।
एक काल्पनिक उदाहरण लें। सहायता एजेंट कई मिलते-जुलते अनुरोध पहचानकर साझा सेटिंग बदलने का सुझाव देता है। सुझाव उचित हो सकता है, फिर भी कुछ ग्राहकों का परिवेश अलग हो सकता है। कार्रवाई से पहले सटीक लक्ष्य और बदलाव का दायरा जाँचना जरूरी है। सिद्धांततः सही समाधान हर ग्राहक के लिए सही कार्रवाई नहीं होता।
व्यावहारिक निर्णय है कि काम को अलग कार्रवाइयों में बाँटा जाए। पढ़ना, प्रस्ताव तैयार करना, मसौदा बनाना और बदलाव करना अलग अनुमतियाँ हैं। एजेंट शुरुआती चरण तेजी से पूरा कर सकता है, जबकि वास्तविक स्थिति बदलने वाला चरण अतिरिक्त जाँच के पीछे रहे। इससे शुरू से व्यापक नियंत्रण दिए बिना लाभ मिलता है।
अनुमतियाँ बातचीत से बाहर लागू होनी चाहिए
OWASP भाषा मॉडल अनुप्रयोगों में जरूरत से ज्यादा अधिकार को ऐसा जोखिम मानता है जो अत्यधिक क्षमताओं, अनुमतियों या स्वतंत्रता से पैदा हो सकता है। उसके सुझावों में अधिकार सीमित करना और अधिक प्रभाव वाली कार्रवाइयों के लिए मानवीय मंजूरी शामिल है। इससे एजेंट को सावधान रहने के लिए कहने और प्रणाली द्वारा सचमुच लागू सीमा का अंतर स्पष्ट होता है।
मसलन, दूसरे फोल्डर न छूने का आंतरिक निर्देश पर्याप्त नहीं यदि तकनीकी कनेक्शन सभी फोल्डरों तक पहुँच देता है। एजेंट को अलग खाता और भूमिका के अनुसार पहुँच दें, फिर जाँचें कि दायरे से बाहर कार्रवाई रुकती है। अनुरोध सामान्य और तार्किक लगे, तब भी यह जाँच सफल होनी चाहिए।
काम शुरू करने वाले व्यक्ति और उसे करने वाली पहचान में अंतर भी जरूरी है। कर्मचारी विश्लेषण माँग सकता है, लेकिन मिटाने की मंजूरी देने का अधिकार नहीं रखता हो। यदि हर अनुरोध पूरा करने के लिए एजेंट को अपने आप प्रशासक अधिकार मिलें, तो संगठन की सीमा ठीक वहीं गायब हो जाती है जहाँ निगरानी चाहिए। स्पष्ट जिम्मेदारी तय करने में मदद करती है कि अनुमतियाँ कौन बदल सकता है।
मानवीय मंजूरी में वास्तविक निर्णय सामने होना चाहिए
मंजूरी का बटन इस बात की गारंटी नहीं कि व्यक्ति समझ गया कि क्या होने वाला है। उपयोगी मंजूरी में दिखना चाहिए कि क्या बदलेगा, किस लक्ष्य पर, कितने दायरे में और पुरानी स्थिति लौटाने के बारे में क्या मालूम है। केवल सेवा बेहतर बनाने जैसी सामान्य व्याख्या मूल मंशा से बाहर की कार्रवाई पहचानना कठिन बनाती है।
मंजूरी को किसी खास बदलाव की सहमति मानें, किसी भी तरीके से काम पूरा करने की खुली अनुमति नहीं। मंजूरी के बाद एजेंट लक्ष्य या कार्रवाई का प्रकार बदले तो निर्णय दोबारा जाँचना चाहिए। छोटी संस्था में दूसरा व्यक्ति यह कर सकता है; बड़ी संस्था इसे मौजूदा अनुमोदन प्रक्रिया में जोड़ सकती है।
अनुरोधों की आवृत्ति भी मायने रखती है। हर साधारण जानकारी पढ़ने पर क्लिक माँगा जाए तो कर्मचारी बिना पढ़े मंजूरी देने के आदी हो सकते हैं। पहले तय करें कि कौन-सी कार्रवाइयाँ सीमित दायरे में चलेंगी और कहाँ रुकना जरूरी है। लक्ष्य मानव का ध्यान उन निर्णयों पर केंद्रित करना है जहाँ गलती की कीमत है, मंजूरी को रस्म बनाना नहीं।
चालू प्रणाली जोड़ने से पहले क्या जाँचें
उचित शुरुआत गैर-संवेदनशील जानकारी और सीमित अनुमतियों वाला परीक्षण परिवेश है। केवल सही काम पूरा होने को न जाँचें; अधूरी जानकारी, विरोधी निर्देश और अनुपलब्ध उपकरण पर प्रतिक्रिया भी देखें। स्पष्टीकरण माँगने के लिए रुकने वाली प्रणाली अंत तक अनुमान लगाते रहने वाली प्रणाली से अधिक उपयोगी हो सकती है।
इसके बाद सिर्फ अंतिम परिणाम नहीं, कार्रवाइयों का क्रम देखें। दो रास्ते एक ही दस्तावेज बना सकते हैं, लेकिन एक में अनावश्यक जानकारी पढ़ी गई हो या अनधिकृत बदलाव की कोशिश हुई हो। उपयुक्त रिकॉर्ड फर्क स्पष्ट करता है, पर गतिविधि लॉग खुद संवेदनशील जानकारी का अतिरिक्त भंडार नहीं बनना चाहिए।
उपयोग बढ़ाने से पहले तय करें कि एजेंट कौन रोक सकता है, उसकी पहुँच कैसे वापस ली जाएगी और गलत बदलाव कौन सँभालेगा। बहाली हमेशा संभव नहीं: भेजा संदेश पढ़ा जा चुका हो सकता है और बाहर गया डेटा वापस लाना संभव नहीं भी हो सकता। इसलिए बहाली के परीक्षण से शुरुआती अनुमतियाँ तय होनी चाहिए।
इजराइल की टीमों के लिए इसका अर्थ
IT टीम, सेवा मंच चलाने वाला व्यवसाय या स्वचालन आजमाने वाली संस्था को यह सिद्धांत अपनाने के लिए क्लाउड कंपनी का बुनियादी ढाँचा दोहराना जरूरी नहीं। सीमित काम से शुरुआत करें, अपेक्षित परिणाम तय करें और सरल भाषा में लिखें कि एजेंट क्या नहीं कर सकता। फिर जाँचें कि तकनीकी कनेक्शन उसी परिभाषा के अनुरूप है। कोई नया कनेक्शन जोड़ने या काम बदलने पर सीमाओं की समीक्षा दोहराएँ। सीमित कार्यप्रवाह की मंजूरी से यह नहीं मान लेना चाहिए कि विस्तृत कार्यप्रवाह भी उन्हीं अनुमतियों, उसी मंजूरी देने वाले व्यक्ति या उसी रोकने की व्यवस्था के लिए उपयुक्त है।
आपूर्तिकर्ता से सफलता के साथ रोक लगाने का प्रदर्शन भी माँगें। अनुमति से बाहर कार्रवाई जरूरी होने पर क्या होता है? अस्वीकृति कौन देखता है? क्या पूरा कार्यप्रवाह मिटाए बिना पहुँच हट सकती है? ठोस जवाब सामान्य सुरक्षा परत के वादे से ज्यादा उपयोगी हैं।
Microsoft का लेख यह साबित नहीं करता कि उसके या किसी अन्य आपूर्तिकर्ता के सभी एजेंट हर खराबी से सुरक्षित हैं। वह व्यापक अर्थ वाले डिजाइन निर्णय पर जोर देता है: स्वायत्तता का आकलन प्रणाली द्वारा रोकी गई चीजों से भी होता है। महत्वपूर्ण प्रगति केवल एक और काम अपने आप पूरा होना नहीं, बल्कि उसके करने के तरीके को समझा और सीमित कर पाना है।