तुमचा AI-चालित असिस्टंट ९९% वेळा त्याच्या सूचनांचे पालन करतो, परंतु उरलेला १% भाग तिथेच हल्लेखोरांसाठी संधी निर्माण करतो. एक तयार केलेला (crafted) प्रॉम्प्ट देऊन, एक दुर्भावनापूर्ण वापरकर्ता मॉडेलला अशी फंक्शन्स वापरण्यास भाग पाडू शकतो जी त्याला वापरता येऊ नयेत, ज्यामुळे डेटा चोरीला जाऊ शकतो किंवा विशेषाधिकार प्राप्त कृती केल्या जाऊ शकतात. याचे निराकरण अधिक नम्र शब्दांत बोलण्यात नाही—तर या त्रुटीकडे अधिकृततेची (authorization) समस्या म्हणून पाहणे आणि मॉडेलच्या आवाजाबाहेर धोकादायक टूल्स काढून टाकणे यात आहे.
प्रॉम्प्ट इंजेक्शन ही केवळ शब्दांची समस्या का नाही
डेव्हलपर्स अनेकदा सर्व कॅपिटल अक्षरातील चेतावणी (all-caps warnings), क्रमांकाचे नियम किंवा “admin फंक्शन्स कॉल करू नका” अशा अटी वापरून एजंट्स अधिक सुरक्षित करण्याचा प्रयत्न करतात. या संरक्षणांमुळे असे गृहीत धरले जाते की मॉडेल “don’t do X” असे म्हणणाऱ्या वाक्याचे पालन करेल. प्रत्यक्षात, विनंतीची पुनर्रचना करून, वेगळी भूमिका (role-playing) साकारून किंवा फक्त अतिरिक्त संदर्भ जोडून मॉडेलला सूचना दुर्लक्षित करण्यास प्रवृत्त केले जाऊ शकते. इंग्रजी भाषेची सीमा लवचिक असते; हल्लेखोराचा प्रॉम्प्ट अमर्याद असतो आणि तो तपासण्यासाठी काहीही खर्च येत नाही.
खरी असुरक्षितता एजंटला मिळणाऱ्या टूल्सच्या यादीमध्ये असते. जेव्हा प्रॉम्प्ट स्कीमामध्ये असे फंक्शन असते जे ॲडमिन अधिकार देते, तेव्हा मॉडेलकडे त्या शक्तीचा नकाशा असतो. जरी प्रॉम्प्टमध्ये “ग्राहकांसाठी याचा वापर करू नका” असे म्हटले असले, तरी मॉडेलला ते फंक्शन कॉल करण्यासाठी अजूनही पटवून दिले जाऊ शकते कारण ते त्याच्या एक्झिक्यूशन एन्व्हायरमेंटमध्ये अस्तित्वात असते. त्यामुळे ही समस्या अधिकृततेतील त्रुटी (authorization gap) आहे: सिस्टीम अशा कॉल करणाऱ्याला विशेषाधिकार प्राप्त क्षमता उघड्यावर दाखवत आहे ज्याला त्यांचे अधिकार नाहीत.
एक्सपोजर मर्यादित करून एजंट्स सुरक्षित करणे
ही त्रुटी दूर करण्याचा सर्वात सोपा मार्ग म्हणजे मॉडेलला अशा टूल्सचा प्रवेश देणे थांबवणे ज्यांचा वापर करण्यासाठी ते अधिकृत नाही. टूल्सची यादी एखाद्या API की प्रमाणे समजा: जर की (key) उपलब्ध नसेल, तर कॉल होऊ शकत नाही. सध्याच्या संदर्भात (context) नसलेले फंक्शन कोणत्याही चतुर शब्दांनी बोलावता येत नाही.
चुकीची पद्धत
Prompt: “You are an assistant. Do not use the adminDeleteUser function for regular customers.”
मॉडेलला त्याच्या टूलबॉक्समध्ये अजूनही adminDeleteUser दिसते आणि त्याला ते वापरण्यास फसवले जाऊ शकते.
योग्य पद्धत
Prompt schema for a regular customer: { “functions”: [ “searchCatalog”, “placeOrder” ] }
adminDeleteUser कधीही दिसत नाही, त्यामुळे मॉडेलकडे ते कॉल करण्याचा कोणताही मार्ग नसतो.
डेव्हलपर्ससाठी तीन व्यावहारिक नियम
- प्रत्येक विनंतीनुसार टूल्सची यादी तयार करा – ऑथेंटिकेटेड कॉल करणाऱ्याच्या परवानग्यांवर आधारित फंक्शन कॅटलॉग डायनॅमिकली तयार करा. ग्राहकाला फक्त त्यांना आवश्यक असलेली फंक्शन्स दिसतील; ॲडमिनला पूर्ण संच दिसेल.
- Fail closed – जर वापरकर्त्याची ओळख पटवता आली नाही, तर सर्व टूल्स उपलब्ध आहेत असे सामान्य उत्तर देण्याऐवजी रिकामी यादी परत करा. यामुळे अनधिकृत विनंतीला कधीही अनपेक्षित अधिकार मिळणार नाहीत याची खात्री मिळते.
- Shared state टाळा – टूल्सच्या व्याख्या कॅश (cache) करताना, वापरकर्त्याशी संबंधित डेटा कधीही शेअर केलेल्या ऑब्जेक्टवर लिहू नका.
copy-on-writeकिंवा प्रति-सत्र (per-session) कॉपी वापरा जेणेकरून एका वापरकर्त्याच्या परवानग्या दुसऱ्याच्या विनंतीमध्ये मिसळणार नाहीत.
जर सामान्य वापरकर्त्याला दाखवलेला स्कीमा ॲडमिनला दाखवल्यासारखाच दिसत असेल, तर सुरक्षा सीमा अजूनही प्रॉम्प्ट टेक्स्टवरच अवलंबून आहे, आणि प्रॉम्प्ट्स हे विश्वसनीय सुरक्षा यंत्रणा नाहीत.
आम्ही इथपर्यंत कसे पोहोचलो
जेव्हा डेव्हलपर्सनी लार्ज लँग्वेज मॉडेल्सना (LLMs) अशा प्रोडक्शन वर्कफ्लोमध्ये जोडण्यास सुरुवात केली ज्यामध्ये मॉडेलला बाह्य API कॉल करणे, कोड चालवणे किंवा डेटाबेसमध्ये बदल करणे आवश्यक होते, तेव्हा प्रॉम्प्ट इंजेक्शनची समस्या समोर आली. मॉडेलचे “reasoning” एका प्रॉम्प्टद्वारे निर्देशित केले जाते ज्यामध्ये उपलब्ध टूल्सची यादी देखील समाविष्ट असते. सुरुवातीच्या प्रोटोटाइपमध्ये असे गृहीत धरले होते की मॉडेल “don’t delete records for non-admins” सारख्या नैसर्गिक भाषेतील नियमाचे पालन करेल. हल्लेखोरांनी लवकरच हे सिद्ध केले की काही अतिरिक्त वाक्यांमुळे ते नियम बायपास करता येतात, ज्यामुळे मॉडेलला तेवढेच डिलीट फंक्शन कॉल करण्यास प्रवृत्त केले जाऊ शकते.
समुदायाची पहिली प्रतिक्रिया प्रॉम्प्टची भाषा अधिक कडक करणे, “never do X” अशा अटी जोडणे किंवा संशयास्पद टोकन्स काढून टाकणारे regex फिल्टर्स वापरणे ही होती. या उपायांनी अपघाती गैरवापर कमी केला परंतु एखाद्या जिद्दी हल्लेखोराला थांबवू शकला नाही जो केवळ विनंतीची पुनर्रचना करू शकतो. मूळ कारण—अविश्वासू कॉल करणाऱ्याला विशेषाधिकार प्राप्त फंक्शन्स उघड्यावर दाखवणे—ते तसेच राहिले.
कोणाचा विजय, कोणाचा पराभव
जे एंटरप्राइजेस प्रति-विनंती टूल स्कोपिंग (per-request tool scoping) स्वीकारतात, त्यांना एक स्पष्ट आणि लागू करण्यायोग्य सीमा मिळते. त्यांचे एजंट्स मोठ्या प्रमाणावर तैनात केले जाऊ शकतात, कारण एखादा चुकीचा प्रॉम्प्ट ॲडमिन क्षमता अनलॉक करेल अशी भीती राहत नाही. कंप्लायन्स टीम्सना ऑडिट ट्रेलचे देखील महत्त्व वाटते: मॉडेलला पाठवलेल्या फंक्शन्सची यादी हा एक ठोस पुरावा आहे जो लॉग आणि रिव्ह्यू केला जाऊ शकतो.
जे डेव्हलपर्स केवळ प्रॉम्प्ट-आधारित संरक्षणावर अवलंबून राहतात, त्यांना सतत बदलत्या आव्हानांचा सामना करावा लागतो. त्यांचे एजंट्स टेस्टिंगमध्ये कार्यान्वित वाटू शकतात परंतु प्रत्यक्ष वापरात ते धोक्यात येऊ शकतात, ज्यामुळे डेटा चोरी, अनधिकृत व्यवहार किंवा कंप्लायन्सचे उल्लंघन होऊ शकते. डेटा चोरीचा खर्च डायनॅमिक टूल लिस्ट तयार करण्याच्या प्रयत्नांपेक्षा कितीतरी पटीने जास्त असतो.
प्रतिवाद: “चांगले प्रॉम्प्ट्स पुरेसे आहेत”
काही लोकांचा असा युक्तिवाद आहे की पुरेशा इन्स्ट्रक्शन इंजिनीअरिंगद्वारे—लेअर्ड प्रॉम्प्ट्स, सिस्टम मेसेजेस आणि मानवी फीडबॅकपासून मिळणारे रिइन्फोर्समेंट लर्निंग (reinforcement learning from human feedback)—मॉडेलला “do not” अटींचे पालन करण्यास भाग पाडले जाऊ शकते. वास्तव असे आहे की लँग्वेज मॉडेल्स हे प्रोबॅबिलिस्टिक जनरेटर्स (probabilistic generators) आहेत; ते सर्वात संभाव्य पुढील शब्दाचा विचार करतात, कोणत्याही कडक सुरक्षा नियमाचा नाही. अगदी फाईन-ट्यून केलेल्या गार्डरेल्स असूनही, नवीन प्रकारची वाक्यरचना सहजपणे घुसून जाऊ शकते, विशेषतः जेव्हा अटॅकर शून्य खर्चात वारंवार प्रयत्न करू शकतो. गार्डरेल्स 'नॉईज' कमी करण्यासाठी उपयुक्त आहेत, परंतु ते संरक्षणाचे एकमेव साधन नसावे.
पुढे काय पाहावे
- टूल स्कोपिंगला (tool scoping) फर्स्ट-क्लास API म्हणून सादर करणारे फ्रेमवर्क्स – अशा नवीन लायब्ररीजची अपेक्षा करा ज्या तुम्हाला वापरकर्त्यानुसार क्षमता घोषित करण्याची आणि प्रॉम्प्ट तयार होण्यापूर्वी फंक्शनची यादी आपोआप कमी करण्याची (prune) सुविधा देतील.
- मानकीकृत “फंक्शन मॅनिफेस्ट्स” (function manifests) – उद्योग समूह असा JSON स्कीमा परिभाषित करू शकतात जो सार्वजनिक आणि विशेषाधिकार प्राप्त (privileged) फंक्शन्स वेगळे करतो, ज्यामुळे विनंती-विशिष्ट मॅनिफेस्ट्स तयार करणे सोपे होईल.
- रनटाइम एन्फोर्समेंट (Runtime enforcement) – काही प्लॅटफॉर्म्स सँडबॉक्स एक्झिक्यूशन (sandboxed execution) सोबत प्रयोग करत आहेत, जे कॉल करणाऱ्याच्या टोकनची तपासणी कॉल केल्या जाणाऱ्या फंक्शनशी करते, ज्यामुळे प्रॉम्प्ट स्कोपिंगच्या पलीकडे संरक्षणाचे दुसरे स्तर जोडले जातात.
निष्कर्ष स्पष्ट आहे: प्रॉम्प्ट इंजेक्शनला (prompt injection) अधिकारातील त्रुटी (authorization flaw) म्हणून पहा. मॉडेलच्या टूलबॉक्समधून अनधिकृत साधने काढून टाकून, तुम्ही त्या अटॅक सरफेसला (attack surface) नष्ट करू शकता ज्याचा फायदा चाणाक्षपणे तयार केलेल्या प्रॉम्प्टद्वारे घेण्याचा प्रयत्न केला जातो. प्रॉम्प्ट्स वर्तनावर मार्गदर्शन करू शकतात; परंतु ते योग्य ॲक्सेस कंट्रोलची (access control) जागा घेऊ शकत नाहीत.