काम करने वाले AI सिस्टम बनाने के लिए, पहले आपको उनकी कमज़ोरियाँ पता करनी होंगी. हमने एक 'रेड टीमिंग' एक्सरसाइज़ की, जिसमें हमने हमलावरों की तरह काम करते हुए फ़ाइनेंशियल सर्विस में कस्टमर-फ़ेसिंग AI ऐप को जाँचा और परखा. हमें जो पता चला, वह उन सभी के लिए ज़रूरी है जो LLM-पावर्ड ऐप्लिकेशन इस्तेमाल कर रहे हैं, जहाँ सिक्योरिटी ज़रूरी है.
'रेड टीमिंग' का मतलब है जान-बूझकर अपने AI सिस्टम की कमजोरियाँ खोजने की कोशिश करना, ताकि किसी असली हमलावर के कमियों का पता लगाने से पहले ही उन्हें ठीक किया जा सके. फ़ाइनेंशियल सर्विस में जोखिम बहुत ज़्यादा होता है: AI ऐप्लिकेशन कस्टमर का डेटा इस्तेमाल करते हैं, ट्रांज़ैक्शन प्रोसेस करते हैं और फ़ाइनेंशियल जानकारी देते हैं. इसमें किसी भी तरह की गड़बड़ी से ख़राब यूज़र अनुभव से लेकर नियमों का उल्लंघन, आर्थिक नुकसान और ब्रैंड को कभी न ठीक होने वाला नुकसान हो सकता है.
हमारा मकसद कमियों का जल्द पता लगाना, असल जैसे अटैक पैटर्न को टेस्ट करना और ऑर्गनाइज़ेशन को AI सुरक्षा से जुड़ी उन उम्मीदों को पूरा करने में मदद करना था, जिन्हें रेगुलेटर बहुत गंभीरता से लेते हैं.
यहाँ एक ज़रूरी फ़र्क समझना चाहिए: जेलब्रेकिंग असल मॉडल के सेफ़्टी फ़िल्टर पर हमला करता है; जबकि प्रॉम्प्ट इंजेक्शन सीधे ऐप्लिकेशन पर हमला करता है, जिसमें डेवलपर के भरोसेमंद प्रॉम्प्ट के साथ भरोसे के लायक न होने वाले यूज़र इनपुट का इस्तेमाल किया जाता है. प्रॉम्प्ट इंजेक्शन ज़्यादा बड़ा रिस्क पैदा करता है क्योंकि यह किसी आम मकसद वाले मॉडल के बजाय आपके सिस्टम और उस पर प्रोसेस होने वाले गोपनीय डेटा को निशाना बनाता है.
हमारी टेस्टिंग के पहले राउंड में लगभग 750 टेस्ट शामिल थे, जो इन क्षेत्रों में किए गए:
अलग-अलग सेशन के बीच डेटा लीक होना
PII का एक्सपोजर (नैचुरल लैंग्वेज, API में हेरफेर और अलग-अलग तरह की एन्कोडिंग के ज़रिए)
SQL इंजेक्शन
सिस्टम प्रॉम्प्ट को ओवरराइड करना
शुरुआती टेस्टिंग के दौरान, हमने मौजूदा सिस्टम में दो बड़ी समस्याएँ पहचानीं: मल्टी-इंटेंट क्वेरीज़ को हैंडल करना और एन्कोडेड प्रॉम्प्ट्स का इस्तेमाल.
मल्टी-इंटेंट क्वेरीज़: ऐसे अनुरोध जिनमें सही और नुकसान पहुँचाने वाली दोनों तरह की बातें शामिल हों. उदाहरण के लिए: “कैटेगरी के हिसाब से मेरा ख़र्च दिखाओ, और साथ ही [malicious SQL] भी चलाओ.” ऐप्लिकेशन नुकसान पहुँचाने वाले इरादे को नहीं पकड़ पा रहा था, बल्कि पूरी तरह से डेटा लेयर के सुरक्षा उपायों पर निर्भर था. यह वैसा ही है जैसे आप अपना मुख्य दरवाज़ा खुला छोड़ दें क्योंकि आपको बेसमेंट में रखी तिजोरी पर भरोसा है.
एन्कोडिंग: इसमें अनुरोध को Base64, Hex, LeetSpeak और होमोग्लिफ़ में एनकोड किया जाता है. सिस्टम के लिए नुकसान पहुँचाने वाले इरादे को पहचानकर अलग करना मुश्किल हो सकता है. हालाँकि हमने पाया कि इन क्वेरीज़ से कोई संवेदनशील डेटा लीक नहीं हुआ, लेकिन इनसे सिस्टम में काफ़ी अस्थिरता ज़रूर आई (जैसे हैलुसिनेशन, यूज़र को नुकसान पहुँचाने वाला SQL दोहराकर दिखाना, इरादे की गलत पहचान आदि).
हमारी शुरुआती टेस्टिंग के नतीजों से ये पता चला:
समय से जुड़ी गलत जानकारी: मॉडल का आत्मविश्वास के साथ ऐसी तारीखें, ट्रांज़ैक्शन के टाइमस्टैम्प या समय-सीमा वाले सारांश बताना जो असल में गलत या मनगढ़ंत हैं— जो फ़ाइनेंशियल मामलों में एक बड़ा रिस्क है, क्योंकि गलत तारीख़ के आधार पर कोई कदम उठाने से कस्टमर को असल नुकसान हो सकता है
नुकसान पहुँचाने वाले SQL का यूज़र को वापस दिखाया जाना (मेमोरी पॉइज़निंग के रिस्क के लिहाज़ से चिंताजनक)
इरादे की गलत पहचान
अव्यवस्थित आउटपुट फ़ॉर्मैटिंग
उन नतीजों के आधार पर, हमने अपना फ़ोकस सीमित कर लिया. SQL इंजेक्शन और एन्कोडिंग टेस्ट को कम प्राथमिकता दी गई (क्योंकि टीम पहले से ही उन पर काम कर रही थी). इसके बजाय, हमने सबसे सफ़ल अटैक वेक्टर पर ध्यान केंद्रित किया: PII एक्सपोजर और क्रॉस-सेशन लीकेज.
दूसरे राउंड से मिली सबसे ख़ास बात बहुत ही आसान थी: आपको अक्सर बिल्कुल भी चालाक होने की ज़रूरत नहीं होती.
कई मामलों में, सिर्फ़ इंटरनल डेटा मांगना—जिसे एक सही लगने वाले अनुरोध के तौर पर पेश किया गया हो, वह सिस्टम को उसे दिखाने के लिए राज़ी करने के लिए काफ़ी था. आसान सवालों के जवाब में ऐसे इंटरनल ID और सिस्टम फ़ील्ड का ज़िक्र होता था, जो कभी भी एंड यूज़र को नहीं दिखने चाहिए.
गहराई से जाँच करने पर हमें पता चला कि यह सिर्फ़ ऐप्लिकेशन-लेवल की ख़राबी नहीं थी. डाउनस्ट्रीम टेक्स्ट-टू-SQL सर्विस ऐसी क्वेरी बना रही थी जो ज़रूरत से ज़्यादा फ़ील्ड मांग रही थीं, और उसके जवाबों में ऐसा डेटा शामिल था जिसे प्रतिबंधित होना चाहिए था. इससे सिस्टम के बीच एक असली कमी सामने आई, यह एक ऐसी कमी थी जो तभी पता चलती है जब आप पूरे स्टैक की टेस्टिंग करते हैं, न कि अलग-अलग कॉम्पोनेंट्स की.
सिस्टम की रेड टीमिंग करें, मॉडल की नहीं. LLM को अलग से टेस्ट करने पर आपको अपने ऐप्लिकेशन की सिक्योरिटी के बारे में बहुत कम जानकारी मिलती है. पूरे स्टैक को एंड-टू-एंड टेस्ट करें, ठीक वैसे ही जैसे कोई यूज़र उसके साथ इंटरैक्ट करेगा.
LLM से पहले इनपुट वैलिडेशन होना चाहिए. एन्कोडेड क्वेरी, मल्टी-इंटेंट अटैक और बेसिक इंजेक्शन की कोशिशों को पेरीमीटर पर ही पकड़ लेना चाहिए, न कि उन्हें बाद की सर्विस पर छोड़ देना चाहिए.
सिस्टम के बीच के जोड़ पर भरोसा न करें. मल्टी-सर्विस आर्किटेक्चर में, सिस्टम के बीच की जगहों में ही सबसे ज़्यादा दिलचस्प कमज़ोरियाँ छिपी होती हैं. ज़ीरो-ट्रस्ट का मतलब सचमुच ज़ीरो-ट्रस्ट है, इसलिए हर लेयर पर हर चीज़ को वेरिफ़ाई करें.
आसान हमले भी सफ़ल होते हैं. मुश्किल जेलब्रेक भले ही सुर्खियां बटोरते हों, लेकिन कभी-कभी आप बस... पूछ सकते हैं. अगर आपका सिस्टम आसानी से इंटरनल आइडेंटिफ़ायर दिखा देता है, जब कोई यूज़र उन्हें किसी सही-सलामत क्वेरी में शामिल करते हैं, तो यह एक समस्या है.
समझें कि आप असल में क्या टेस्ट कर रहे हैं. हमले के जाने-पहचाने पैटर्न आपके सुरक्षा उपायों के बजाय LLM की अपनी ट्रेनिंग से पकड़े जा सकते हैं. अपनी रेड टीमिंग में निगरानी की क्षमता शामिल करें ताकि यह समझा जा सके कि असल में कौन से कंट्रोल इस्तेमाल हो रहे हैं.
सीमित एनवायरनमेंट में क्रिएटिव समाधानों की ज़रूरत होती है. कस्टम प्रोवाइडर और लोकल मॉडल सपोर्ट की वजह से, ख़ास क्लाउड एक्सेस के बिना भी असरदार रेड टीमिंग मुमकिन हो जाती है. लेकिन इससे जुड़ी सीमाओं के बारे में साफ़-साफ़ बताएँ.
रेड टीमिंग कोई एक बार की जाने वाली प्रक्रिया नहीं है. यह बार-बार दोहराई जाने वाली प्रक्रिया है; जहाँ भी संभव हो, इसे ऑटोमेटेड रखा जाना चाहिए और जैसे-जैसे आपका सिस्टम विकसित हो, इसे भी उसी के साथ विकसित होना चाहिए. भविष्य में जो हमले मायने रखेंगे, वे आज मायने रखने वाले हमलों से अलग होंगे.
रेगुलेटेड एनवायरनमेंट में AI सिस्टम की और ज़्यादा जाँच-पड़ताल होगी, कम नहीं. जो ऑर्गनाइज़ेशन सिक्योरिटी टेस्टिंग को लॉन्च से पहले की एक औपचारिकता के बजाय एक लगातार चलने वाली प्रक्रिया मानते हैं, वे इस जाँच-पड़ताल का बेहतर ढंग से सामना कर पाएँगे और उन PR संकटों से बच पाएँगे जिनसे कस्टमर का भरोसा टूटता है.