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 या मूळ समस्येला “खर्चातील विषमता” (cost asymmetry) म्हणते. एक छोटी, स्वस्त विनंती तुमच्या बाजूला खर्चिक संगणन सुरू करू शकते.

उदाहरण: मे 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 वापरल्याचे उघड केले, आणि कंपनीने अंतिम हप्ता परत करण्याचे मान्य केले. दुर्दैवाने, हे एक खात्रीकरण पुनरावलोकन (assurance review) होते.

तुम्ही काय करू शकता:

• पुरावे उत्तराला दुजोरा देतात का ते तपासा: दावे सद्य, अधिकृत स्रोतांवर आधारित ठेवा. धोरणाशी संबंधित उत्तरासाठी, मंजूर धोरण मिळवा आणि त्यातील अपवादांसह ते निष्कर्षाला दुजोरा देते का ते तपासा.
• प्रणालीने कृती करण्यापूर्वी पडताळणी करा: एखाद्या ग्राहकाने ओळख तपासणी उत्तीर्ण केली असे एजंट सांगत असेल, तर पेमेंट जारी करण्यापूर्वी पडताळणी प्रणालीमध्ये त्याची खात्री करा. महत्त्वाच्या निर्णयांसाठी मानवी मंजुरी आवश्यक करा आणि समर्थन करणारे पुरावे पुनरावलोकनकर्त्याला उपलब्ध करून द्या.

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 सुरक्षित आहे का?

काही बाबतीत हा अधिक सुरक्षित पर्याय आहे, पण तो आपोआप सुरक्षित ठरत नाही. तुम्ही मॉडेल स्वतःच्या पायाभूत सुविधांवर किंवा क्लाउड वातावरणात चालवल्यास डेटा हाताळणीवर तुमचे अधिक नियंत्रण असते. मात्र प्रॉम्प्ट इंजेक्शन, अतिरिक्त एजन्सी, पॉयझनिंग किंवा चुकीची माहिती आपोआप रोखण्याचा कोणताही मार्ग नाही.

सेल्फ-होस्टिंग करताना, तुम्ही डाउनलोड केलेल्या मॉडेलची जबाबदारीही तुमचीच असते, ज्यामध्ये पुरवठा साखळीतील धोके आणि त्यासाठी लागणाऱ्या पायाभूत सुविधांचा समावेश आहे.