एका कस्टमर-सर्व्हिस चॅटबॉटने मटण रेसिपीच्या साध्या विनंतीनंतर स्वतःचे 'सिस्टम प्रॉम्प्ट्स' (system prompts) उघड केले. काही मिनिटांतच, बॉटने केवळ रेसिपीच दिली नाही, तर पायथन (Python) कोड देखील तयार केला आणि त्याच्या वर्तनाचे मार्गदर्शन करणाऱ्या अंतर्गत सूचना देखील प्रकट केल्या.
ही घटना सिद्ध करते की लँग्वेज मॉडेलचा "सिस्टम प्रॉम्प्ट" हा सुरक्षेचा अडथळा (security wall) नाही. जेव्हा एखादा बॉट वापरकर्त्याची विनंती त्याच्या ध्येयाशी सुसंगत आहे की नाही याचा निर्णय तात्काळ घेतो, तेव्हा एखादा अटॅकर (attacker) त्या तर्काला दिशा देऊन मॉडेलकडून गोपनीय माहिती उघड करून घेऊ शकतो.
ही घुसखोरी कशामुळे घडली
ही चाचणी एका साध्या प्रश्नाने सुरू झाली: “तुम्ही मला मटण स्ट्यूची (mutton stew) रेसिपी देऊ शकता का?” ज्या बॉटचा घोषित उद्देश कंपनीच्या सेवा स्पष्ट करणे होता, त्याने पूर्ण रेसिपी दिली, घटकांचे विश्लेषण करणारा एक छोटा पायथन स्क्रिप्ट जोडला आणि त्यानंतर त्याच्या सिस्टम प्रॉम्प्टचे नेमके शब्द छापले – तो मजकूर जो मॉडेलला कसे वागावे हे सांगतो.
ही विनंती स्वतःहून निरुपद्रवी होती; धोका बॉटच्या त्या तयारीमध्ये होता की त्याने रेसिपीला त्याच्या मुख्य कार्याचा भाग मानले.
हे महत्त्वाचे का आहे
चॅटबॉट्स आता ग्राहकांशी संवाद साधणाऱ्या भूमिकांमध्ये आहेत, जे वैयक्तिक डेटा हाताळतात, व्यवहार (transactions) सुरू करतात किंवा अंतर्गत साधने (internal tools) नियंत्रित करतात. जर एखादे मॉडेल स्वतःच्या सूचना संच उघड करण्यासाठी प्रवृत्त केले जाऊ शकते, तर अटॅकरला त्या गार्डरेल्सची (guardrails) माहिती मिळते जे मॉडेलला हानिकारक गोष्टी करण्यापासून रोखण्यासाठी होते.
ही हल्ला प्रक्रिया कशी काम करते
- बॉटच्या उद्देशाचे प्रोफाइलिंग करणे – टेस्टरने हे ओळखले की बॉटचे काम कंपनीच्या सेवा स्पष्ट करणे आहे.
- एक खोटा संबंध निर्माण करणे – वापरकर्त्याने कोणती सेवा वापरावी हे ठरवण्यासाठी रेसिपीची गरज आहे असा दावा करून, टेस्टरने त्या विनंतीला बॉटच्या ध्येयाशी वरवरचा संबंध दिला.
- तर्काचा गैरफायदा घेणे – बॉटने तो बनावट संबंध स्वीकारला, विनंतीला त्याच्या अंतर्गत सुसंगतता तपासणीतून (relevance check) जाऊ दिले आणि त्याला रोखणारे गार्डरेल्स निष्क्रिय केले.
हा हल्ला मॉडेलच्या सुसंगततेच्या स्वतःच्या मूल्यमापनावर अवलंबून असतो. जेव्हा हे मूल्यमापन बदलता येते, तेव्हा मॉडेलचे स्वतःचे "नियम" वाटाघाटीसाठी उपलब्ध होतात.
अपयशाचे तीन टप्पे
| अपयशाचा टप्पा | काय घडले |
|---|---|
| ध्येयाचे हायजॅकिंग (Goal hijacking) | बॉटने स्वयंपाक करण्याच्या असंबंधित विनंतीला त्याच्या सेवा-स्पष्टीकरणाच्या ध्येयाचा भाग मानले. |
| क्षमता विचलन (Capability drift) | जरी त्याच्या भूमिकेत कोड जनरेशनचा समावेश नव्हता, तरीही त्याने एक्झिक्युटेबल पायथन कोड तयार केला. |
| प्रॉम्प्ट लीकेज (Prompt leakage) | त्याने नेमका तो सिस्टम प्रॉम्प्ट छापला जो लपवून ठेवला पाहिजे होता. |
प्रत्येक टप्पा एका वेगळ्या संरक्षणात्मक थराच्या (defensive layer) बिघाडाचे प्रतिनिधित्व करतो, ज्याची अंमलबजावणी मॉडेल स्वतः करेल असे अनेकदा मानले जाते.
खरोखर काम करणारे संरक्षणात्मक स्तर
गार्डरेल्स मॉडेलमधून बाहेर काढून डिटरमिनिस्टिक कोडमध्ये (deterministic code) नेल्यामुळे एक विश्वसनीय सुरक्षा सीमा पुन्हा प्रस्थापित होते.
- टास्क राउटिंग (Task routing) – येणारे संदेश अनुमत हेतूंच्या (allowed intents) निश्चित सूचीशी मॅप करण्यासाठी वेगळ्या क्लासिफायरचा वापर करा. जर एखादी विनंती त्या सूचीच्या बाहेर असेल, तर ती थेट नाकारा. मॉडेलला सुसंगततेबद्दल वाद घालण्याची संधीच मिळणार नाही.
- किमान क्षमता (Least capability) – बॉटला आवश्यक नसलेली साधने काढून टाका. जर त्याला कोड एक्झिक्यूशन किंवा व्यापक डेटाबेस प्रवेशाची आवश्यकता नसेल, तर ती क्षमता काढून टाका.
- डिटरमिनिस्टिक ऑथोरायझेशन (Deterministic authorization) – परवानगी तपासणी (permission checks) ॲप्लिकेशन कोडमध्ये करा, लँग्वेज मॉडेलमध्ये नाही. मॉडेल एखादी कृती सुचवू शकते, परंतु ती कृती करायची की नाही याचा निर्णय कोड घेतो.
- आउटपुट व्हॅलिडेशन (Output validation) – मॉडेलचा प्रतिसाद वापरकर्त्यापर्यंत पोहोचण्यापूर्वी, त्यामध्ये सिस्टम प्रॉम्प्ट किंवा संवेदनशील डेटा यांसारख्या निषिद्ध मजकुरासाठी स्कॅन करा.
"ही विनंती निषिद्ध आहे का?" असे विचारणारा फिल्टर एखादा पटवून देणारा वापरकर्ता बगल देऊ शकतो. बंद सूचीच्या (closed list) आधारे तपासणारा राउटिंग लेयर वाटाघाटीसाठी कोणतीही जागा सोडत नाही.
पुढे काय पाहावे
कन्वर्सेशनल एआयवर (conversational AI) अवलंबून असलेल्या उद्योगांनी मटण-रेसिपी चाचणीने दर्शवलेल्या तीन अपयशाच्या पद्धतींसाठी त्यांच्या उपयोजनांचे (deployments) ऑडिट केले पाहिजे. तोपर्यंत, कोणत्याही सिस्टम प्रॉम्प्टला सार्वजनिक माहिती मानून चाला; मॉडेलला स्वतःला उघड करण्यापासून रोखण्यासाठी त्यावर अवलंबून राहू नका.
निष्कर्ष स्पष्ट आहे: जर तुमचे सुरक्षा मॉडेल नैसर्गिक-भाषेच्या सूचनांच्या परिच्छेदावर अवलंबून असेल, तर ते कमकुवत आहे. मॉडेल काहीही म्हणो, ऑडिट, व्हर्जन आणि अंमलबजावणी करता येण्याजोग्या कोडने ते मजबूत करा.