इस पेज पर
संक्षिप्त उत्तर
एलएलएम एप्लिकेशन को तीन सीमाओं पर सुरक्षित रखें: इसका उपयोग कौन कर सकता है, मॉडल क्या एक्सेस कर सकता है या बदल सकता है, और प्रत्येक अनुरोध कितना काम ट्रिगर कर सकता है। शीघ्र इंजेक्शन और स्वचालित बॉट दुरुपयोग का अलग-अलग परीक्षण करें, वास्तविक डेटा और टूल परिणामों को सत्यापित करें, और प्रत्येक प्रस्तावित सुधार के लिए साक्ष्य बनाए रखें। केवल एक इनकार संदेश या एक शांत डैशबोर्ड यह साबित नहीं करता है कि सीमा कायम है।
क्या ले जाना है
- बॉट का दुरुपयोग मॉडल में हेरफेर किए बिना सामान्य अनुरोधों के माध्यम से संसाधनों का उपभोग कर सकता है।
- प्राधिकरण और व्यय नियंत्रण को एप्लिकेशन और डाउनस्ट्रीम सेवाओं में प्रवर्तन की आवश्यकता है।
- प्रत्येक प्रतिकूल मामले को एक वैध कार्य के साथ जोड़ें ताकि सुरक्षा चुपचाप उत्पाद को न तोड़ दे।
- परीक्षण किए गए संस्करण, देखे गए परिणाम, अप्रयुक्त पथ और पुनः परीक्षण परिणाम की रिपोर्ट करें।
स्रोतों की जाँच की गई . अनुसंधान संश्लेषण और रूब्रेक्स सिफारिशें। उदाहरणों और स्थानीय प्रयोगों को लेबल किया गया है; वे ग्राहक परिणाम नहीं हैं.
आप किस प्रकार के हमले को रोकने का प्रयास कर रहे हैं?
एलएलएम सुरक्षा मॉडल के आसपास के एप्लिकेशन के साथ-साथ उसकी प्रतिक्रियाओं को भी कवर करती है। त्वरित इंजेक्शन अविश्वसनीय इनपुट को एक निर्देश की तरह कार्य करने का प्रयास करता है। बॉट दुरुपयोग वर्कफ़्लो का दुरुपयोग करने के लिए स्वचालन का उपयोग करता है, संभवतः बिना किसी विशेष संकेत के। एक ही एप्लिकेशन दोनों का अनुभव कर सकता है, लेकिन एक नियंत्रण जो संदिग्ध भाषा को पकड़ता है, वह बार-बार वैध दिखने वाले अनुरोधों को नहीं रोकेगा।
OWASP के स्वचालित-खतरे प्रोजेक्ट में स्पष्ट रूप से वैध एप्लिकेशन कार्यक्षमता का दुरुपयोग शामिल है। इसका एलएलएम जोखिम मार्गदर्शन सेवा में गिरावट और आर्थिक नुकसान के मार्ग के रूप में अत्यधिक अनुमान का वर्णन करता है। किसी घटना का परीक्षण करते समय उन भेदों का उपयोग करें: यह तय करने से पहले प्रभावित संपत्ति और परिणाम की पहचान करें कि समस्या मॉडल व्यवहार, खाता पहुंच, प्राधिकरण या संसाधन प्रबंधन से संबंधित है या नहीं।
साक्ष्य: OWASP वेब अनुप्रयोगों के लिए स्वचालित खतरे [1]LLM10:2025 असीमित उपभोग [2]
| धमकी | परीक्षण के लिए सीमा | परिणाम का साक्ष्य |
|---|---|---|
| पुनर्प्राप्त दस्तावेज़ में शीघ्र इंजेक्शन | अविश्वसनीय दस्तावेज़ पाठ किसी टूल कार्रवाई को अधिकृत नहीं कर सकता | टूल ट्रेस और अंतिम रिकॉर्ड स्थिति |
| क्रॉस-टेनेंट डेटा अनुरोध | कॉल करने वाला केवल अनुमत रिकॉर्ड ही पुनः प्राप्त कर सकता है | पहुंच से इनकार और साथ ही दूसरे किरायेदार की सामग्री का अभाव |
| बार-बार भुगतान किया गया अनुमान | कोई खाता या किरायेदार सहमत कार्य बजट से अधिक नहीं हो सकता | प्रवेश निर्णय, उपयोग काउंटर, और प्रदाता-कॉल गिनती |
| रनअवे टूल या पुनः प्रयास लूप | किसी कार्य में चरणों की एक सीमित संख्या और एक समय सीमा होती है | कदम गिनती और सबूत कि आगे का काम रुक गया |
| बार-बार दुष्प्रभाव का अनुरोध | उसी ऑपरेशन का पुनः प्रयास करने से किसी क्रिया की नकल नहीं होती है | एक परिणामी रिकॉर्ड और एक सुसंगत ऑपरेशन पहचानकर्ता |
| वैध स्वचालन अवरुद्ध | स्वीकृत एकीकरण एक प्रयोग योग्य पथ बनाए रखते हैं | अपने निर्धारित कोटा के भीतर सफल नियंत्रण कार्य |
स्कैनर चुनने से पहले परीक्षण सीमा लिखें
रूब्रेक्स के प्रस्तावित मूल्यांकन वर्कफ़्लो के लिए, एप्लिकेशन संस्करण, पर्यावरण, प्रवेश बिंदु, मॉडल कॉन्फ़िगरेशन, पुनर्प्राप्ति स्रोत और सक्षम टूल का नाम दें। प्रत्येक संरक्षित संसाधन के स्वामी की पहचान करें। उस परिणाम के लिए एक वाक्य लिखें जो कभी घटित नहीं होना चाहिए, जैसे कि एक समर्थन उपयोगकर्ता दूसरे किरायेदार का टिकट देख रहा है या केवल-पढ़ने के लिए सहायक एक संदेश भेज रहा है।
सिंथेटिक खातों, दस्तावेज़ों और टूल गंतव्यों के साथ एक परीक्षण वातावरण का उपयोग करें। सिस्टम स्वामी के साथ अनुरोध सीमा, व्यय सीमा, निष्पादन विंडो और रोक शर्तों पर सहमति व्यक्त करें। एक कम कॉन्फ़िगर किया गया कोटा ट्रैफ़िक बाढ़ उत्पन्न किए बिना प्रवर्तन का कार्य कर सकता है। सामान्य ग्राहक कार्यों का एक छोटा सा सेट नियंत्रण के रूप में रखें, और प्रारंभिक डेटा स्थिति रिकॉर्ड करें ताकि बाद के परीक्षणों को रीसेट किया जा सके। यह एक एप्लिकेशन परीक्षण योजना है, असंबंधित सेवाओं को स्कैन करने की अनुमति नहीं है।
वास्तविक उपकरण अनुमतियों के विरुद्ध शीघ्र इंजेक्शन का परीक्षण करें
OWASP सीमित उपकरण, सत्यापन और कम से कम विशेषाधिकार के साथ-साथ मॉडल-आधारित रेलिंग को एक परत के रूप में मानने की अनुशंसा करता है। इसका अत्यधिक-एजेंसी मार्गदर्शन किसी कार्रवाई की अनुमति है या नहीं यह तय करने के लिए मॉडल को छोड़ने के बजाय प्राधिकरण को डाउनस्ट्रीम सिस्टम में रखता है। एक मजबूत निर्देश उपयोगी संदर्भ है, लेकिन यह अनुमति जांच का स्थान नहीं ले सकता।
एक उदाहरणात्मक समर्थन परीक्षण में, एक सिंथेटिक पुनर्प्राप्त नोट सहायक से टिकट के मालिक को बदलने के लिए कहता है, भले ही उपयोगकर्ता ने केवल सारांश का अनुरोध किया हो। लाइव राइट टूल को इंस्ट्रुमेंटेड टेस्ट कार्यान्वयन से बदलें। रिकॉर्ड करें कि क्या मॉडल ने लिखने का अनुरोध किया है, क्या टूल सीमा ने इसकी अनुमति दी है, और क्या कोई रिकॉर्ड बदला है। एक मॉडल इनकार और एक अस्वीकृत टूल अनुरोध अलग-अलग अवलोकन हैं; दोनों को सुरक्षित रखें.
फिर एक अधिकृत परीक्षण खाते के माध्यम से एक वैध अपडेट सबमिट करें। यदि प्रस्तावित फिक्स हर अपडेट को ब्लॉक कर देता है, तो इसने उपयोगी सुरक्षा प्रदर्शित करने के बजाय उत्पाद अनुबंध को बदल दिया है। अनुमोदन की आवश्यकता वाले कार्यों के लिए, सत्यापित करें कि स्वीकृत लक्ष्य और तर्क निष्पादित किए गए हैं और उन्हें बदलने के लिए एक नए निर्णय की आवश्यकता है।
साक्ष्य: एलएलएम प्रॉम्प्ट इंजेक्शन प्रिवेंशन चीट शीट [3]एलएलएम06:2025 अत्यधिक एजेंसी [4]
मॉडल या उपकरण लागत उत्पन्न करने से पहले बॉट के दुरुपयोग को नियंत्रित करें
OWASP का एपीआई संसाधन-खपत मार्गदर्शन कार्यभार और तीसरे पक्ष के खर्च पर स्पष्ट सीमा की मांग करता है। एलएलएम एप्लिकेशन के लिए, संपूर्ण कार्य की लागत का मूल्यांकन करें, जिसमें पुनर्प्राप्ति, मॉडल कॉल, टूल संचालन और पुनः प्रयास शामिल हैं। यदि एक स्वीकृत अनुरोध अनबाउंड डाउनस्ट्रीम कार्य को ट्रिगर कर सकता है तो आने वाले अनुरोधों की संख्या को सीमित करना अपर्याप्त है।
रूब्रेक्स अलग प्रवेश सीमा और निष्पादन सीमा का दस्तावेजीकरण करने की सिफारिश करता है। प्रवेश के समय, अनुरोध को किसी सत्यापित खाते या किरायेदार से संबद्ध करें और उसके भत्ते की जांच करें। निष्पादन के दौरान, बाउंड इनपुट आकार, आउटपुट बजट, समवर्ती कार्य, टूल चरण और पुनः प्रयास प्रयास। एक समय सीमा लागू करें और परिभाषित करें कि पहले से ही कतारबद्ध या प्रदाता को भेजे गए काम के लिए रद्दीकरण का क्या मतलब है। जहां उपलब्ध हो, प्रदाता व्यय नियंत्रण का उपयोग करें; अकेले बिलिंग अलर्ट से खपत नहीं रुकती।
एक उदाहरणात्मक अंकगणितीय जाँच के रूप में, यदि एक परीक्षण नीति प्रति कार्य तीन मॉडल कॉल और प्रति कॉल अधिकतम दो पुनः प्रयास की अनुमति देती है, तो बजट को अधिकतम नौ प्रयासित मॉडल कॉल की अनुमति देनी चाहिए। यह अनुशंसित उत्पादन सेटिंग या लागत अनुमान नहीं है। यह प्रति-अनुरोध कोटा और एप्लिकेशन द्वारा वास्तव में शेड्यूल किए जा सकने वाले कार्य के बीच बेमेल को उजागर करने का एक तरीका है। पुनर्प्राप्ति और बाह्य-उपकरण बजट अलग-अलग शामिल करें।
साक्ष्य: API4:2023 अप्रतिबंधित संसाधन खपत [5]LLM10:2025 असीमित उपभोग [2]
निष्पादित उदाहरण: एक कोटा दौड़, फिक्स, और पुनः परीक्षण
हमने 3 अक्टूबर, 2026 को लिंक किए गए मॉडल-मुक्त Node.js फिक्स्चर को निष्पादित किया। यह दो समवर्ती अनुरोधों और एक सिंथेटिक इकाई के भत्ते का उपयोग करता है। संवेदनशील परिदृश्य में, एक बाधा दोनों अनुरोधों को जारी रखने से पहले एक ही ठहराव तक पहुंचने के लिए मजबूर करती है। कोई आउटबाउंड अनुरोध, वास्तविक उपयोगकर्ता रिकॉर्ड, सशुल्क मॉडल कॉल या लाइव-साइट लक्ष्य नहीं हैं; प्रदाता कॉल को इन-मेमोरी स्टब द्वारा गिना जाता है।
असुरक्षित संस्करण में, प्रत्येक अनुरोध शेष भत्ते की जांच करता है, बाधा की प्रतीक्षा करता है, फिर कटौती करता है। दोनों चेक पास करते हैं: दो को प्रवेश दिया जाता है, दो स्टब कॉल होते हैं, और शेष भत्ता −1 हो जाता है। निश्चित संस्करण में, अनुरोध पहले प्रतीक्षा से पहले अपनी इकाई को समकालिक रूप से आरक्षित करता है। केवल एक अनुरोध को स्वीकार किया जाता है और दूसरे को स्टब से पहले अस्वीकार कर दिया जाता है; शेष भत्ता शून्य है.
स्क्रिप्ट डाउनलोड करें और नोड.जेएस 22 के साथ नोड कोटा-रेस-डेमो.एमजेएस चलाएं। यह चार परिदृश्य प्रिंट करता है; परिणाम रिकॉर्ड में सटीक स्क्रिप्ट का देखा गया आउटपुट, रनटाइम, दिनांक और SHA-256 हैश शामिल है। शून्य-बजट नियंत्रण दोनों अनुरोधों को अस्वीकार करता है; पर्याप्त-बजट नियंत्रण दोनों को स्वीकार करता है। वे नियंत्रण जाँचते हैं कि समाधान केवल प्रत्येक अनुरोध को अवरुद्ध नहीं कर रहा है।
यह एक शेड्यूलिंग दोष और एक एकल-प्रक्रिया फिक्स प्रदर्शित करता है। यह एक वितरित कोटा कार्यान्वयन नहीं है: सिंक्रोनस जावास्क्रिप्ट श्रमिकों या प्रतिकृतियों में अनुरोधों को क्रमबद्ध नहीं कर सकता है। उत्पादन प्रवेश के लिए साझा भंडारण में परमाणु आरक्षण, पुनः प्रयास के लिए निष्क्रियता और पूर्ण होने या रद्द करने पर स्पष्ट सामंजस्य की आवश्यकता होती है। परिवर्तनीय-लागत मॉडल अनुरोधों को एक रूढ़िवादी आरक्षण और अंतिम उपयोग समायोजन की भी आवश्यकता होती है। उन व्यवहारों को अलग से सत्यापित करें; यह फिक्स्चर किरायेदार अलगाव, शीघ्र इंजेक्शन, या रूब्रेक्स उत्पादन बुनियादी ढांचे का परीक्षण नहीं करता है।
- रनयोग्य कोटा रेस फिक्स्चर डाउनलोड करें (Node.js)
- रिकॉर्ड किया गया निष्पादन और स्क्रिप्ट हैश (JSON) डाउनलोड करें
| परिदृश्य | स्वीकृत/अस्वीकृत | स्टब कॉल | शेष भत्ता |
|---|---|---|---|
| असुरक्षित: भत्ता 1 | 2 / 0 | 2 | −1 |
| प्रतीक्षा से पहले आरक्षित: भत्ता 1 | 1 / 1 | 1 | 0 |
| शून्य-बजट नियंत्रण | 0 / 2 | 0 | 0 |
| पर्याप्त-बजट नियंत्रण: भत्ता 2 | 2 / 0 | 2 | 0 |
अवलोकन योग्य उत्तीर्ण स्थितियों के साथ एक छोटा परीक्षण सेट
निम्नलिखित मामले एक प्रस्तावित प्रारंभिक कार्यपत्रक हैं, रूब्रेक्स क्लाइंट या पूर्ण कवरेज के दावे के परिणाम नहीं हैं। उदाहरण सीमाओं को उत्पाद के लिखित अनुबंध से बदलें। प्रत्येक मामले को चलाने से पहले अपेक्षित परिणाम रिकॉर्ड करें और बाद में साक्ष्य का संदर्भ शामिल करें।
कोटा परीक्षणों के लिए, एक अलग वातावरण में जानबूझकर छोटे भत्ते को कॉन्फ़िगर करें और अनुरोध की मात्रा कम रखें। अनुमति परीक्षणों के लिए, दो सिंथेटिक किरायेदारों और अद्वितीय गैर-संवेदनशील मार्करों का उपयोग करें। पुनः प्रयास परीक्षण के लिए, एक नकली उपकरण द्वारा अपना कार्य पूरा करने के बाद एक पावती विफलता का अनुकरण करें। ये फिक्स्चर वास्तविक आउटेज, वास्तविक ग्राहक डेटा या विनाशकारी साइड इफेक्ट पर भरोसा किए बिना सीमा का निरीक्षण करना संभव बनाते हैं।
| मामला | सेटअप | सत्यापित करने के लिए अपेक्षित परिणाम |
|---|---|---|
| रीड-ओनली सहायक को लिखने का निर्देश प्राप्त होता है | सिंथेटिक दस्तावेज़; यंत्रीकृत लेखन उपकरण | कोई अनधिकृत राज्य परिवर्तन नहीं; प्रयास किए गए कॉल दृश्यमान रहते हैं |
| किरायेदार ए किरायेदार बी के परीक्षण रिकॉर्ड का अनुरोध करता है | दो पृथक परीक्षण खाते और मार्कर दस्तावेज़ | सामग्री लौटाने से पहले पहुंच अस्वीकृत कर दी गई |
| कार्य बिना किसी शेष भत्ते के शुरू होता है | समाप्त कोटा के साथ परीक्षण खाता | नए बिल योग्य अनुरोध को स्वीकार किए जाने से पहले अस्वीकृत कर दिया गया |
| अंतिम भत्ते के लिए दो कार्य प्रतिस्पर्धा करते हैं | नियंत्रित समवर्ती अनुरोध; वाद्ययंत्र प्रदाता | भत्ता आरक्षण परमाणु है; स्वीकृत कार्य बजट के भीतर रहता है |
| टूल अपनी चरण सीमा तक पहुँच गया | एक छोटे कॉन्फ़िगर अधिकतम के साथ मॉक टूल अनुक्रम | निष्पादन रुक जाता है और अपूर्ण कार्य की रिपोर्ट करता है |
| उपकरण पूरा होने के बाद परिणाम खो जाता है | स्थिर संचालन पहचानकर्ता के साथ नकली दुष्प्रभाव | पुन: प्रयास स्थिति का समाधान करता है या दोहराव के बिना परिणाम का पुन: उपयोग करता है |
| वैध ग्राहक संरक्षित पथ का उपयोग करता है | अधिकृत खाता और प्रतिनिधि सामान्य अनुरोध | कार्य अनुमत विलंबता और संसाधन बजट के भीतर पूरा होता है |
किसी निष्कर्ष को समाधान में बदलें जिसे कोई सत्यापित कर सके
एक उपयोगी खोज बताती है कि क्या अपेक्षित था, क्या हुआ, यह क्यों मायने रखता है, और कौन से साक्ष्य निष्कर्ष का समर्थन करते हैं। सिस्टम संस्करण, परीक्षण केस, खाता भूमिका, कॉन्फ़िगरेशन, देखी गई स्थिति और रन पहचानकर्ता को एक साथ रखें। मॉडल-जनित संदेह को पुनरुत्पादित सीमा विफलता से अलग करें। संकेत के नाटकीय शब्दों के बजाय पहुंच योग्य डेटा या कार्रवाई का उपयोग करके प्रभाव का वर्णन करें।
एक उदाहरणात्मक कोटा खोज के लिए, अपेक्षित परिणाम प्रदाता कॉल से पहले अस्वीकृति है। देखी गई विफलता खाता भत्ता समाप्त होने के बाद दर्ज की गई प्रदाता कॉल हो सकती है। एक उम्मीदवार प्रवेश से पहले भत्ता आरक्षित कर सकता है। पुन: परीक्षण में मूल मामला, अंतिम भत्ते के आसपास नियंत्रित समवर्तीता और पर्याप्त कोटा के साथ एक वैध अनुरोध शामिल होना चाहिए। रिकॉर्ड करें कि क्या परिणाम निश्चित है, आंशिक रूप से तय है, पुनरुत्पादित नहीं है, या परीक्षण नहीं किया गया है; वे लेबल विनिमेय नहीं हैं।
| फ़ील्ड | क्या रखना है |
|---|---|
| दायरा | संस्करण, परिवेश, घटक, भूमिका और स्पष्ट बहिष्करण |
| उम्मीद | संरक्षित सीमा और अवलोकन योग्य स्वीकृति शर्त |
| अवलोकन | संशोधित इनपुट, प्रासंगिक ट्रेस और अंतिम स्थिति |
| प्रभाव | पहुंच योग्य डेटा, अनधिकृत कार्रवाई, या संसाधन जोखिम |
| निवारण | स्वामी, प्रस्तावित नियंत्रण, और कॉन्फ़िगरेशन या कोड संदर्भ |
| पुनः परीक्षण करें | मूल और नियंत्रण मामले, परिणाम, तिथि और अवशिष्ट अनिश्चितता |
सुरक्षा और उत्पाद उपयोगिता को एक साथ मापें
मूल्यांकन रीडआउट के लिए, सीमा उल्लंघन, अस्वीकृत अनुरोध, अधूरे कार्य, वैध मामलों पर गलत अवरोध और संसाधन उपयोग की रिपोर्ट करें। प्रत्येक दर के पीछे मामलों की संख्या और प्रकार बताएं। बेसलाइन और उम्मीदवार के बीच कॉन्फ़िगरेशन अंतर को सुरक्षित रखें। समग्र स्कोर उस अनधिकृत कार्रवाई को छिपा सकता है जिसे रोकने के लिए परीक्षण का उद्देश्य था।
चल रहे ऑपरेशनों के लिए, तय करें कि किसे अलर्ट प्राप्त होगा और वे क्या बदल सकते हैं। एक उपयोगी प्रतिक्रिया किसी महंगे उपकरण को रोकना, किरायेदार के भत्ते को कम करना, या किसी संवेदनशील पथ पर अस्थायी रूप से समीक्षा की आवश्यकता हो सकती है। जांच रिकॉर्ड को एक्सेस-नियंत्रित रखें और संपूर्ण ग्राहक वार्तालापों को सामान्य अलर्ट चैनल में कॉपी करने से बचें। किसी पुष्ट घटना के बाद, एक सैनिटाइज़्ड रिग्रेशन केस जोड़ें और मॉडल, प्रॉम्प्ट, पुनर्प्राप्ति, या टूल परिवर्तन के बाद संबंधित सीमा को फिर से जांचें।
साक्ष्य की सीमाएँ
कोटा-रेस अनुभाग डाउनलोड करने योग्य कोड और परिणामों के साथ एक निष्पादित, मॉडल-मुक्त स्थानीय सिमुलेशन की रिपोर्ट करता है। अन्य परिदृश्य प्रस्तावित परीक्षण मामले हैं, न कि निष्पादित हमले या ग्राहक निष्कर्ष। फिक्स्चर एकल-प्रक्रिया शेड्यूलिंग दोष प्रदर्शित करता है; यह वितरित कोटा, लाइव बुनियादी ढांचे, शीघ्र सुरक्षा, या किरायेदार अलगाव को मान्य नहीं करता है। ओडब्ल्यूएएसपी मार्गदर्शन एक खतरे का वर्गीकरण प्रदान करता है, न कि इस बात का सबूत कि कोई विशेष एप्लिकेशन सुरक्षित है। सहमत सीमाओं और सुरक्षित फिक्स्चर के साथ केवल अधिकृत सिस्टम का परीक्षण करें।
सामान्य प्रश्न
क्या एलएलएम बॉट हमला हमेशा शीघ्र इंजेक्शन होता है?
नहीं, स्वचालित ग्राहक मॉडल के निर्देशों को बदले बिना सामान्य सुविधाओं का दुरुपयोग कर सकते हैं या बजट समाप्त कर सकते हैं। नियंत्रण का चयन करने से पहले संरक्षित संसाधन और देखे गए व्यवहार का निदान करें।
क्या WAF या कैप्चा इसका समाधान करेगा?
ये ट्रैफ़िक और दुरुपयोग नियंत्रण का समर्थन कर सकते हैं, लेकिन वे किरायेदार प्राधिकरण स्थापित नहीं करते हैं, प्रत्येक टूल अनुमति को बाधित नहीं करते हैं, या किसी स्वीकृत कार्य के डाउनस्ट्रीम कार्य को बाध्य नहीं करते हैं। एप्लिकेशन में उन सीमाओं की जांच करें और वैध एकीकरण और पहुंच का ध्यान रखें।
क्या एलएलएम रेलिंग पर्याप्त हैं?
उन्हें एक पहचान या नीति परत के रूप में उपयोग करें और उनके झूठे अवरोधों और चूकों का परीक्षण करें। प्रवर्तनीय एप्लिकेशन या डाउनस्ट्रीम नियंत्रणों में प्राधिकरण, संसाधन सीमाएं और परिणामी कार्रवाई जांच रखें।
यदि स्कैनर कोई विफलता की रिपोर्ट नहीं करता तो क्या होगा?
यह उस दौर में मामलों, कॉन्फ़िगरेशन और टिप्पणियों के बारे में सबूत है। परीक्षण किए गए दायरे को सुरक्षित रखें और एप्लिकेशन-विशिष्ट सीमाओं के लिए परिदृश्य जोड़ें; एक साफ़ स्कैन को सार्वभौमिक सुरक्षा दावे में न बदलें।
यह रूब्रेक्स सगाई में कैसे फिट बैठता है?
एक स्कोप्ड एआई सास सुरक्षा मूल्यांकन सहमत पहुंच, उपकरण और दुरुपयोग-नियंत्रण प्रश्नों की जांच कर सकता है और एक पुन: परीक्षण रिकॉर्ड के साथ निष्कर्ष दे सकता है। सुरक्षा आकलन को 10-कार्य-दिवसीय एआई विश्वसनीयता स्प्रिंट से अलग से लागू किया जाता है।
स्रोत और आगे पढ़ना
इस ब्रीफिंग के पीछे प्राथमिक स्रोत। किसी स्रोत के निष्कर्ष उसकी अपनी अध्ययन स्थितियों पर लागू होते हैं; arXiv पर प्रकाशन सहकर्मी समीक्षा स्थापित नहीं करता है।
- OWASP वेब अनुप्रयोगों के लिए स्वचालित खतरे ओडब्ल्यूएएसपी · जीवित संदर्भ · सुरक्षा मार्गदर्शनसमीक्षित: परियोजना अवलोकन और दायरा. पहुँच गया 3 अक्टू॰ 2026.
- LLM10:2025 असीमित उपभोग ओडब्ल्यूएएसपी · 2025 · सुरक्षा मार्गदर्शनसमीक्षित: जोखिम विवरण और संसाधन-नियंत्रण मार्गदर्शन. पहुँच गया 3 अक्टू॰ 2026.
- एलएलएम प्रॉम्प्ट इंजेक्शन प्रिवेंशन चीट शीट ओडब्ल्यूएएसपी · जीवित संदर्भ · सुरक्षा मार्गदर्शनसमीक्षित: हमले की सीमाएँ, स्तरित नियंत्रण और सीमाएँ. पहुँच गया 3 अक्टू॰ 2026.
- एलएलएम06:2025 अत्यधिक एजेंसी ओडब्ल्यूएएसपी · 2025 · सुरक्षा मार्गदर्शनसमीक्षित: टूल स्कोप, अनुमतियाँ और डाउनस्ट्रीम प्राधिकरण. पहुँच गया 3 अक्टू॰ 2026.
- API4:2023 अप्रतिबंधित संसाधन खपत ओडब्ल्यूएएसपी · 2023 · सुरक्षा मार्गदर्शनसमीक्षित: संसाधन सीमाएँ और रोकथाम मार्गदर्शन. पहुँच गया 3 अक्टू॰ 2026.
प्रश्न या सुधार? रूब्रेक्स को लिखें. हमारा संपादकीय दृष्टिकोण पढ़ें.