जब एक AI एजेंट अपने स्वयं के क्रेडेंशियल्स लेकर सीधे बाहरी सेवाओं से संपर्क करता है, तो वह कर्मचारी सॉफ्टवेयर की तरह कम और बिना किसी सुपरवाइजर वाले कॉर्पोरेट कार्ड वाले ठेकेदार की तरह अधिक व्यवहार करता है। आप यह नहीं देख सकते कि उसने क्या छुआ, किसने एक्सेस को मंजूरी दी, या क्यों एक बातचीत की लागत दूसरी की तुलना में दस गुना अधिक थी। लॉग्स दर्जनों सेवाओं में बिखर जाते हैं। सवाल बढ़ते जाते हैं।
एजेंट ने वास्तव में किस टूल का उपयोग किया? उसे उस डेटाबेस को छूने की अनुमति किसने दी? मंगलवार का रन चालीस हजार टोकन क्यों खर्च कर गया जबकि सोमवार में केवल पांच का उपयोग हुआ था? हमने वास्तव में कितना खर्च किया?
उपयोगकर्ताओं, मॉडल्स और सेवाओं के बीच एक केंद्रीय कंट्रोल लेयर (central control layer) के बिना, ये सवाल अनुत्तरित रह जाते हैं। आपको एक ऐसे सिंगल प्लेन की आवश्यकता है जो हर कनेक्शन को एक बार रजिस्टर करे, केवल उन्हीं फंक्शन्स के सीमित सेट को उजागर करे जिनकी एजेंट को वास्तव में आवश्यकता है, और हर निष्पादन (execution) को पूरी तरह से रिकॉर्ड करे। यह लेख deco Studio का उपयोग करके एक उन्नत लैब के माध्यम से जानकारी देता है, जो उस लोकल कंट्रोल प्लेन के रूप में कार्य करता है। आप इसे सेटअप करेंगे, एक सुरक्षित Model Context Protocol सर्वर से कनेक्ट करेंगे, ठीक एक अनुमत फंक्शन को उजागर करेंगे, और देखेंगे कि क्या होता है जब एक एजेंट अपनी सीमा से बाहर जाने की कोशिश करता है।
बिखरे हुए क्रेडेंशियल्स की समस्या
एक विशिष्ट टीम सेटअप की कल्पना करें। एक डेवलपर व्यक्तिगत की (personal key) का उपयोग करके एक एजेंट को सर्च API से जोड़ता है। दूसरा उसी एजेंट को प्रोडक्शन डेटाबेस से जोड़ देता है क्योंकि डेमो हानिरहित लग रहा था। तीसरा एक बिलिंग लुकअप टूल जोड़ता है ताकि एजेंट "इनवॉइस में मदद" कर सके। प्रत्येक कनेक्शन दूसरों के लिए अदृश्य है। अब एजेंट के पास सर्च, प्रोडक्शन डेटा और वित्तीय रिकॉर्ड तक सीधी पहुंच है, लेकिन टीम के पास इस बात की कोई एकीकृत सूची नहीं है कि क्या लाइव है।
जब क्रेडेंशियल्स एजेंट के भीतर होते हैं, तो गवर्नेंस (governance) टूट जाती है। आप केंद्रीय रूप से एक्सेस को रद्द नहीं कर सकते क्योंकि की (key) एजेंट की मेमोरी या उसकी लोकल एनवायरनमेंट फ़ाइल में होती है। आप उपयोग का ऑडिट नहीं कर सकते क्योंकि बाहरी सेवा केवल एक अज्ञात स्वचालित क्लाइंट से API कॉल देखती है। लागत का आश्चर्य कुछ दिनों बाद क्लाउड बिल में दिखाई देता है, और तब तक किसी को याद नहीं रहता कि किस प्रॉम्प्ट ने इस उछाल को ट्रिगर किया था।
deco Studio में अपना कंट्रोल प्लेन बनाना
deco Studio एक लोकल हब के रूप में कार्य करके इसे ठीक करता है। आप इसे अपनी मशीन पर चलाते हैं, और यह वह एकमात्र स्थान बन जाता है जहाँ कॉन्फ़िगरेशन रहते हैं। API कीज़ और टूल डेफिनिशन को एजेंटों में बिखेरने के बजाय, आप Studio के भीतर एक बार कनेक्शन रजिस्टर करते हैं। फिर आप तय करते हैं कि प्रत्येक एजेंट कौन से फंक्शन देख सकता है।
इसे एक स्विचबोर्ड लगाने की तरह समझें। सभी तार एक ही कमरे में आते हैं। आप चुनते हैं कि कौन सी लाइनें किन विभागों से जुड़ती हैं, और आप हर कॉल का रिकॉर्ड रखते हैं।
deco Studio को स्थानीय रूप से चलाकर शुरुआत करें। एक बार जब यह शुरू हो जाए, तो आप कॉन्फ़िगरेशन को केंद्रीकृत कर देते हैं। अब प्रत्येक एजेंट जो किसी टूल का उपयोग करना चाहता है, उसे सीधे बाहरी सेवा से नहीं, बल्कि कंट्रोल प्लेन से पूछना होगा। यह तुरंत एक चोकपॉइंट (chokepoint) बनाता है जहाँ आप देख सकते हैं, फ़िल्टर कर सकते हैं और लॉग कर सकते हैं।
एक सुरक्षित MCP सर्वर को कनेक्ट करना
इस लैब में, आप एक Model Context Protocol सर्वर को कनेक्ट करते हैं। MCP मॉडल्स को बाहरी टूल के साथ इंटरैक्ट करने देने के लिए एक ओपन स्टैंडर्ड है, लेकिन स्टैंडर्ड सुरक्षा की गारंटी नहीं देते हैं। यहाँ महत्वपूर्ण कदम चयनात्मकता (selectivity) है। आप सर्वर द्वारा दिए जाने वाले प्रत्येक एंडपॉइंट को आँख बंद करके उजागर नहीं करते हैं। आप deco Studio में सर्वर को रजिस्टर करते हैं, और फिर अपने टेस्ट एजेंट को केवल एक अनुमत फंक्शन ही दिखाते हैं।
उदाहरण के लिए, आपका MCP सर्वर दस फंक्शन दे सकता है: फ़ाइल रीड, फ़ाइल राइट, डेटाबेस क्वेरी, नेटवर्क फ़ेच और अन्य। आप एक हानिरहित ऑपरेशन चुनते हैं, शायद एक सैंडबॉक्स्ड कैलकुलेटर या सिंथेटिक डेटा के विरुद्ध रीड-ओनली लुकअप, और केवल उसे ही उजागर करते हैं। बाकी नौ एजेंट के लिए अदृश्य हो जाते हैं। यदि एजेंट उनके लिए पूछता है, तो कंट्रोल प्लेन स्पष्ट रूप से मना कर देता है।
यह 'प्रिंसिपल ऑफ लीस्ट प्रिविलेज' (principle of least privilege) को यांत्रिक रूप से लागू करना है। एजेंट को क्षमता एक विनम्र निर्देश के माध्यम से नहीं, बल्कि एक सॉफ्टवेयर बाउंड्री के माध्यम से मिलती है।
बाउंड्री का परीक्षण करना
एक टेस्ट एजेंट बनाएं और उसे अपने deco Studio कंट्रोल प्लेन की ओर निर्देशित करें। उसे ऐसा कार्य दें जिसमें केवल एक अनुमत फंक्शन की आवश्यकता हो। उसे सफल होते हुए देखें। Studio के भीतर के लॉग मॉडल अनुरोध, कंट्रोल प्लेन के माध्यम से टूल कॉल रूटिंग, फंक्शन निष्पादन और मॉडल को वापस आने वाले परिणाम को दिखाएंगे। आप एक निरंतर ट्रेस में पूरा पथ पढ़ सकते हैं।
अब एजेंट को दूसरा कार्य दें जिसमें ऐसे फ़ंक्शन की आवश्यकता हो जिसे आपने जानबूझकर बाहर रखा है। एजेंट इस सीमा के इर्द-गिर्द तर्क करने का प्रयास कर सकता है, या यह भ्रम (hallucinate) में आ सकता है कि वह टूल मौजूद है। दोनों ही स्थितियों में, कॉल कंट्रोल प्लेन तक पहुँचती है, allowlist उसे अस्वीकार कर देती है, और निष्पादन (execution) विफल हो जाता है। यह विफलता इस बात का प्रमाण है कि सीमा सॉफ्टवेयर द्वारा लागू की गई है, न कि केवल सैद्धांतिक है।
इसे पहले सिंथेटिक कार्यों के साथ करें। जनरेट किए गए यूज़र प्रोफाइल से भरा एक नकली डेटाबेस बनाएँ। एजेंट को इसे क्वेरी करने दें। allowlist और अस्वीकृतियों (denials) को सत्यापित करें। जब आप सीमा पर भरोसा करने लगें, तभी एजेंट को प्रोडक्शन सिस्टम की ओर निर्देशित करने पर विचार करें। दीवार को सत्यापित करने से पहले वास्तविक डेटा की ओर भागना ही वह तरीका है जिससे सीक्रेट्स लीक होते हैं।
रन के पूरे पथ (Full Path) को पढ़ना
deco Studio आपको निष्पादन (execution) की प्रत्येक परत का निरीक्षण करने की अनुमति देता है। आप रॉ मॉडल रिक्वेस्ट देखते हैं: प्रॉम्ट, कॉन्टेक्स्ट विंडो, फ़ॉर्मेटिंग। आप वह टूल कॉल देखते हैं जिसे मॉडल ने करने का निर्णय लिया है। आप देखते हैं कि कंट्रोल प्लेन उस कॉल को कैसे रूट करता है, फ़ंक्शन को निष्पादित करता है, और पेलोड वापस करता है। अंत में, आप देखते हैं कि मॉडल अपना उत्तर बनाने के लिए उस परिणाम का उपयोग कैसे करता है।
यह दृश्यता बुनियादी ऑडिट प्रश्नों का उत्तर देती है। आप जानते हैं कि कौन सा टूल चला क्योंकि कंट्रोल प्लेन ने उसे लॉग किया था। आप जानते हैं कि किसने एक्सेस दिया क्योंकि कॉन्फ़िगरेशन रिकॉर्ड एक स्थानीय रजिस्ट्री में स्थित हैं। आप जानते हैं कि रन महंगा क्यों था क्योंकि आप टोकन गिन सकते हैं।
जो महत्वपूर्ण है उसे गिनना
प्रत्येक रन के लिए, चार विशिष्ट मेट्रिक्स को ट्रैक करें। पहला, इनपुट और आउटपुट टोकन। ये मॉडल की लागत का मुख्य हिस्सा होते हैं, और आपको सटीक गणना की आवश्यकता होती है, न कि अनुमानित। दूसरा, मॉडल लेटेंसी को टूल लेटेंसी से अलग करें। आपके प्रॉम्ट और मॉडल की प्रतिक्रिया के बीच का समय, टूल कॉल का उत्तर देने में बाहरी सेवा द्वारा लिए गए समय से अलग होता है। दोनों में भ्रमित होने से गलत निदान (misdiagnosed) हो सकता है। तीसरा, सत्यापित प्रदाता दरों (provider rates) के आधार पर लागत की गणना करें। अनुमान न लगाएं। अपने प्रदाता की प्राइसिंग शीट देखें और उसे मापे गए टोकन से मिलाएं। चौथा, सफल कॉल्स की तुलना अस्वीकृत अनधिकृत कॉल्स से करें। अस्वीकृति की उच्च संख्या का अर्थ है कि आपका एजेंट सीमाओं की जांच कर रहा है या आपकी allowlist वैध आवश्यकताओं के साथ मेल नहीं खा रही है।
ये नंबर एजेंट ऑपरेशन्स को एक 'ब्लैक-बॉक्स सब्सक्रिप्शन' से एक 'ऑब्जर्वेबल सिस्टम' में बदल देते हैं। आप बजट बना सकते हैं, अनुकूलित (optimize) कर सकते हैं और समझा सकते हैं।
लोकल कंट्रोल और लोकल एक्जीक्यूशन के बीच का अंतर
यहाँ एक ऐसा सबक है जो सावधान बिल्डर्स को भी उलझा देता है। अपने मशीन पर deco Studio चलाने से आपको कॉन्फ़िगरेशन पर लोकल कंट्रोल मिलता है, लेकिन यह स्वयं मॉडल के लोकल एक्जीक्यूशन की गारंटी नहीं देता है। यदि आप एजेंट को OpenAI, Anthropic, या किसी भी होस्टेड API जैसे बाहरी प्रदाता को कॉल करने के लिए कॉन्फ़िगर करते हैं, तो आपके प्रॉम्ट आपकी मशीन छोड़ देते हैं। Studio गेट (gate) को मैनेज करता है, लेकिन डेटा अभी भी नेटवर्क के माध्यम से पार होता है।
हमेशा इन सीमाओं को ट्रैक करें। जानें कि पाइपलाइन के कौन से हिस्से localhost पर रहते हैं और कौन से हिस्से किसी और के सर्वर पर जाते हैं। यदि आपका डेटा संवेदनशील है, तो टूल लेयर का लोकल कंट्रोल पर्याप्त नहीं है। आपको यह भी जानने की आवश्यकता है कि मॉडल इन्फरेंस (inference) कहाँ होता है। लोकल डैशबोर्ड के आराम को रिमोट मॉडल की वास्तविकता के साथ भ्रमित न करें।
निर्देश, प्राधिकरण (Authorization) नहीं हैं
एक खतरनाक शॉर्टकट प्रॉम्टिंग के माध्यम से एजेंट को सुरक्षित करने का प्रयास करना है। मॉडल को यह कहना कि, "कभी भी डिलीट फ़ंक्शन को कॉल न करें," कोई सुरक्षा नियंत्रण नहीं है। यह केवल एक सुझाव है। मॉडल निर्देशों की गलत व्याख्या कर सकते हैं, जेलब्रेक प्रॉम्ट का शिकार हो सकते हैं, या बस तर्क करने में त्रुटि कर सकते हैं। वास्तविक सुरक्षा सॉफ्टवेयर बाउंड्री पर होती है।
यह परिभाषित करने के लिए कि कौन से फ़ंक्शन कॉल किए जा सकते हैं, deco Studio के भीतर allowlists का उपयोग करें। कंट्रोल प्लेन के भीतर सर्वर-साइड चेक के साथ उन सीमाओं को लागू करें। एजेंट को अपनी क्षमताओं का पता उसी तरह चलना चाहिए जैसे एक उपयोगकर्ता फ़ाइल परमिशन का पता लगाता है: एक सख्त सीमा (hard limit) से टकराकर, न कि किसी मित्रवत नोट को पढ़कर। सुरक्षा आर्किटेक्चर में होनी चाहिए, प्राकृतिक भाषा में नहीं।
छोटी शुरुआत करें, संशयवादी रहें
अपने कंट्रोल प्लेन को एक बार में एक कदम करके बनाएँ। एक MCP सर्वर। एक एक्सपोज़्ड फ़ंक्शन। एक सिंथेटिक कार्य। सत्यापित करें कि एजेंट वहां सफल होता है जहां उसे होना चाहिए और वहां विफल होता है जहां उसे विफल होना चाहिए। ट्रेस (trace) को पढ़ें। टोकन काउंट की पुष्टि करें। फिर अगला टूल जोड़ें।
नियंत्रण कोई ऐसा स्विच नहीं है जिसे आप बस घुमा दें। यह सीमाओं पर भरोसा करने से पहले उन्हें साबित करने की एक आदत है। deco Studio आपको उस आदत का अभ्यास करने के लिए लोकल प्लेन देता है। स्वायत्त एजेंटों (autonomous agents) के झुंड को एक प्रबंधित, ऑब्जर्वेबल और सीमित सिस्टम में बदलने के लिए इसका उपयोग करें।
स्रोत: Controlling AI Agents in deco Studio: Tools, Permissions, and Cost
वैकल्पिक लर्निंग कम्युनिटी: टेलीग्राम पर GyaanSetu AI