जेव्हा एखादा AI agent स्वतःची credentials घेऊन थेट बाह्य सेवांशी (external services) संपर्क साधतो, तेव्हा तो कर्मचाऱ्याच्या सॉफ्टवेअरसारखा कमी आणि कॉर्पोरेट कार्ड असलेला पण कोणताही सुपरवायझर नसलेला कॉन्ट्रॅक्टरसारखा जास्त वागतो. त्याने कशाला स्पर्श केला, कोणाकडे प्रवेशाची (access) मंजुरी घेतली, किंवा एखादा संवाद दुसऱ्यापेक्षा दहापट महाग का पडला, हे तुम्हाला पाहता येत नाही. लॉग्स (logs) डझनभर सेवांमध्ये विखुरलेले असतात. प्रश्न वाढतच जातात.
एजंटने प्रत्यक्षात कोणते टूल (tool) वापरले? त्याला त्या डेटाबेसमध्ये प्रवेश करण्याची परवानगी कोणी दिली? सोमवारी फक्त पाच टोकन्स वापरले असताना मंगळवारी चालीने चाळीस हजार टोकन्स का खर्च केले? आपण प्रत्यक्षात किती खर्च केला?
वापरकर्ते (users), मॉडेल्स आणि सेवा यांच्यामध्ये एक मध्यवर्ती नियंत्रण स्तर (central control layer) नसल्यास, ही प्रश्ने अनुत्तरीत राहतात. तुम्हाला अशा एका सिंगल प्लेनची (single plane) गरज आहे जे प्रत्येक कनेक्शन एकदाच नोंदवते, एजंटला खरोखर आवश्यक असलेल्या मर्यादित फंक्शन्सनाच (functions) उपलब्ध करून देते आणि प्रत्येक एक्झिक्युशनची (execution) पूर्ण नोंद ठेवते. हा लेख deco Studio ला स्थानिक नियंत्रण प्लेन (local control plane) म्हणून वापरून एका प्रगत लॅबमधून मार्गदर्शन करतो. तुम्ही ते सेट कराल, एक सुरक्षित Model Context Protocol सर्व्हर कनेक्ट कराल, नेमके एकच परवानगी असलेले फंक्शन उपलब्ध करून द्याल आणि जेव्हा एखादा एजंट आपल्या मर्यादेबाहेर जाण्याचा प्रयत्न करतो तेव्हा काय होते ते पाहाल.
विखुरलेल्या Credentials ची समस्या
एका सामान्य टीम सेटअपची कल्पना करा. एक डेव्हलपर वैयक्तिक की (personal key) वापरून एजंटला सर्च API शी जोडतो. दुसरा डेव्हलपर डेमो सुरक्षित वाटल्यामुळे त्याच एजंटला प्रोडक्शन डेटाबेसशी जोडतो. तिसरा डेव्हलपर बिलिंग लूकअप टूल जोडतो जेणेकरून एजंट "इनव्हॉइसेसमध्ये मदत" करू शकेल. प्रत्येक कनेक्शन इतरांना दिसत नाही. आता एजंटला सर्च, प्रोडक्शन डेटा आणि आर्थिक रेकॉर्ड्सचा थेट प्रवेश आहे, परंतु टीमकडे काय सक्रिय (live) आहे याची कोणतीही एकत्रित यादी नाही.
जेव्हा credentials एजंटच्या आत असतात, तेव्हा गव्हर्नन्स (governance) कोलमडते. तुम्ही मध्यवर्ती पद्धतीने प्रवेश रद्द (revoke) करू शकत नाही कारण ती की एजंटच्या मेमरीमध्ये किंवा त्याच्या स्थानिक एन्व्हायरनमेंट फाईलमध्ये असते. तुम्ही वापराचे ऑडिट (audit) करू शकत नाही कारण बाह्य सेवा केवळ एका अनामिक ऑटोमेटेड क्लायंटकडून आलेला API कॉल पाहते. खर्चाचा धक्का काही दिवसांनंतर क्लाउड बिलावर दिसतो आणि तोपर्यंत कोणता प्रॉम्प्ट (prompt) खर्च वाढवण्यास कारणीभूत ठरला, हे कोणालाही आठवत नाही.
deco Studio मध्ये तुमचे कंट्रोल प्लेन तयार करणे
deco Studio एका स्थानिक हब (local hub) म्हणून काम करून ही समस्या सोडवते. तुम्ही ते तुमच्या स्वतःच्या मशीनवर चालवता आणि ते कॉन्फिगरेशनसाठी एकच ठिकाण बनते. API की आणि टूल डेफिनिशन्स (tool definitions) एजंट्समध्ये विखुरण्याऐवजी, तुम्ही स्टुडिओमध्ये एकदाच कनेक्शन नोंदवता. त्यानंतर प्रत्येक एजंटला नेमकी कोणती फंक्शन्स दिसू शकतात, याचा निर्णय तुम्ही घेता.
याला एक स्विचबोर्ड बसवल्याप्रमाणे समजा. सर्व वायर्स एकाच खोलीत येतात. तुम्ही कोणत्या लाईन्स कोणत्या विभागांना जोडायच्या हे निवडता आणि प्रत्येक कॉलची नोंद ठेवता.
deco Studio स्थानिक पातळीवर (locally) चालवून सुरुवात करा. एकदा ते सुरू झाले की, तुम्ही कॉन्फिगरेशनचे केंद्रीकरण करता. ज्या एजंटला टूल वापरायचे आहे, त्याला आता थेट बाह्य सेवेऐवजी कंट्रोल प्लेनला विचारावे लागेल. यामुळे लगेच एक चोकपॉइंट (chokepoint) तयार होतो जिथे तुम्ही निरीक्षण, फिल्टरिंग आणि लॉगिंग करू शकता.
एक सुरक्षित MCP सर्व्हर कनेक्ट करणे
या लॅबमध्ये, तुम्ही Model Context Protocol सर्व्हर कनेक्ट करता. मॉडेल्सना बाह्य साधनांशी (external tools) संवाद साधू देण्यासाठी MCP हा एक ओपन स्टँडर्ड आहे, परंतु स्टँडर्ड्स सुरक्षिततेची हमी देत नाहीत. येथे महत्त्वाचे पाऊल म्हणजे निवडकता (selectivity). सर्व्हर जे एंडपॉइंट्स (endpoints) ऑफर करतो, ते तुम्ही आंधळेपणाने उघडत नाही. तुम्ही deco Studio मध्ये सर्व्हर नोंदवता आणि त्यानंतर तुमच्या टेस्ट एजंटला फक्त एकच परवानगी असलेले फंक्शन उपलब्ध करून देता.
उदाहरणार्थ, तुमच्या MCP सर्व्हरमध्ये दहा फंक्शन्स असू शकतात: फाईल रीड (file read), फाईल राईट (file write), डेटाबेस क्वेरी (database query), नेटवर्क फेच (network fetch) आणि इतर. तुम्ही एक सुरक्षित ऑपरेशन निवडता, कदाचित सँडबॉक्स कॅल्क्युलेटर (sandboxed calculator) किंवा सिंथेटिक डेटावरील रीड-ओन्ली लूकअप, आणि फक्त तेच उपलब्ध करून देता. इतर नऊ फंक्शन्स एजंटला दिसत नाहीत. जर एजंटने त्यांच्याबद्दल विचारले, तर कंट्रोल प्लेन स्पष्ट नकार देते.
हे 'principle of least privilege' यंत्रवत (mechanical) केलेले रूप आहे. एजंटला क्षमता एखाद्या नम्र सूचनेद्वारे नाही, तर सॉफ्टवेअर बाउंड्रीद्वारे (software boundary) प्राप्त होते.
बाउंड्रीची चाचणी घेणे
एक टेस्ट एजंट तयार करा आणि तो तुमच्या deco Studio कंट्रोल प्लेनशी जोडा. त्याला एक असे कार्य द्या ज्यासाठी केवळ एकच परवानगी असलेले फंक्शन आवश्यक आहे. ते यशस्वी होताना पहा. स्टुडिओमधील लॉग्समध्ये मॉडेलची विनंती (model request), कंट्रोल प्लेनद्वारे टूल कॉलचे राउटिंग, फंक्शन एक्झिक्युशन आणि मॉडेलकडे परत येणारा रिझल्ट (result) दिसेल. तुम्ही संपूर्ण मार्ग एका सलग ट्रेसमध्ये (continuous trace) वाचू शकता.
आता एजंटला दुसरे असे कार्य द्या ज्यासाठी तुम्ही जाणीवपूर्वक वगळलेले फंक्शन आवश्यक असेल. एजंट त्या मर्यादांच्या भोवती तर्क करण्याचा प्रयत्न करू शकतो किंवा ते टूल अस्तित्वात आहे असा भ्रम (hallucinate) निर्माण करू शकतो. दोन्ही परिस्थितीत, कॉल कंट्रोल प्लेनपर्यंत पोहोचतो, अलाऊलिस्ट त्याला नाकारते आणि अंमलबजावणी अयशस्वी होते. ही अपयशाची घटना म्हणजे तुमची सीमा केवळ सैद्धांतिक नसून सॉफ्टवेअरद्वारे लागू केलेली आहे याचा पुरावा आहे.
हे प्रथम सिंथेटिक टास्कसह करा. जनरेट केलेल्या युजर प्रोफाइल्सने भरलेला एक बनावट डेटाबेस तयार करा. एजंटला तो क्वेरी करू द्या. अलाऊलिस्ट आणि नकार (denials) तपासा. सीमेवर विश्वास बसल्यानंतरच तुम्ही एजंटला प्रोडक्शन सिस्टम्सकडे वळवण्याचा विचार करावा. भिंत तपासण्यापूर्वीच खऱ्या डेटाकडे धाव घेणे म्हणजे गुपिते (secrets) लीक होण्याचे कारण ठरते.
रनचा संपूर्ण मार्ग (Full Path) वाचणे
deco Studio तुम्हाला अंमलबजावणीच्या प्रत्येक थराची तपासणी करण्याची परवानगी देते. तुम्हाला रॉ मॉडेल रिक्वेस्ट दिसते: प्रॉम्प्ट, कॉन्टेक्स्ट विंडो, फॉरमॅटिंग. मॉडेलने घेतलेला टूल कॉल तुम्हाला दिसतो. कंट्रोल प्लेन तो कॉल कसा राउट करते, फंक्शन कसे एक्झिक्युट करते आणि पेलोड कसा रिटर्न करते हे देखील तुम्हाला दिसते. शेवटी, मॉडेल त्याचे उत्तर तयार करण्यासाठी त्या निकालाचा वापर कसे करते, हे तुम्हाला दिसते.
ही दृश्यमानता मूलभूत ऑडिट प्रश्नांची उत्तरे देते. कोणता टूल फायर झाला हे तुम्हाला समजते कारण कंट्रोल प्लेनने त्याची नोंद (log) केली असते. कोणाला प्रवेश दिला हे तुम्हाला समजते कारण कॉन्फिगरेशन रेकॉर्ड्स एका स्थानिक रजिस्ट्रीमध्ये असतात. रन महाग का होते हे तुम्हाला समजते कारण तुम्ही टोकन्स मोजू शकता.
महत्त्वाच्या गोष्टी मोजणे
प्रत्येक रनसाठी, चार विशिष्ट मेट्रिक्सचा मागोवा घ्या. पहिले, इनपुट आणि आउटपुट टोकन्स. हे मॉडेलच्या खर्चाचा मोठा भाग असतात आणि तुम्हाला अंदाजे आकड्यांऐवजी अचूक संख्यांची गरज असते. दुसरे, मॉडेल लॅटन्सी आणि टूल लॅटन्सी वेगळी करा. तुमच्या प्रॉम्प्ट आणि मॉडेलच्या प्रतिसादादरम्यानचा वेळ आणि बाह्य सेवा टूल कॉलला उत्तर देण्यासाठी घेणारा वेळ यात फरक असतो. या दोन्ही गोष्टींमध्ये गोंधळल्यास स्लोडाउन्सचे चुकीचे निदान होऊ शकते. तिसरे, पडताळणी केलेल्या प्रोव्हायडर दरांनुसार खर्च मोजा. अंदाज लावू नका. तुमच्या प्रोव्हायडरची प्राइसिंग शीट तपासा आणि मोजलेल्या टोकन्सशी त्याची तुलना करा. चौथे, यशस्वी कॉल्सची तुलना नाकारलेल्या अनधिकृत कॉल्सशी करा. नकार जास्त असल्यास याचा अर्थ असा की तुमचा एजंट सीमा तपासत आहे किंवा तुमची अलाऊलिस्ट वैध गरजांशी सुसंगत नाही.
हे आकडे एजंट ऑपरेशन्सना 'ब्लॅक-बॉक्स सबस्क्रिप्शन' मधून एक 'ऑब्झर्व्हेबल सिस्टम' (निरीक्षणक्षम प्रणाली) मध्ये रूपांतरित करतात. तुम्ही बजेट ठरवू शकता, ऑप्टिमाइझ करू शकता आणि स्पष्टीकरण देऊ शकता.
लोकल कंट्रोल आणि लोकल एक्झिक्यूशन मधील फरक
हा एक असा धडा आहे जो सावध बिल्डर्सनाही गोंधळात टाकू शकतो. तुमच्या मशीनवर deco Studio चालवल्यामुळे तुम्हाला कॉन्फिगरेशनवर लोकल कंट्रोल मिळतो, परंतु ते मॉडेलच्या स्वतःच्या लोकल एक्झिक्यूशनची खात्री देत नाही. जर तुम्ही एजंटला OpenAI, Anthropic किंवा कोणत्याही होस्टेड API सारख्या बाह्य प्रोव्हायडरला कॉल करण्यासाठी कॉन्फिगर केले असेल, तर तुमचे प्रॉम्प्ट्स तुमच्या मशीनवरून बाहेर जातात. Studio गेट मॅनेज करते, परंतु डेटा तरीही नेटवर्कद्वारे प्रवास करतो.
नेहमी या सीमांचा मागोवा घ्या. पाईपलाईनचे कोणते भाग localhost वर राहतात आणि कोणते भाग दुसऱ्याच्या सर्व्हरवर जातात हे जाणून घ्या. जर तुमचा डेटा संवेदनशील असेल, तर टूल लेयरचा लोकल कंट्रोल पुरेसा नाही. मॉडेल इन्फरन्स कुठे होतो हे देखील तुम्हाला माहित असणे आवश्यक आहे. लोकल डॅशबोर्डच्या सोयीला रिमोट मॉडेलच्या वास्तव्याशी गोंधळू नका.
सूचना म्हणजे अधिकृतता (Authorization) नाही
एक धोकादायक शॉर्टकट म्हणजे प्रॉम्प्टिंगद्वारे एजंट सुरक्षित करण्याचा प्रयत्न करणे. मॉडेलला "कधीही डिलीट फंक्शन कॉल करू नकोस" असे सांगणे, हा सुरक्षा नियंत्रण (security control) नाही. ती केवळ एक सूचना आहे. मॉडेल्स सूचनांचा चुकीचा अर्थ लावू शकतात, जेलब्रेक प्रॉम्प्ट्सचा वापर करू शकतात किंवा साध्या तर्कामध्ये चुका करू शकतात. खरी सुरक्षा सॉफ्टवेअर बाउंड्रीवर असते.
नेमके कोणते फंक्शन्स कॉल करण्यायोग्य आहेत हे परिभाषित करण्यासाठी deco Studio मध्ये अलाऊलिस्ट वापरा. कंट्रोल प्लेनमध्ये सर्व्हर-साइड चेक वापरून त्या मर्यादा लागू करा. एजंटला त्याच्या क्षमतांचा शोध एखाद्या युजरला फाईल परमिशन्स शोधल्याप्रमाणे लागला पाहिजे: एका कडक मर्यादेला (hard limit) भिडल्यामुळे, केवळ एखादी मैत्रीपूर्ण नोट वाचून नाही. सुरक्षा ही आर्किटेक्चरमध्ये असावी, नैसर्गिक भाषेत नाही.
लहान सुरुवात करा, शंका घेण्यास तयार राहा
तुमचा कंट्रोल प्लेन एकेका टप्प्याने तयार करा. एक MCP सर्व्हर. एक एक्सपोज्ड फंक्शन. एक सिंथेटिक टास्क. एजंट जिथे यशस्वी व्हायला हवा तिथे यशस्वी होतोय आणि जिथे अपयशी व्हायला हवा तिथे अपयशी ठरतोय याची खात्री करा. ट्रेस (trace) वाचा. टोकन काउंट्स तपासा. त्यानंतर पुढचे टूल जोडा.
नियंत्रण म्हणजे तुम्ही चालू किंवा बंद करू शकणारा एखादा स्विच नाही. ते सीमांवर विश्वास ठेवण्यापूर्वी त्या सिद्ध करण्याची एक सवय आहे. deco Studio तुम्हाला ती सवय सरावण्यासाठी लोकल प्लेन देते. स्वायत्त एजंट्सच्या समूहाला (swarm) एक व्यवस्थापित, निरीक्षणक्षम आणि मर्यादित प्रणालीमध्ये रूपांतरित करण्यासाठी याचा वापर करा.
स्रोत: Controlling AI Agents in deco Studio: Tools, Permissions, and Cost
ऐच्छिक शिक्षण समुदाय: टेलिग्रामवरील GyaanSetu AI