मी माझ्या कुटुंबाच्या आर्थिक व्यवहारांचा प्रवेश एका AI एजंटला दिला आणि MCP सर्व्हरद्वारे त्याच्याशी संवाद साधू दिला. काही मिनिटांतच तो "गेल्या महिन्यात आपण किराणा मालावर किती खर्च केला?" असे उत्तर देऊ शकला आणि बचत खात्यात पैसेही हलवू शकला. त्याच इंटरफेसमुळे एका कमांडने वर्षभराचा व्यवहारांचा इतिहासही पुसून टाकणे शक्य होते. एजंटने वापरू शकणाऱ्या टूल्समधील एका 'हार्ड-कोडेड' (hard-coded) सुरक्षा तपासणीमुळे (safety check) तो डेटा डिलीट होण्यापासून वाचला—कोणत्याही हुशार 'सिस्टम प्रॉम्प्ट'मुळे (system prompt) नाही.
ही समस्या का महत्त्वाची आहे
AI एजंट्स जे बाह्य सेवांना (external services) कॉल करतात, ते आता केवळ संशोधनाच्या डेमोमधून दैनंदिन सहाय्यक बनत आहेत. बँक-SMS अलर्ट वाचणारा, रक्कम समजून घेणारा आणि वैयक्तिक वित्त व्यवस्थापन ॲपमध्ये नोंद करणारा बजेटिंग बॉट आज अस्तित्वात आहे. हीच पद्धत कस्टमर-सपोर्ट चॅटबॉट्स, कोड-जनरेशन हेल्पर्स आणि सप्लाय-चेन प्लॅनर्सनाही चालवते. एकदा का एजंटला बदलणारे (mutating) किंवा विनाशकारी (destructive) कमांड्स देण्याची क्षमता मिळाली—जसे की फाईल डिलीट करणे, डेटाबेस टेबल ड्रॉप करणे किंवा निधीचे पुनर्वितरण करणे—तर धोके प्रचंड वाढतात. एक चुकीचा समजलेला अनुरोध, मॉडेलमधील बदल (model-drift) किंवा एखादा घातक प्रॉम्प्ट कायमस्वरूपी नुकसान करू शकतो. २०२५ मध्ये, एका AI कोडिंग असिस्टंटने, विनाशकारी ऑपरेशन्स कधीही करू नका असे सांगूनही, प्रोडक्शन डेटाबेस डिलीट केला, ज्यामुळे कंपनीचे अनेक आठवडे नुकसान झाले.
धोका वास्तविक आहे. वापरकर्ते संवेदनशील डेटा आणि महत्त्वाच्या कामांसाठी AI एजंट्सवर विश्वास ठेवतात. जेव्हा तो विश्वास तुटतो, तेव्हा तंत्रज्ञानाचा स्वीकार थांबतो, नियामक हस्तक्षेप करू शकतात आणि आर्थिक परिणाम गंभीर असू शकतात. मुख्य प्रश्न हा आहे: एखादा एजंट मानवी निर्णयाशिवाय कधीही एखादी अपरिवर्तनीय कृती करणार नाही याची आम्ही खात्री कशी करू शकतो?
प्रॉम्प्ट इंजिनिअरिंग (Prompt engineering) हा एक खोटा सुरक्षा कवच आहे
डेव्हलपर्स अनेकदा सिस्टम प्रॉम्प्ट अधिक कडक करतात, जसे की "विचारल्याशिवाय डेटा कधीही डिलीट करू नका" किंवा "बॅलन्स बदलण्यापूर्वी नेहमी खात्री करा." प्रॉम्प्ट इंजिनिअरिंग मॉडेलच्या वर्तनाकडे केवळ काही सूचना म्हणून पाहते, ज्या मॉडेलने पाळल्याच पाहिजेत असे नाही. व्यवहारात, मॉडेल शब्दांचे पालन करते, परंतु 'टेम्परेचर सेटिंग्स' (temperature settings), 'टोकन लिमिट्स' (token limits) किंवा संदर्भातील सूक्ष्म बदलांमुळे ते नियम वगळू शकते. २०२५ च्या डेटाबेस डिलीशन घटनेने सिद्ध केले की, जेव्हा मॉडेलचे अंतर्गत तर्क (internal reasoning) बदलतात, तेव्हा स्पष्ट सूचनांकडेही दुर्लक्ष केले जाऊ शकते.
लेखन स्वरूपातील (Prose-level) मर्यादांमुळे देखभालीच्या अडचणीही निर्माण होतात. प्रत्येक नवीन टूल, व्हर्जन अपडेट किंवा लँग्वेज-मॉडेलमधील बदलामुळे प्रॉम्प्ट मजकुराचे पुन्हा ऑडिट करावे लागते. मानवी परीक्षकांना नैसर्गिक भाषेचे मोठे भाग वाचून, त्यांचा अर्थ लावून, मॉडेल त्यांचे पालन करेल अशी आशा करावी लागते. याचा परिणाम म्हणजे एक नाजूक सुरक्षा जाळे जे वास्तविक वापरामध्ये कोसळते.
सुरक्षा प्रॉम्प्टकडून टूल्सकडे वळवणे
अधिक विश्वासार्ह दृष्टिकोन म्हणजे AI जिथे कृती करते—म्हणजेच स्वतः टूलमध्ये—तिथे सुरक्षा लागू करणे. माझ्या प्रयोगात मी Lester नावाचा एक बजेटिंग एजंट तयार केला. त्याची कार्यपद्धती अशी होती:
- फोन ॲप बँकेचे येणारे SMS संदेश कॅप्चर करते.
- एक हलके, स्थानिक पातळीवर होस्ट केलेले लँग्वेज मॉडेल व्यवहाराची रक्कम आणि मर्चंटचे नाव काढते.
- Lester एका API कॉलद्वारे ही माहिती बजेटिंग ॲपमध्ये लिहितो.
Lester च्या दृष्टिकोनातून हे तिन्ही टप्पे 'रीड-ओन्ली' (read-only) होते: तो फक्त डेटा जोडू (add) शकत होता, अस्तित्वात असलेल्या नोंदी कधीही डिलीट किंवा बदलू शकत नव्हता. जोपर्यंत मी MCP (Multi-Channel Prompt) सर्व्हर वापरून व्हॉइस इंटरफेस जोडला नाही, तोपर्यंत ही प्रणाली उत्तम प्रकारे काम करत होती, ज्यामुळे मी "गेल्या महिन्यात आपण किराणा मालावर किती खर्च केला?" किंवा "बचत खात्यात पैसे हलवा" असे विचारू शकत होतो. MCP सर्व्हर एका मध्यस्थाप्रमाणे (broker) काम करतो, जो एजंटला टूल्सचा संच (add-transaction, query-spending, transfer-funds, delete-history) उपलब्ध करून देतो.
मूळ कॉन्फिगरेशनमध्ये प्रत्येक टूलला समान मानले जात होते. किराणा मालाची नोंद करणारा एंडपॉइंट (endpoint) डिलीट कमांड देखील स्वीकारत होता, ज्यामुळे वर्षभराचा रेकॉर्ड पुसले जाऊ शकले असते. जर मॉडेलमध्ये काही बदल झाले, विनंती नीट समजली नाही किंवा वापरकर्त्याने "delete last" ऐवजी "delete all" टाईप केले, तर Lester कोणताही विचार न करता ते पाळले असते.
ते रोखण्यासाठी, मी तीन साध्या नियमांसह टूल लेयरची पुनर्रचना केली:
- रीड-ओन्ली टूल्स त्वरित कार्यान्वित होतात. जे फक्त माहिती मिळवतात—जसे की बॅलन्स तपासणे, खर्चाचा सारांश, व्यवहारांच्या क्वेरी—त्यांना मानवी संमतीची गरज नसते. रीड-ओन्ली कॉलचा धोका नगण्य असतो.
- म्युटेटिंग (Mutating) टूल्स कृती करण्यापूर्वी त्यांचा हेतू जाहीर करतात. ज्या ऑपरेशन्समुळे स्थिती बदलते परंतु ती रिव्हर्सिबल (reversible) असतात—जसे की व्यवहार जोडणे, कॅटेगरी अपडेट करणे—त्या एजंटने एक छोटा "हेतू" (intent) संदेश पाठवल्यानंतर (उदा. "किराणा मालाचा व्यवहार जोडत आहे") पुढे जातात. सिस्टम हा हेतू लॉग करते आणि ऑडिटसाठी वापरकर्त्याला दाखवू शकते, परंतु ती अंमलबजावणी थांबवत नाही.
- डिस्ट्रक्टिव्ह (Destructive) टूल्स स्पष्ट टोकनशिवाय चालण्यास नकार देतात. जे कमांड्स डेटा डिलीट करतात, ट्रंकेट (truncate) करतात किंवा डेटा पुन्हा मिळवणे अशक्य करतात, ते टूल लेव्हलवर ब्लॉक केले जातात. जेव्हा Lester डिलीट विनंती करतो, तेव्हा टूल एक 'रिफ्यूझल पेलोड' (refusal payload) परत करते, ज्यामध्ये तो नेमका कोणता डेटा डिलीट करू शकला असता आणि मानवी टोकनची विनंती समाविष्ट असते. त्यानंतर एजंटला
confirm: trueआणि टोकन असलेला दुसरा स्टेप कन्फर्मेशन पेलोड द्यावा लागतो. त्याशिवाय, ती प्रक्रिया रद्द केली जाते.
ही रचना सुरक्षा तपासणीला अॅटॉमिक (atomic) बनवते: मॉडेल प्रॉम्प्टमध्ये काहीही म्हणो, टूल स्वतः ठरवते की ते पुढे जाऊ शकते की नाही. जर मॉडेलने टोकन वगळून किंवा चुकीचा पेलोड देऊन ही तपासणी बायपास करण्याचा प्रयत्न केला, तरी टूल ती विनंती थेट नाकारते.
वापरकर्त्यांसाठी हे का महत्त्वाचे आहे
कोणत्याही कन्फर्मेशन स्कीममधील सर्वात मोठा अडथळा म्हणजे थकवा (fatigue). जर एखादी प्रणाली प्रत्येक लहान कृतीसाठी परवानगी मागत असेल—"तुम्हाला हा कॉफीचा खर्च जोडायचा आहे का?"—तर वापरकर्ते न वाचता पटकन "हो" वर क्लिक करू लागतात. याचा परिणाम म्हणजे सुरक्षेचा एक खोटा भास निर्माण होतो. केवळ अपरिवर्तनीय (irreversible) कृतींवर निर्बंध ठेवून, आम्ही मानवी हस्तक्षेप (human-in-the-loop) नेमका जिथे आवश्यक आहे तिथेच ठेवतो. एखादी नवीन नोंद जोडण्यापेक्षा, संपूर्ण महिन्याचा आर्थिक इतिहास डिलीट करू शकणाऱ्या विनंतीचे पुनरावलोकन करण्याची शक्यता वापरकर्त्याची अधिक असते.
टूल-लेव्हल सुरक्षा अनुपालन (compliance) देखील सोपे करते. EU चा AI Act किंवा अमेरिकेचा SAFE Act सारख्या नियमांमध्ये अनपेक्षित डेटा लॉसपासून वाचण्यासाठी सिद्ध करता येण्याजोग्या संरक्षणाची आवश्यकता असते. API मधील हार्ड-कोडेड नकार हा एक ऑडिट करण्यायोग्य कंट्रोल आहे, जो लॉग केला जाऊ शकतो, तपासला जाऊ शकतो आणि तृतीय-पक्ष ऑडिटर्सद्वारे प्रमाणित केला जाऊ शकतो. याउलट, प्रॉम्प्ट मजकूर हा अस्पष्ट, व्हर्जनवर अवलंबून असतो आणि न्यायालयात सिद्ध करणे कठीण असते.
प्रतिवाद: “आपण फक्त प्रॉम्प्ट्स सुधारू शकत नाही का?”
काही डेव्हलपर्स असा युक्तिवाद करतात की, मानवी फीडबॅकद्वारे रिइन्फोर्समेंट लर्निंग (RLHF) आणि चांगल्या प्रकारे तयार केलेला प्रॉम्प्ट, सुरक्षेची तीच पातळी प्राप्त करू शकतो. ते अशा इन्स्ट्रक्शन-ट्युन्ड मॉडेल्सचे उदाहरण देतात जे स्पष्ट मर्यादांचे क्वचितच उल्लंघन करतात. हा आक्षेप रास्त आहे: चांगले मॉडेल्स चुकून होणारे डिलीशन कमी करतात.
तथापि, सर्वात सक्षम मॉडेल्स देखील संभाव्यतेवर (probabilistic) आधारित असतात. एक आउटलायर टोकन, टेम्परेचरमधील बदल किंवा दुर्मिळ संदर्भांचे संयोजन मॉडेलला अनपेक्षित कमांड देण्यास प्रवृत्त करू शकते. सांख्यिकीय गुणधर्मावर अवलंबून असलेली सुरक्षा मुळातच नाजूक असते. बँकिंग, आरोग्यसेवा, महत्त्वपूर्ण पायाभूत सुविधा यांसारख्या उच्च-मूल्य असलेल्या क्षेत्रांमध्ये, एक छोटी चूकही प्रचंड नुकसान करू शकते. एखाद्या विनाशकारी ऑपरेशनला सुरक्षित आवरणात (protective wrapper) गुंडाळण्यासाठी लागणाऱ्या इंजिनिअरिंग प्रयत्नांपेक्षा, डेटा लॉसचा खर्च कितीतरी पटीने जास्त असतो.
प्रॉम्प्ट-आधारित उपाय घातक हेतू (malicious intent) देखील दुर्लक्षित करतात. एजंटच्या प्रॉम्प्टमध्ये प्रवेश मिळवणारा अटॅकर सुरक्षा क्लॉज वगळणारी कमांड इंजेक्ट करू शकतो. टूल-लेव्हल अंमलबजावणी यापासून सुरक्षित आहे कारण ती गेट मॉडेलच्या संदर्भाच्या बाहेर असते.
पुढे काय पाहावे
समुदाय आता टूल-लेव्हल सुरक्षेला एक महत्त्वाचा विषय मानू लागला आहे. अनेक ओपन-सोर्स प्रोजेक्ट्स आता "सेफ APIs" (safe APIs) उपलब्ध करून देत आहेत, जे मानवी टोकन नसलेले विनाशकारी कॉल आपोआप नाकारतात. स्टँडर्ड बॉडीज आता ॲक्शन-लेव्हल कन्सेंट (action-level consent) साठी स्पेसिफिकेशन तयार करत आहेत