LLM सुरक्षा क्या है? OWASP Top 10 सुरक्षा जोखिमों को कैसे कम करें

किसी AI को धोखे से हमलावर के निर्देशों को कमांड मानने पर मजबूर करने वाला हमला—प्रॉम्प्ट इंजेक्शन—2023 से हर संस्करण में LLM ऐप्लिकेशन के लिए OWASP Top 10 में नंबर 1 पर रहा है।

AI सुरक्षा के क्षेत्र में यह सूची आम सहमति के सबसे करीब है। यह प्रोजेक्ट सुरक्षा पेशेवरों के एक छोटे समूह के रूप में शुरू हुआ था और अब इसमें 18 से ज़्यादा देशों के 600 से अधिक योगदानकर्ता विशेषज्ञ शामिल हैं।

हम एक AI कंपनी हैं और यह गाइड प्रकाशित कर रहे हैं कि AI को बातों में फँसाकर उससे कुछ भी कैसे करवाया जा सकता है, इसलिए हम यह दिखावा नहीं करेंगे कि यह समस्या हल हो चुकी है। OWASP प्रोजेक्ट के सह-प्रमुख Wilson ने मौजूदा सुरक्षा उपायों के बारे में साफ़ शब्दों में कहा: "...सच कहूँ तो, मुझे नहीं लगता कि हम 99% पर हैं।"

2026 संस्करण की शुरुआत भी इसी बात से होती है। प्रोजेक्ट प्रमुख हमसे कहते हैं कि "ऐसा मॉडल बनाने की कोशिश बंद करें जिसे धोखा न दिया जा सके" और आसपास के सिस्टम को इस तरह डिज़ाइन करें कि धोखा खाया हुआ मॉडल कुछ भी महत्वपूर्ण न बिगाड़ सके।

OWASP की 2026 सूची के सभी 10 जोखिमों पर हम यही रुख अपना रहे हैं।

LLM सुरक्षा का क्या मतलब है?

LLM सुरक्षा का मतलब है AI मॉडल और उनका इस्तेमाल करने वाले ऐप्लिकेशन को हमलों और दुरुपयोग से बचाना। मॉडल जितनी चीज़ों से जुड़ा होता है, जोखिम उतना ही बढ़ता है: वे फ़ाइलें और डेटा जिन्हें वह पढ़ सकता है, और वे टूल जिनका वह इस्तेमाल कर सकता है, जैसे ईमेल, सर्च या किसी कंपनी का डेटाबेस।

ठीक से सुरक्षित किए गए सॉफ़्टवेयर में, प्रोग्राम जिन निर्देशों का पालन करता है और जिस जानकारी को प्रोसेस करता है, उनके बीच एक स्पष्ट रेखा होती है। लेकिन LLM में ऐसी कोई रेखा नहीं होती।

मॉडल जो कुछ भी पढ़ता है, वह टेक्स्ट की एक लंबी धारा के रूप में आता है: डेवलपर के निर्देश, आपका सवाल, कोई वेबपेज जिसे उसने खोजा। AI मॉडल से उम्मीद की जाती है कि वे इस बात का ध्यान रखें कि कौन बोल रहा है—डेवलपर, उपयोगकर्ता, या खुद मॉडल, जो किसी समस्या पर सोच-विचार कर रहा है।

लेकिन शोधकर्ता Jasmine Cui और Charles Ye ने पाया कि मॉडल ज़्यादातर टेक्स्ट के लहजे से अंदाज़ा लगाते हैं कि कौन बोल रहा है। इसलिए अगर कोई हमलावर कुछ ऐसा लिखता है जो मॉडल के अपने तर्क जैसा लगे, तो मॉडल यह मान सकता है कि यह विचार खुद उसी का है। यह हर उस सुरक्षा व्यवस्था के लिए समस्या है जो इस बात पर निर्भर करती है कि मॉडल को पता हो कि नियंत्रण किसके हाथ में है।

हमारे अपने AI एजेंटों के साथ भी हमें यही समस्या आई है। हमारे CISO, Kyle Polley ने ISMG को बताया कि एजेंट "सिस्टम प्रॉम्प्ट में नीतियाँ जोड़ने के बाद भी शायद उनका पालन न करें।" इसीलिए हमने Numbat बनाया, एक ओपन-सोर्स टूल जो जाँचता है कि कोई एजेंट क्या करने वाला है, और अगर वह कार्रवाई किसी कॉन्फ़िगर किए गए सुरक्षा नियम का उल्लंघन करती है, तो उसे रोक सकता है।

LLM सुरक्षा का मतलब है यह स्वीकार करना कि मॉडल कभी-कभी गलत व्यक्ति से आदेश ले लेगा, और उसके इर्द-गिर्द ऐसे AI गार्डरेल बनाना जो ऐसा होने पर भी कारगर रहें।

LLM सुरक्षा के सबसे अच्छे तरीके क्या हैं?

हम LLM ऐप्लिकेशन के लिए OWASP Top 10 2026 को क्रम से, नंबर 1 से नंबर 10 तक समझेंगे।

हर जोखिम के लिए, आपको आसान भाषा में यह समझाया जाएगा कि चीज़ें कैसे बिगड़ती हैं, साथ ही एक वास्तविक उदाहरण भी मिलेगा। फिर हम उन तरीकों पर बात करेंगे जो इसे रोकने में, या कम से कम नुकसान को सीमित करने में मदद कर सकते हैं।

1. प्रॉम्प्ट इंजेक्शन पर काबू पाएँ

प्रॉम्प्ट इंजेक्शन तब होता है जब कोई हमलावर AI से ऐसे निर्देशों का पालन करवाता है जिनका उसे पालन नहीं करना चाहिए। ये निर्देश सीधे चैट में आ सकते हैं या किसी ईमेल, वेबपेज या दस्तावेज़ में छिपाकर रखे जा सकते हैं।

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

PCMag प्रॉम्प्ट सुरक्षा की तुलना किसी छिद्रों वाले पत्थर के छेद बंद करने से करता है। आप एक छेद बंद करते हैं, और पानी दूसरा रास्ता ढूँढ लेता है। “एक हमला अपना रास्ता बना लेता है; उसे ठीक कर दिया जाता है, लेकिन हमले के अनगिनत दूसरे रास्ते अभी खोजे जाने बाकी रहते हैं, सिर्फ़ इसलिए कि LLM जैसे सिस्टम कितने गतिशील होते हैं।”

उदाहरण: जून 2025 में, Aim Security के शोधकर्ताओं ने EchoLeak का पता लगाया, एक ऐसी खामी जिसने Microsoft 365 Copilot को धोखे से कंपनी की निजी जानकारी लीक करने पर मजबूर कर दिया। जब किसी कर्मचारी ने काम से जुड़ा कोई सामान्य सवाल पूछा, तो Copilot उस ईमेल को भी शामिल कर सकता था, उसमें छिपे निर्देशों का पालन कर सकता था, और संवेदनशील जानकारी हमलावर को भेज सकता था। यह हमला उन जाँचों को भी पार कर गया जो दुर्भावनापूर्ण निर्देशों को पकड़ने और संदिग्ध लिंक हटाने के लिए बनाई गई थीं।

आप क्या कर सकते हैं:

• Meta के “Rule of Two” का पालन करें: EchoLeak के लिए ऐसे AI की ज़रूरत थी जो कंपनी का डेटा पढ़ सके, बाहर से आए ईमेल पढ़ सके, और जानकारी बाहर भेज सके—उस AI में ये तीनों क्षमताएँ थीं। इसे इनमें से दो क्षमताओं तक सीमित रखने से प्रॉम्प्ट इंजेक्शन बहुत ज़्यादा नियंत्रण हासिल नहीं कर पाता। अगर कार्य के लिए तीनों की ज़रूरत हो, तो हर कार्रवाई से पहले इंसानी मंज़ूरी अनिवार्य करें।
• ऐसे हमलावरों के खिलाफ़ परीक्षण करें जो आपकी सुरक्षा व्यवस्था जानते हों: अपने सुरक्षा परीक्षकों को वे नियम और फ़िल्टर बताएँ जो आपने लागू किए हैं, फिर उन्हें इनसे बचने का रास्ता निकालने दें। एक अध्ययन में, सुरक्षा उपायों के हिसाब से अपना तरीका बदलने वाले हमलावर, परीक्षण किए गए 12 में से ज़्यादातर सुरक्षा उपायों के खिलाफ़ 90% से ज़्यादा मामलों में सफल रहे।

2. संवेदनशील जानकारी को लीक होने से रोकें

जब AI सिस्टम ऐसे लोगों को निजी जानकारी दे देते हैं जिन्हें वह नहीं देखनी चाहिए, तो इसे संवेदनशील जानकारी का खुलासा कहा जाता है। इसका मतलब किसी ग्राहक के भुगतान विवरण उजागर करना या निजी बातचीत को किसी साझा डेटाबेस में छोड़ देना हो सकता है।

कई लीक “ज़रूरत से ज़्यादा साझा करने” से शुरू होते हैं। मान लीजिए कोई कंपनी अपने AI को ढीली अनुमतियों वाली ड्राइव और नॉलेज बेस से जोड़ देती है। AI जहाँ तक पहुँच सकता है, वह सब निकाल लेता है, ठीक वैसे ही जैसे उसे डिज़ाइन किया गया है। किसी को सेंध लगाने की ज़रूरत नहीं पड़ती, फिर भी मान लीजिए कि LLM में सेंध लग चुकी है।

उदाहरण: जनवरी 2025 में, Wiz के शोधकर्ताओं को DeepSeek का एक डेटाबेस इंटरनेट पर खुला मिला, जिसमें दस लाख से ज़्यादा लॉग एंट्री थीं। इनमें चैट हिस्ट्री और API कुंजियाँ भी शामिल थीं, जिनका इस्तेमाल सॉफ़्टवेयर दूसरी सेवाओं तक पहुँचने के लिए करता है। शोधकर्ताओं को मॉडल से कुछ भी उगलवाने के लिए उसे मनाने की ज़रूरत ही नहीं पड़ी।

आप क्या कर सकते हैं:

• AI के डेटा पढ़ने से पहले एक्सेस की जाँच करें: मॉडल तक दस्तावेज़ भेजने से पहले आपके ऐप्लिकेशन को यह जाँचना चाहिए कि सवाल पूछने वाले व्यक्ति को कौन-से दस्तावेज़ देखने की अनुमति है।
• आपका AI जो रिकॉर्ड पीछे छोड़ता है, उन्हें सुरक्षित रखें: गतिविधि लॉग सहेजने से पहले उनमें से निजी विवरण और सीक्रेट कुंजियाँ हटा दें, लॉगिन अनिवार्य करें, और एक्सेस सिर्फ़ उन्हीं लोगों तक सीमित रखें जिन्हें इसकी ज़रूरत है। एक रिटेंशन अवधि तय करें ताकि ये रिकॉर्ड अनिश्चित काल तक जमा न होते रहें।

3. अत्यधिक स्वायत्तता पर लगाम लगाएँ

अत्यधिक स्वायत्तता वाले AI के पास उनके काम की ज़रूरत से ज़्यादा ताकत होती है: ऐसे टूल जिनकी उन्हें ज़रूरत नहीं, ऐसी अनुमतियाँ जो उनके कार्य के दायरे से बाहर हैं, या बिना जाँच के कार्रवाई करने की आज़ादी। यहाँ कारण मायने नहीं रखता।

इंजेक्शन प्रॉम्प्ट हो, कोई बग हो, या बस गलती करने वाला मॉडल—इन सबका नतीजा एक ही होता है। अगर AI में क्षमता है, तो वह देर-सबेर कुछ विनाशकारी कर ही देगा।

उदाहरण: जुलाई 2025 में, SaaStr के संस्थापक Jason Lemkin ने बताया कि बदलाव न करने के निर्देशों के बावजूद Replit के कोडिंग एजेंट ने 1,206 एग्ज़ीक्यूटिव रिकॉर्ड वाला उनका डेटाबेस डिलीट कर दिया। एजेंट ने पहले कहा कि डेटा वापस नहीं लाया जा सकता, हालाँकि बाद में उसे रिकवर करना संभव निकला। Jason ने पाया कि एजेंट से डेटाबेस को न छूने के लिए कहने से उसकी डेटाबेस डिलीट करने की क्षमता खत्म नहीं हुई थी।

बड़ा करें

स्रोत: X

आप क्या कर सकते हैं:

• ऐसी क्षमताएँ हटाएँ जिनकी कार्य को ज़रूरत नहीं है: एजेंट को मिलने वाले टूल और वे टूल क्या कर सकते हैं, दोनों को सीमित करें। ईमेल का सारांश बनाने वाले असिस्टेंट को उन्हें पढ़ने की अनुमति चाहिए, भेजने या डिलीट करने की नहीं।
• अनुमति की जाँच AI के बाहर रखें: जब भी किसी कार्रवाई का अनुरोध हो, उसे अपने सुरक्षा नियमों के आधार पर जाँचें, और उसके लिए किसी व्यक्ति की मंज़ूरी अनिवार्य करें।

4. जाँचें कि आपकी AI सप्लाई चेन में क्या आ रहा है

बहुत कम कंपनियाँ शुरुआत से AI बनाती हैं, और हर साल ऐसी कंपनियाँ और भी कम होती जा रही हैं। Menlo Ventures के 2025 The State of Generative AI in the Enterprise सर्वे के मुताबिक, 2024 में 53% कंपनियों ने AI मॉडल खरीदे, और 2025 में यह आँकड़ा बढ़कर 76% हो गया।

ज़्यादातर मामलों में, कंपनियाँ Hugging Face जैसे हब से मॉडल डाउनलोड करती हैं, उन्हें दूसरों के इकट्ठा किए गए डेटासेट पर आगे ट्रेन करती हैं, और अनजान लोगों के लिखे ऐड-ऑन और कोड पैकेज जोड़ती हैं।

इनमें से हर हिस्सा अंदर घुसने का एक रास्ता है। अगर किसी एक के साथ भी छेड़छाड़ होती है, तो समस्या आपके प्रोडक्ट के साथ ही ग्राहकों तक पहुँच जाती है।

उदाहरण: जनवरी 2026 से अगस्त 2026 के बीच Hugging Face पर सार्वजनिक मॉडल रिपॉज़िटरी की संख्या 2.43 मिलियन से बढ़कर 2.96 मिलियन हो गई। लेकिन जुलाई 2026 में, आंतरिक सुरक्षा परीक्षण के दौरान OpenAI के मॉडल उन्हें इंटरनेट से दूर रखने के लिए बनाए गए नियंत्रणों को चकमा दे गए और Hugging Face के सिस्टम के कुछ हिस्सों में सेंध लगा दी। दरअसल, एक एजेंट ने सार्वजनिक रूप से उजागर 14 एक्सेस क्रेडेंशियल हासिल किए, जाँचा कि वे काम करते हैं, और उन्हें दूसरे एजेंटों के साथ साझा किया। इसके बाद एजेंटों ने ऐसी खामियों का फ़ायदा उठाया जिनसे वे Hugging Face के सर्वर पर कोड चला सके।

OpenAI की रिपोर्ट में कहा गया है, “हम मॉडल के पूरे जीवनचक्र में अलाइनमेंट से जुड़ी शर्तें और सख्त कर रहे हैं, ज़्यादा अलग-थलग सैंडबॉक्स बना रहे हैं, इंटरनेट एक्सेस सीमित कर रहे हैं, और मॉडल वेट्स तक पहुँच पर नियंत्रण और कड़ा कर रहे हैं।”

आप क्या कर सकते हैं:

• मॉडल को एक सटीक वर्ज़न पर पिन करें और उनका सत्यापन करें: हर मॉडल को समीक्षा किए गए वर्ज़न पर पिन करें और लोड करने से पहले उसकी फ़ाइल का फ़िंगरप्रिंट जाँचें, ताकि उसी लेबल के तहत कोई बदली हुई फ़ाइल चुपके से न आ सके। OWASP डिजिटल हस्ताक्षरों की भी सलाह देता है, लेकिन एक चेतावनी के साथ—हस्ताक्षर यह साबित करता है कि मॉडल कहाँ से आया, यह नहीं कि वह सुरक्षित है।
• आपका AI जो भी पैकेज सुझाए, उसकी जाँच करें: AI असिस्टेंट के सुझाए किसी कोड पैकेज को इंस्टॉल करने से पहले पुष्टि करें कि वह मौजूद है, वह वही पैकेज है जो आप चाहते थे, और वह उसी प्रकाशक से आया है जिसकी आप उम्मीद करते हैं।

5. डेटा और मॉडल पॉइज़निंग से बचाव करें

पॉइज़न किया गया AI दूषित डेटा से सीखता है। यह वे उदाहरण हो सकते हैं जिन पर उसे फ़ाइन-ट्यून किया गया था, या कोई नॉलेज बेस जिसमें वह जवाब खोजता है। मॉडल तब भी ठीक से काम करता दिखता है; बस वह गलत सबक सीख लेता है, और कभी-कभी वह सिर्फ़ तभी गलत व्यवहार करना सीखता है जब उसे कोई खास ट्रिगर वाक्यांश दिखे।

जब तक कोई उस वाक्यांश का इस्तेमाल नहीं करता, तब तक मॉडल आपके हर परीक्षण में पास होता रहेगा।

बड़ा करें

साथ ही, इसके असर को पलटना बहुत मुश्किल है। पॉइज़निंग कोई ऐसा बग नहीं है जिसे आप पैच कर सकें। अगर आपका डेटा गलत है, तो आपको उसे दोबारा जाँचना, मॉडल को फिर से ट्रेन करना, या उसे पूरी तरह बदलना पड़ सकता है।

उदाहरण: अक्टूबर 2025 में, Anthropic, UK AI Security Institute और Alan Turing Institute के शोधकर्ताओं ने दिखाया कि 250 पॉइज़न किए गए दस्तावेज़ किसी मॉडल को बेतुका टेक्स्ट बनाना सिखा सकते हैं, जब भी उसका सामना किसी खास ट्रिगर से हो। परीक्षण किए गए मॉडल के चारों आकारों पर यही संख्या कारगर रही, भले ही सबसे बड़े मॉडल को 20 गुना से ज़्यादा साफ़ डेटा पर ट्रेन किया गया था।

आप क्या कर सकते हैं:

• ट्रैक करें कि आपका डेटा कहाँ से आता है: आप जिस भी डेटासेट और मॉडल का इस्तेमाल करते हैं, उसका रिकॉर्ड रखें—हर एक कहाँ से आया और वर्ज़न के बीच क्या बदला। हम डेटासेट के लिए वर्ज़न कंट्रोल की सलाह देते हैं, ताकि अगर पॉइज़निंग का पता चले, तो आप किसी साफ़ वर्ज़न पर वापस जा सकें और पता लगा सकें कि वह अंदर कैसे आई।
• बैकडोर के लिए परीक्षण करें: “बैकडोर” एक छिपा हुआ व्यवहार है जिसे हमलावर किसी मॉडल में डाल देता है, और जो किसी खास वाक्यांश या दूसरे ट्रिगर के मिलने पर सक्रिय हो जाता है। इनका परीक्षण ऐसे इनपुट से करें जो मॉडल से उसके सामान्य नियम तुड़वाने के लिए बनाए गए हों।

6. असीमित खपत पर सीमा लगाएँ

जब AI पर इस बात की कोई सीमा नहीं होती कि वे कितना काम कर सकते हैं या उन पर कितना खर्च आ सकता है, तो उनकी खपत को “असीमित” माना जाता है। ज़्यादातर AI सेवाएँ हर इस्तेमाल पर शुल्क लेती हैं, इसलिए कोई हमलावर आपका बिल बढ़ा सकता है या आपके मॉडल की नकल बना सकता है।

OWASP मूल समस्या को “लागत असमानता” कहता है। एक छोटा, सस्ता अनुरोध आपकी तरफ़ महँगी कंप्यूटिंग शुरू करवा सकता है।

उदाहरण: मई 2024 में, Sysdig की Threat Research Team ने “LLMjacking” नाम के एक नए हमले का पता लगाया। हमलावरों के एक समूह ने चुराए गए क्रेडेंशियल का इस्तेमाल करके क्लाउड पर होस्ट की गई 10 LLM सेवाओं को निशाना बनाया। वे Laravel के एक कमज़ोर वर्ज़न के ज़रिए अंदर घुसे, फिर उन्होंने पता लगाया कि इन क्रेडेंशियल से क्या-क्या किया जा सकता है और कौन-से कोटा लागू हैं, जिसका ज़ाहिर मकसद एक्सेस बेचना था। कई लॉगिंग सेटिंग्स की भी जाँच की गई, शायद पकड़े जाने से बचने के लिए। Sysdig के मुताबिक, सबसे खराब स्थिति में पीड़ित को रोज़ाना $46,000 से ज़्यादा का खर्च उठाना पड़ सकता है।

आप क्या कर सकते हैं:

• ऐसे बजट तय करें जो खर्च को रोक दें: अलग-अलग उपयोगकर्ताओं, API कुंजियों, टीमों और पूरे खाते के लिए खर्च की सख्त सीमाएँ रखें। अनुरोध जहाँ से भी आ सकते हैं, वहाँ इन्हें लागू करें।
• हर कार्य के लिए एक रुकने का बिंदु तय करें: सीमित करें कि कोई कार्य कितनी देर चल सकता है, कितना टेक्स्ट प्रोसेस और जनरेट कर सकता है, और कितने टूल कॉल कर सकता है। जो एजेंट खुद को दोहराते हैं या अपनी तय सीमा पार कर जाते हैं, उन्हें अपने-आप रोकने की व्यवस्था जोड़ें।

7. कार्रवाई करने से पहले गलत सूचना पकड़ें

जब कोई AI ऐसी गलत बात कहता है जो सही लगती है, और कोई व्यक्ति या कोई सिस्टम उसके आधार पर कार्रवाई करता है, तो इसे गलत सूचना कहा जाता है। मूल जोखिम गलत जवाब खुद उतना नहीं है, जितना यह कि उस गलत जवाब पर भरोसा करके उसका इस्तेमाल किया जाता है।

घटनाओं के रिकॉर्ड से पता चलता है कि इस क्षेत्र के पेशेवर गलत सूचना को लेकर उतने चिंतित नहीं थे जितना उन्हें होना चाहिए था। 2026 संस्करण के शुरुआती पत्र के मुताबिक, वोट देने वालों ने इसे सूची में सबसे निचले पायदानों के पास रखा, लेकिन वास्तविक घटनाओं को देखें तो यह शीर्ष के करीब है।

उदाहरण: 2025 में, Deloitte Australia ने A$440,000 के एक सरकारी अनुबंध के तहत कल्याण योजनाओं के IT सिस्टम की समीक्षा रिपोर्ट सौंपी। University of Sydney के शोधकर्ता Chris Rudge को उसमें ऐसे शोध के संदर्भ मिले जो मौजूद ही नहीं था, साथ ही एक संघीय अदालत के फ़ैसले से गढ़ा हुआ उद्धरण भी मिला। संशोधित रिपोर्ट में खुलासा किया गया कि Deloitte ने अपनी कार्यप्रणाली में Azure OpenAI GPT-4o का इस्तेमाल किया था, और फ़र्म आखिरी किस्त लौटाने पर सहमत हो गई। दुर्भाग्य से, यह एक एश्योरेंस समीक्षा थी।

आप क्या कर सकते हैं:

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

8. छिपे हुए संदर्भ के खुलासे से होने वाले नुकसान को सीमित करें

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

OWASP ने 2026 में इस प्रविष्टि का दायरा “सिस्टम प्रॉम्प्ट लीकेज” से बढ़ा दिया, क्योंकि जो जानकारी बाहर आ सकती है, सिस्टम प्रॉम्प्ट उसका सिर्फ़ एक हिस्सा है। खतरा इस बात पर निर्भर करता है कि आपने वहाँ क्या रखा है। टोन-ऑफ़-वॉइस गाइड लीक होना थोड़ी शर्मिंदगी की बात है, लेकिन लीक हुई API कुंजी किसी को आपके गोपनीय डेटाबेस तक पहुँच दे देती है।

उदाहरण: फ़रवरी 2023 में, उपयोगकर्ताओं ने Microsoft के Bing Chat से उसके आंतरिक निर्देश उगलवा लिए। एक सफल कोशिश Marvin von Hagen ने की, जिन्होंने OpenAI डेवलपर होने का दावा किया और मॉडल को कॉन्फ़िगर करने के बहाने निर्देश माँगे। Bing ने अपनी सर्च, जवाबों और सुरक्षा व्यवहार को नियंत्रित करने वाले नियमों के साथ-साथ अपना आंतरिक नाम, Sydney, भी बता दिया। उजागर हुए निर्देशों में एक निर्देश यह भी था कि वह उन निर्देशों को गोपनीय रखे।

आप क्या कर सकते हैं:

• सीक्रेट्स को मॉडल के कॉन्टेक्स्ट से बाहर रखें: मानकर चलें कि मॉडल जो कुछ भी पढ़ सकता है, वह उपयोगकर्ताओं को दिखाई दे सकता है—पासवर्ड, API कुंजियाँ और एक्सेस टोकन एक अलग सीक्रेट्स-मैनेजमेंट सिस्टम में स्टोर करें।
• नियम लीक होने पर भी अनुमतियाँ कारगर रहें: एक्सेस जाँच अपने एप्लिकेशन कोड में लागू करें। अगर कोई टूल केवल एडमिनिस्ट्रेटर के लिए प्रतिबंधित है, तो उसे चलाने से पहले उपयोगकर्ता के अकाउंट की अनुमतियाँ जाँचें।

9. अपने वेक्टर और एम्बेडिंग को पूरी तरह सुरक्षित करें

जब कोई AI आपकी कंपनी के दस्तावेज़ों में जवाब खोजने के लिए वेक्टर सर्च का उपयोग करता है, तो वह सीधे टेक्स्ट में नहीं खोजता। दस्तावेज़ों को “एम्बेडिंग” में बदला जाता है—ये संख्याओं की लंबी सूचियाँ होती हैं जो दर्शाती हैं कि हर अंश का अर्थ क्या है—और इन्हें एक वेक्टर डेटाबेस में स्टोर किया जाता है। किसी प्रश्न को भी इसी तरह बदला जाता है, और सिस्टम वे अंश निकालता है जिनकी संख्याएँ उसके सबसे नज़दीक होती हैं।

OWASP इसके विफल होने के चार तरीकों का सार बताता है: पॉइज़निंग सिस्टम को गलत बना देती है, इनवर्ज़न से डेटा लीक होता है, जैमिंग उसे चुप करा देती है, और त्रुटिपूर्ण एक्सेस कंट्रोल के कारण वह कुछ भी, किसी को भी सौंप देता है।

ये संख्याएँ उतना सुरक्षित एब्स्ट्रैक्शन नहीं हैं जितनी दिखती हैं। स्टोर किए गए एम्बेडिंग को वापस टेक्स्ट में बदला जा सकता है, और एक तरीके ने अपने परीक्षणों में 32-टोकन वाले छोटे अंशों में से 92% को हूबहू रिकवर कर लिया। इसलिए लीक हुआ “केवल-एम्बेडिंग” बैकअप भी दस्तावेज़ों की सामग्री उजागर कर सकता है।

उदाहरण: USENIX Security 2025 में प्रस्तुत एक शोध में, शोधकर्ताओं ने दिखाया कि सावधानी से तैयार किया गया एक दस्तावेज़ किसी AI को किसी खास प्रश्न का उत्तर देने से रोक सकता है। उन्होंने इसे उस संग्रह में जोड़ दिया जिसमें AI खोज करता था। जब AI को यह दस्तावेज़ मिला, तो वह कह सकता था कि उसके पास पर्याप्त जानकारी नहीं है या उत्तर देना असुरक्षित होगा। दस्तावेज़ को AI से उसके नियमों को अनदेखा करने के लिए कहने की ज़रूरत भी नहीं थी। इसे “रिट्रीवल जैमिंग” कहा जाता है।

आप क्या कर सकते हैं:

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

10. AI आउटपुट को आगे भेजने से पहले जाँचें

जब भी कोई एप्लिकेशन AI आउटपुट को यह जाँचे बिना किसी दूसरे सिस्टम में भेजता है कि वह वहाँ उपयोग के लिए सुरक्षित है या नहीं, तो वह LLM आउटपुट को अनुचित तरीके से हैंडल कर रहा होता है।

इस प्रविष्टि में वह असुरक्षित कोड भी शामिल है जिसे AI कोडिंग असिस्टेंट बड़े पैमाने पर जनरेट करते हैं। इसलिए, असिस्टेंट की लिखी हर पंक्ति भी आउटपुट ही है।

उदाहरण: 2025 में, शोधकर्ता Johann Rehberger ने दिखाया कि Sourcegraph का Amp कोडिंग असिस्टेंट सिर्फ़ एक इमेज दिखाकर चैट की सामग्री कैसे लीक कर सकता है। उन्होंने प्रॉम्प्ट इंजेक्शन का उपयोग करके Amp से किसी इमेज के वेब पते में निजी जानकारी शामिल करवाई। इसके बाद एप्लिकेशन ने अपने-आप वह इमेज फ़ेच की, जिससे वह जानकारी उनके सर्वर पर पहुँच गई। आउटपुट हैंडलिंग की विफलता वही स्वचालित अनुरोध था—मॉडल द्वारा जनरेट किया गया टेक्स्ट किसी बाहरी सर्वर से कनेक्शन बन गया, जो अपने साथ निजी डेटा ले गया।

आप क्या कर सकते हैं:

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

Perplexity LLM को कैसे सुरक्षित रखता है?

हम मानकर चलते हैं कि ऊपर बताया गया हर जोखिम कभी न कभी सामने आएगा, और हम अपने सिस्टम ऐसे डिज़ाइन करते हैं कि ऐसा होने पर भी वह ज़्यादा नुकसान न कर सके। हमारे CISO, Kyle Polley ने एक हालिया वर्कशॉप में विस्तार से बताया कि हम यह कैसे करते हैं।

• एजेंट को अपना कंप्यूटर मिलता है, जो शुरुआत में खाली होता है: आपके लैपटॉप पर इंस्टॉल किए गए एजेंट टूल उसकी फ़ाइलों, ऐप्स और सेव किए गए क्रेडेंशियल्स तक पहुँच हासिल कर सकते हैं। Perplexity Computer इसके उलट काम करता है। हर टास्क अपने अलग, आइसोलेटेड सैंडबॉक्स में चलता है, और जैसा कि Polley कहते हैं, “डिफ़ॉल्ट रूप से इसके पास किसी भी चीज़ का एक्सेस नहीं होता।”
• एजेंट कभी पासवर्ड नहीं देखता: कनेक्ट की गई सेवाओं के क्रेडेंशियल्स सैंडबॉक्स के बाहर स्टोर किए जाते हैं। जब एजेंट को GitHub जैसी किसी सेवा तक पहुँचना होता है, तो वह बिना किसी क्रेडेंशियल के अनुरोध भेजता है। एक गेटवे जाँचता है कि गंतव्य और अनुरोध उसकी अपेक्षा के अनुरूप हैं, फिर बाहर जाते समय उसमें क्रेडेंशियल्स जोड़ देता है। एजेंट कुंजियाँ पाए बिना कनेक्शन का उपयोग कर सकता है।
• आपकी अनुमतियाँ बरकरार रहती हैं, और आप उन्हें और सख़्त कर सकते हैं: OAuth के ज़रिए बनाए गए कनेक्शन, कनेक्ट की गई सेवा में आपकी एक्सेस अनुमतियों को बनाए रखते हैं। अगर आप कुछ नहीं देख सकते, तो आपका एजेंट भी नहीं देख सकता।
• हर वेब पेज को अजनबी माना जाता है: हमने अपने एजेंटिक ब्राउज़र Comet के लिए BrowseSafe बनाया, क्योंकि जिन टूल्स का हमने परीक्षण किया, वे वास्तविक उपयोग में हमारी ज़रूरतें पूरी नहीं करते थे। यह ब्राउज़र वेब पेजों और ईमेल सहित अन्य बाहरी सामग्री को प्रॉम्प्ट इंजेक्शन के लिए स्कैन करता है। हमने मॉडल और डेटासेट, दोनों को ओपन-सोर्स किया है।
• हम एजेंट और उन मशीनों पर नज़र रखते हैं जिन पर वह चलता है: Numbat एजेंट के कार्रवाई करने का निर्णय लेने और टूल के वास्तव में चलने के बीच काम करता है। Numbat समर्थित कोडिंग एजेंटों की गतिविधियों को लॉग करता है और कॉन्फ़िगर की गई नीतियों का उल्लंघन करने वाली कार्रवाइयों को उनके एक्ज़ीक्यूट होने से पहले ही ब्लॉक कर सकता है। Bumblebee लैपटॉप, सर्वर और बिल्ड पाइपलाइनों में मौजूद सॉफ़्टवेयर पैकेजों की सूची बनाता है और ज्ञात दुर्भावनापूर्ण पैकेजों को फ़्लैग करता है। दोनों ओपन सोर्स हैं।
• मॉडल प्रदाता आपका डेटा नहीं रखते: अपने थर्ड-पार्टी LLM प्रदाताओं के साथ हमारी ज़ीरो डेटा रिटेंशन व्यवस्था है। Enterprise एडमिन Perplexity के अपने डेटा रिटेंशन की अवधि को भी 24 घंटे जितना कम सेट कर सकते हैं।

हमने Numbat को पहले से ही, एहतियात के तौर पर बनाया, और इसकी वजह Polley एक पंक्ति में बताते हैं: “आप किसी एजेंट को जितनी ज़्यादा स्वायत्तता देते हैं, जोखिम उतना ही ज़्यादा होता है।”

LLM सुरक्षा से जुड़े अक्सर पूछे जाने वाले प्रश्न

सबसे सुरक्षित LLM कौन-सा है?

कोई भी LLM अपने-आप किसी एप्लिकेशन को सुरक्षित नहीं बनाता—मॉडल अब भी उस सामग्री को, जिसे उन्हें केवल पढ़ना चाहिए, ऐसे निर्देश समझने की गलती कर सकते हैं जिनका उन्हें पालन करना चाहिए। मानक परीक्षणों में मज़बूत दिखने वाले बचाव भी दबाव में ढह सकते हैं।

बेहतर सवाल यह है कि आपके उपयोग के मामले के लिए कौन-सा सेटअप सबसे सुरक्षित है। इसका मतलब है सीमित अनुमतियाँ, मॉडल से दूर रखे गए क्रेडेंशियल्स, जोखिम भरी कार्रवाइयों के लिए मानवीय स्वीकृति, और ऐसे लोगों द्वारा परीक्षण जो आपके बचाव के तरीकों को जानते हों।

LLM की कमज़ोरियाँ क्या हैं?

LLM की कमज़ोरियाँ वे खामियाँ हैं जिनकी वजह से किसी AI सिस्टम को धोखा दिया जा सकता है, उससे डेटा लीक हो सकता है, या वह नुकसान पहुँचा सकता है—चाहे किसी हमलावर के कारण या उसकी अपनी गलतियों से।

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

क्या प्राइवेट LLM सुरक्षित है?

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

सेल्फ़-होस्टिंग में, आप अपने डाउनलोड किए गए मॉडल के लिए भी ज़िम्मेदार होते हैं, जिसमें सप्लाई चेन के जोखिम और उसके लिए ज़रूरी इंफ्रास्ट्रक्चर भी शामिल हैं।