सबसे कठिन AI सुरक्षा समस्याएँ अब मॉडल के बाहर जीवित हैं

यह 2026 OWASP Top 10 for LLM Applications उत्पादन AI की परिपक्वता पर एक महत्वपूर्ण दृष्टिकोण प्रदान करता है। यह एक निर्णायक बदलाव को दर्शाता है: उद्योग सैंडबॉक्स से आगे बढ़ रहा है और वास्तविक‑विश्व एकीकरण की जटिलताओं से जूझ रहा है।

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

OWASP Top 10 रैंकिंग इस विकास को प्रतिबिंबित करती है। “Excessive Agency” छठे स्थान से तीसरे स्थान पर चढ़ गया है, जबकि “Unbounded Consumption” छठे स्थान तक पहुंच गया है। इसके विपरीत, “Improper Output Handling” दसवें स्थान पर गिर गया है।

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

सुरक्षा चुनौती अब केवल मॉडल का मूल्यांकन करना नहीं रह गई है; यह अनुमान के बाद क्या होता है, उसकी सीमाओं को परिभाषित करना है। आपका आर्किटेक्चर तय करता है कि क्या कोई भ्रम केवल पाठ में रहता है या अनधिकृत डेटाबेस परिवर्तन के रूप में प्रकट होता है।

रैंकिंग नुकसान के अनुसार होती है

OWASP ने 7,714 घटनाओं का उपयोग किया, जिसमें 75% सामुदायिक सहमति द्वारा संचालित था, और 25% अनुभवजन्य घटना डेटा द्वारा. यह प्रमाण आधार प्राथमिकताओं के वास्तविक पुनः क्रमबद्धन को मजबूर किया।

“Excessive Agency” बढ़ा क्योंकि उत्पादन पर्यावरण की वास्तविकता सिद्धांत से मिल गई। संगठन स्वायत्त क्षमताओं की तैनाती को आवश्यक नियंत्रण प्लेन स्थापित करने से तेज़ी से बढ़ा रहे हैं। महत्वपूर्ण कमजोरी केवल मॉडल द्वारा प्रदान किए गए उत्तर में नहीं, बल्कि उस उत्तर के निष्पादन के अधिकार संदर्भ में है।

“Improper Output Handling” अभी भी एक चिंता है, लेकिन DevOps टीमों ने स्कीमा वैधता और पैरामीटरयुक्त क्वेरीज के माध्यम से डाउनस्ट्रीम सिंक्स को सुरक्षित करने की क्षमता में परिपक्वता हासिल की है। ये स्थापित एप्लिकेशन सुरक्षा प्रथाएँ हैं।

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

हर टूल को एक उजागर क्षमता के रूप में मानें

कई टीमें टूल परिभाषाओं को केवल एकीकरण पाइपलाइन मानती हैं। यह एक काफी हँसी का और बुनियादी त्रुटि है। हर टूल, कनेक्टर, या API एन्डपॉइंट AI एप्लिकेशन के प्रभाव क्षेत्र को विस्तारित करता है।

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

आपको न्यूनतम विशेषाधिकार सिद्धांत को लागू करना चाहिए:

• इंटरफ़ेस को सीमित करें: एजेंट को सामान्य‑उद्देश्य कनेक्टरों के बजाय केवल‑पढ़ने योग्य टूल प्रदान करें।
• स्कोप्ड संदर्भ: अनुरोधों को उपयोगकर्ता की OAuth‑स्कोप्ड पहचान के भीतर निष्पादित करें।
• Policy Enforcement Points (PEP): मॉडल और डाउनस्ट्रीम सिस्टमों के बीच अनिवार्य मिडलवेयर के रूप में प्राधिकरण लॉजिक लागू करें। प्रत्येक कार्रवाई को निष्पादन से पहले नीति के विरुद्ध सत्यापित किया जाना चाहिए।
• Human-in-the-loop (HITL): उन संचालन के लिए स्पष्ट अनुमोदन आवश्यक करें जो उलटने में कठिन हैं या उच्च सामग्री प्रभाव रखते हैं।

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

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

प्रत्येक स्वायत्त रन को एक कठोर रोक की आवश्यकता है

“Unbounded Consumption” बढ़ गया है क्योंकि अनुरोध मात्रा संसाधन जोखिम के लिए अपर्याप्त मीट्रिक है। एकल, संक्षिप्त प्रॉम्प्ट एक पुनरावर्ती, संसाधन‑गहन टूल कॉल श्रृंखला को ट्रिगर कर सकता है। मीटर तब तक नहीं रुकता जब तक एजेंट समाप्त नहीं हो जाता।

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

ऑपरेशनल स्कोप को समान कठोरता की आवश्यकता होती है। निर्धारित करें कि एजेंट अधिकतम कितनी रिकॉर्ड्स संशोधित कर सकता है और कार्य प्रसार की सीमाएँ तय करें। यदि आपके आर्किटेक्चर में एक निर्धारक “स्टॉप” तंत्र नहीं है, तो आप मूल रूप से अधिकार को बिना उसकी सीमा निर्धारित किए सौंप रहे हैं।

गलत उत्तर के लिए बनाएं

सिस्टम इंजीनियरिंग ने लंबे समय से अंतर्निहित रूप से अविश्वसनीय घटकों को सुरक्षित करने के लिए लचीले आर्किटेक्चर पर भरोसा किया है। हम घटक विफलता और नेटवर्क अस्थिरता की भविष्यवाणी करते हैं; सुरक्षा इस अनुमान से उत्पन्न होती है, न कि पूर्णता के भ्रम से। LLMs को भी वही आर्किटेक्चरल अनुशासन चाहिए।

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

हम अब प्रॉम्प्ट इंजेक्शन को एक भेद्यता से कम और भौतिक नियम के रूप में देखते हैं। यह हमेशा मौजूद रहेगा। तथ्य यह है कि मॉडल स्वयं सुरक्षा‑संबंधी प्रश्नों के प्रभावी निर्णयकर्ता नहीं हो सकते। एक वास्तविक एजेंटिक प्रोजेक्ट में मैं लगभग 100 स्वचालित “रेड टीम” परीक्षण चलाता हूँ। हम सुनिश्चित करते हैं कि हम सभी को पास कर लें। लेकिन हम यह मॉडल के बाहर कठोर नियंत्रण बनाकर करते हैं। हम इसे बंद कर सकते हैं और केवल मॉडल के पास/फ़ेल दर देख सकते हैं। सबसे पुराना, सबसे कमजोर मॉडल 17% समय में फेल होता है। सबसे नया, सबसे बड़ा मॉडल 2% समय में फेल होता है। शानदार प्रगति, है ना? लेकिन क्या 98% पर्याप्त है जब हर विफलता का मतलब संवेदनशील डेटा का रिसाव है? बिल्कुल भी नहीं।

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

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