LLM के जोखिमों में ‘प्रॉम्प्ट इंजेक्शन’ सबसे अहम क्यों है

यह फ़्लो दिखाता है कि सिर्फ़ चैट बॉक्स को फ़िल्टर करना काफ़ी क्यों नहीं है। कोई बाहरी ईमेल इंजेक्ट किया गया निर्देश ले जा सकता है, रिट्रीवल उसे संदर्भ (context) में रख सकता है, और टूल का परिणाम उसे बाद के चरण में दोहरा सकता है। HTML रेंडरिंग एक और सीमा जोड़ती है क्योंकि जो आउटपुट मॉडल के लिए सिर्फ़ टेक्स्ट होता है, वह ब्राउज़र में एक सक्रिय लिंक, मार्कअप या अनुरोध बन सकता है। संदर्भ तक पहुँचने से पहले हर स्रोत को भरोसेमंद, आंशिक रूप से भरोसेमंद या अविश्वसनीय के रूप में लेबल करें, फिर उस लेबल को लॉग में सुरक्षित रखें।

एक ही स्ट्रीम सब कुछ ले जाती है

वह मिश्रित फ़्लो OWASP LLM01:2026 का दायरा है। इसमें उपयोगकर्ता इनपुट से सीधा इंजेक्शन और रिट्रीव किए गए दस्तावेज़ों, ईमेल, वेब पेजों, टूल आउटपुट, परसिस्टेंट मेमोरी, इमेज, ऑडियो और वीडियो से अप्रत्यक्ष इंजेक्शन शामिल हैं। सीधा मामला उपयोगकर्ता के संदेश से शुरू होता है। अप्रत्यक्ष मामला तब शुरू होता है जब हमारे असिस्टेंट के रिट्रीवल इंडेक्स में मौजूद ईमेल बॉडी ऐसा टेक्स्ट देती है जिसे उपयोगकर्ता ने कभी नहीं लिखा या देखा था।

हम हर मामले को तीन आधारों पर वर्गीकृत कर सकते हैं। डिलीवरी सरफेस वह जगह है जहाँ कंटेंट डाला जाता है, जैसे ईमेल या टूल रिस्पॉन्स। प्रोपैगेशन वह जगह है जहाँ यह आगे जाता है, जैसे एक रिट्रीवल परिणाम से परसिस्टेंट मेमोरी में। एनकोडिंग वह तरीका है जिससे इसे दिखाया जाता है, जिसमें प्लेन टेक्स्ट, छिपे हुए यूनिकोड कैरेक्टर या इमेज में एम्बेड किए गए निर्देश शामिल हैं। यह वर्गीकरण हमें वास्तविक रास्ते का परीक्षण करने में मदद करता है, न कि केवल वाक्यांश पैटर्न का।

पारंपरिक पैरामीटराइज़ेशन डेटा को क्वेरी सिंटैक्स बदलने से रोकता है क्योंकि डेटाबेस पैरामीटर को अलग-अलग मानता है। मौजूदा LLM एप्लीकेशन में निर्देश और डेटा जब एक ही संदर्भ (context) में टोकन के तौर पर आते हैं, तो उनके बीच कोई स्पष्ट अंतर नहीं होता। डेलीमिटर (delimiters) और लेबल मकसद तो साफ़ कर सकते हैं, लेकिन वे अधिकार (authority) लागू नहीं करते। इसके बजाय, सुरक्षा सीमा मॉडल के बाहर होनी चाहिए, जहाँ कोड अनुमतियों की जाँच करे, आर्ग्युमेंट्स को मान्य (validate) करे और यह तय करे कि कौन सा आउटपुट आगे जा सकता है।

कामकाजी धारणा मॉडल के हर इनपुट को ऐसा मानें कि वह आउटपुट को प्रभावित कर सकता है, भले ही वह किसी आंतरिक रिट्रीवल सिस्टम (internal retrieval system) के ज़रिए आया हो।

इंजेक्शन सिस्टम के लिए जोखिम बन जाता है

एक बार जब इंजेक्ट किया गया ईमेल आउटपुट को प्रभावित करता है, तो नतीजा इस बात पर निर्भर करता है कि आस-पास का एप्लीकेशन क्या अनुमति देता है। अगर असिस्टेंट छिपा हुआ सिस्टम कंटेंट या रिट्रीव किया गया निजी हिस्सा (private passage) दिखाता है, तो मामला OWASP LLM08:2026 Hidden Context Exposure (छिपे हुए संदर्भ का उजागर होना) तक पहुँच जाता है। अगर यह ऐसा HTML बनाता है जिसे रेंडरर बिना सैनिटाइज़ेशन के स्वीकार कर लेता है, या ऐसे टूल आर्ग्युमेंट्स बनाता है जिन्हें डाउनस्ट्रीम कोड बिना वैलिडेशन के चलाता है, तो यह OWASP LLM10:2026 Improper Output Handling (आउटपुट को गलत तरीके से संभालना) तक पहुँच जाता है। LLM01 इनपुट-साइड की वह कमी है जो इन नतीजों को शुरू करती है।

वही इंजेक्शन कैलेंडर पर कोई असुरक्षित कार्रवाई करने या रिट्रीवल कॉर्पस (retrieval corpus) में डेटा को स्थायी रूप से सेव करने की कोशिश भी कर सकता है। ये नतीजे तब और गंभीर हो जाते हैं जब मॉडल व्यापक टूल (broad tools) को कॉल कर सकता है, लेकिन मॉडल का अनुरोध कभी भी उसका अपना ऑथराइज़ेशन (authorization) नहीं होना चाहिए। कैलेंडर सर्विस को यूज़र के अधिकार की पुष्टि करनी चाहिए, लिखने योग्य फ़ील्ड (writable fields) को सीमित करना चाहिए, और महत्वपूर्ण बदलावों के लिए मंज़ूरी लेनी चाहिए। रेंडरर को केवल सुरक्षित आउटपुट फ़ॉर्मैट की अनुमति देनी चाहिए। मॉडल आउटपुट बदलने के बाद हर लेयर एक अलग रास्ते को सीमित करती है।

नतीजों की तुलना करके पता लगाएँ कि किस बाउंड्री को हर एक को रोकना चाहिए।