साइबर सुरक्षा में एआई — जब हमलावरों और रक्षकों दोनों के पास मॉडल होते हैं तो वास्तव में क्या बदलता है

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

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

इस विषय के आसपास वर्तमान में सामने आ रहा सबसे मजबूत सार्वजनिक सामग्री एक कारण से लगातार उन्हीं विषयों पर केंद्रित है। माइक्रोसॉफ्ट खतरे के प्राथमिक निदान (थ्रेट ट्रायज), बड़े पैमाने पर फ़िशिंग, और रक्षकों के लिए स्वायत्त सहायता पर ध्यान केंद्रित करता है। गूगल विश्लेषकों के श्रम को कम करने, जांच और पता लगाने की इंजीनियरिंग को गति देने, और पहचान-प्रधान अभियानों से बचाव करने पर जोर देता है। आईबीएम शासन, पहुँच नियंत्रण, डेटा सुरक्षा, और जब सुरक्षा एआई का व्यापक रूप से उपयोग किया जाता है और ठीक से नियंत्रित किया जाता है तो उससे होने वाली मापनीय बचत पर अधिक ध्यान केंद्रित करता है। OWASP, NIST, CISA, और MITRE उस हिस्से को जोड़ते हैं जिसे विक्रेता मार्केटिंग अक्सर कमज़ोर कर देती है: प्रॉम्प्ट इंजेक्शन, डेटा और मॉडल पॉइज़निंग, सप्लाई चेन जोखिम, मॉडल-सर्विंग भेद्यताएँ, और नए AI-नेटिव दुरुपयोग के मामले पहले से ही इतने वास्तविक हैं कि उनके लिए औपचारिक ढांचे और साझा वर्गीकरण की आवश्यकता है। (गूगल क्लाउड)

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

साइबर सुरक्षा में एआई का वास्तविक अर्थ क्या है

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

यहीं पर बहुत सारा सार्वजनिक लेखन अभी भी गलत हो जाता है। एक मॉडल जो साधारण अंग्रेज़ी में एक SIEM अलर्ट की व्याख्या करता है, वह एक ऐसे सिस्टम के बराबर नहीं है जो विश्वसनीय डिटेक्शन उत्पन्न कर सकता है। एक मॉडल जो एक अच्छी KQL क्वेरी लिखता है, वह एक ऐसे मॉडल के समान नहीं है जो लॉग, IAM नीति, और क्लाउड कंट्रोल-प्लेन इवेंट्स में एक संदिग्ध पहचान पथ को मान्य कर सकता है। और एक एआई असिस्टेंट जो एक पेनेटस्टर को अगला कदम सुझाता है, वह एक ऐसे प्लेटफ़ॉर्म के समान नहीं है जो प्रमाणीकृत स्थिति बनाए रख सकता है, वर्कफ़्लो में पिवट कर सकता है, शोषण क्षमता को साबित कर सकता है, और एक पुन: उत्पन्न करने योग्य रिपोर्ट तैयार कर सकता है। यह अंतर वैचारिक नहीं है। यह परिचालन संबंधी है। यह निर्धारित करता है कि सिस्टम कार्यभार को कम करता है या केवल उसका स्वरूप बदलता है। (माइक्रोसॉफ्ट लर्न)

इस क्षेत्र के बारे में सोचने का सबसे उपयोगी तरीका है "भाषाई सुविधा" को "सुरक्षा क्षमता" से अलग करना। प्राकृतिक-भाषा इंटरफ़ेस मूल्यवान होते हैं। ये जूनियर विश्लेषकों को डेटा लेक की जांच करने, संदिग्ध स्क्रिप्ट का अनुवाद करने, या डिटेक्शन लॉजिक को तेजी से समझने में मदद करते हैं। माइक्रोसॉफ्ट स्पष्ट रूप से सिक्योरिटी कोपायलट को खतरों की जांच और उन्हें दूर करने, KQL क्वेरी बनाने, और संदिग्ध स्क्रिप्ट का विश्लेषण करने के इर्द-गिर्द तैयार करता है। गूगल भी इसी तरह प्राकृतिक भाषा में पूछताछ, डिटेक्शन-रूल निर्माण, प्लेबुक निर्माण, और SecOps में घटनाओं के त्वरित समाधान को उजागर करता है। ये वास्तविक लाभ हैं। लेकिन ये पूरी कहानी नहीं है, और इन्हें स्वायत्त सुरक्षा क्षमता के साथ भ्रमित नहीं किया जाना चाहिए। (माइक्रोसॉफ्ट लर्न)

हमलावर पक्ष पर भी यही अंतर लागू होता है। आज का बाजार अभी भी "AI पेंटस्ट टूल" शब्द का ढीला-ढाला उपयोग करता है, लेकिन तकनीकी रूप से प्रासंगिक सार्वजनिक सामग्री लगातार एक सख्त परिभाषा की ओर बढ़ रही है: एक वास्तविक प्रणाली को पहचानने योग्य पैठ-परीक्षण कार्य करना चाहिए, संदर्भ बनाए रखना चाहिए, स्टेटफुल अनुप्रयोगों को संभालना चाहिए, हमले के मार्गों पर तर्क करना चाहिए, और सुंदर सारांश के बजाय ठोस साक्ष्य प्रस्तुत करने चाहिए। यह रूपरेखा विशेष रूप से महत्वपूर्ण है क्योंकि कई टीमें अब यह आकलन कर रही हैं कि क्या एआई केवल पहचान और प्रतिक्रिया तक ही सीमित है, या क्या इस पर स्टेजिंग और प्रोडक्शन-जैसे वातावरण में एक्सपोज़र को लगातार मान्य करने के लिए भी भरोसा किया जाना चाहिए। (पेनलिजेंट)

नीचे दी गई तालिका श्रेणियों को अलग करने का एक व्यावहारिक तरीका है।

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

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

जहाँ एआई पहले से ही वास्तविक रक्षात्मक मूल्य प्रदान करता है

साइबर सुरक्षा में एआई का सबसे कम विवादास्पद मूल्य गति है। यह उत्पाद-विपणन की अस्पष्ट समझ में 'गति' नहीं है, बल्कि उन क्षेत्रों में गति है जहाँ रक्षक लगातार अतिभारित रहते हैं: अलर्ट ट्राइएज, जांच सहायता, संबंधित घटनाओं का सहसंबंध, और विश्लेषकों के दोहराव वाले कार्यों का संपीड़न। आईबीएम एआई-संचालित सुरक्षा को सुरक्षा टीमों की गति, सटीकता और उत्पादकता में सुधार करने का एक तरीका बताता है, और यह भी बताता है कि एआई-संचालित जोखिम विश्लेषण उच्च-विश्वासनीय सारांश तैयार कर सकता है और अलर्ट जांच तथा प्राथमिकता निर्धारण को तेज कर सकता है। गूगल भी SecOps के लिए इसी तरह का तर्क देता है, यह बताते हुए कि जेमिनी कैसे थकाऊ काम को कम कर सकता है, सुरक्षा डेटा के साथ इंटरैक्शन को सरल बना सकता है, और टीमों को डिटेक्शन बनाने, प्लेबुक बनाने और खतरों की जांच तेजी से करने में मदद कर सकता है। (आईबीएम)

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

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

मूल्य का अगला स्तर अनुक्रम का पता लगाना है। कई महत्वपूर्ण हमले इसलिए छिपे नहीं होते हैं क्योंकि कोई एक घटना अदृश्य होती है। वे इसलिए चूक जाते हैं क्योंकि सार्थक पैटर्न समय, पहचानों, एपीआई, सेवाओं और होस्ट्स में फैला होता है। AWS का गार्डड्यूटी एक्सटेंडेड थ्रेट डिटेक्शन इस बात का एक अच्छा उदाहरण है कि क्लाउड रक्षक यहां एआई को कैसे परिचालित कर रहे हैं। AWS बताता है कि AI और ML का उपयोग कई संकेतों को एक साथ जोड़कर हमले की अनुक्रम-खोज के निष्कर्ष निकालने के लिए किया जाता है, जो विशेषाधिकार खोज, API हेरफेर, स्थायी गतिविधि और डेटा निकासी तक फैले हो सकते हैं, साथ ही प्राकृतिक भाषा में सारांश और ATT&CK-अनुरूप सुधारात्मक मार्गदर्शन भी प्रदान करता है। यह बिल्कुल उस तरह का कार्य है जहाँ फैली हुई टेलीमेट्री में पैटर्न मान्यता उपयोगी होती है। (अमेज़न वेब सर्विसेज़, इंक.)

पहचान रक्षा एक और ऐसा क्षेत्र है जहाँ एआई पहले से ही जायज़ ठहराया गया है, आंशिक रूप से इसलिए क्योंकि खतरे का परिदृश्य वहाँ बहुत आक्रामक रूप से आगे बढ़ गया है। गूगल क्लाउड ने मंडiant के नवीनतम एम-ट्रेंड्स निष्कर्षों का हवाला देते हुए बताया कि 2024 में चोरी हुए क्रेडेंशियल, फ़िशिंग, ब्रूट-फ़ोर्स, और अन्य पहचान-आधारित तरीकों ने 37 प्रतिशत सफल उल्लंघनों के लिए जिम्मेदार थे। यह संख्या मैलवेयर-प्रथम सोच से हटकर पहचान के दुरुपयोग, सत्र चोरी, सूचना-चोरों, और विशेषाधिकार के दुरुपयोग की ओर बढ़ रहे व्यापक उद्योग परिवर्तन के अनुरूप है। इस माहौल में, एआई अपनी उपयोगिता तब सिद्ध करता है जब यह सुरक्षा टीमों को एक शोर भरी लॉगिन घटना और उपयोगकर्ता, डिवाइस, सत्र, और बाद के व्यवहार से जुड़े एक सार्थक क्रेडेंशियल-जोखिम पैटर्न के बीच अंतर पहचानने में मदद करता है। (गूगल क्लाउड)

वह पहचान परिवर्तन यह भी स्पष्ट करता है कि AI स्वयं SOC डैशबोर्ड के बाहर भी क्यों दिन-प्रतिदिन अधिक मूल्यवान होता जा रहा है। यह एक्सेस समीक्षा, गैर-मानवीय पहचान शासन, विशेषाधिकार प्राप्त खाता विश्लेषण और सत्र विसंगति पहचान में उपयोगी है। IBM की 2025 ब्रीच-लागत सामग्री इस बात पर जोर देती है कि AI-संबंधी घटनाओं का सामना करने वाले संगठनों में अक्सर उचित AI एक्सेस नियंत्रण का अभाव था, और यह स्पष्ट रूप से पहचान सुरक्षा और आधुनिक फिशिंग-प्रतिरोधी प्रमाणीकरण को व्यावहारिक जोखिम में कमी से जोड़ती है। यदि कोई संगठन पहचान की सीमाओं को कड़ा किए बिना AI एजेंट, मॉडल-सर्विंग एंडपॉइंट या रिट्रीवल वर्कफ़्लो जोड़ता है, तो वह सुरक्षा का आधुनिकीकरण नहीं कर रहा है। यह उन तरीकों की संख्या बढ़ा रहा है जिनसे एक समझौता किया गया टोकन एक बड़ी घटना बन सकता है। (आईबीएम)

तीसरा परिपक्व उपयोग मामला डेटा सुरक्षा है। इसे आकर्षक मॉडल डेमो जितना ध्यान नहीं मिलता, लेकिन यह अधिक महत्वपूर्ण है। IBM की 2025 ब्रीच रिपोर्ट वर्तमान क्षण को "एआई पर्यवेक्षण अंतराल" के रूप में प्रस्तुत करती है, यह उजागर करते हुए कि बिना शासित एआई सिस्टम में सेंध लगने की अधिक संभावना होती है और जब ऐसा होता है तो यह अधिक महंगा पड़ता है। वही रिपोर्ट कहती है कि एआई-संबंधी सुरक्षा घटना की सूचना देने वाले 97 प्रतिशत संगठनों में उचित एआई एक्सेस नियंत्रण का अभाव था, जबकि 63 प्रतिशत के पास एआई का प्रबंधन करने या शैडो एआई को रोकने के लिए एआई गवर्नेंस नीतियां नहीं थीं। ये आंकड़े बताते हैं कि साइबर सुरक्षा में एआई को केवल डिटेक्शन मॉडल तक ही क्यों सीमित नहीं किया जा सकता। इसमें डेटा डिस्कवरी, वर्गीकरण, एक्सेस नियंत्रण, कुंजी प्रबंधन, और इस बात की दृश्यता शामिल होनी चाहिए कि एआई वर्कलोड वास्तव में कहाँ चल रहे हैं। (आईबीएम)

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

हमलावर को भी लाभ होता है, और इससे आधार रेखा बदल जाती है।

साइबर सुरक्षा में एआई के बारे में कोई भी ईमानदार लेख यह स्पष्ट रूप से कहना होगा: केवल बचाव करने वालों को ही बढ़त नहीं मिल रही है। क्राउडस्ट्राइक की 2025 ग्लोबल थ्रेट रिपोर्ट में कहा गया कि GenAI-संचालित धोखाधड़ी बढ़ रही थी, वाशिंग (vishing) में 442 प्रतिशत की वृद्धि दर्ज की गई, और मैलवेयर-मुक्त, पहचान-आधारित हमलों में व्यापक वृद्धि का वर्णन किया गया। गूगल क्लाउड की थ्रेट-इंटेलिजेंस सामग्री भी यही कहती है कि राज्य-समर्थित कर्ता और साइबर अपराधी हमले के जीवनचक्र में एआई को एकीकृत कर रहे हैं, जो केवल उत्पादकता लाभ से परे है। माइक्रोसॉफ्ट की डिजिटल डिफेंस रिपोर्ट 2025 में एक केस स्टडी शामिल है जिसमें एक आपराधिक नेटवर्क ने एआई सुरक्षा नियंत्रणों को बायपास करने और अपमानजनक एआई-निर्मित छवियां उत्पन्न करने के लिए चोरी की गई एपीआई कुंजियों का फायदा उठाया। एआई केवल एक ढाल नहीं है। यह दुरुपयोग, पैमाने, धोखे और प्रयोग के लिए एक बल गुणक है। (क्राउडस्ट्राइक)

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

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

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

यही कारण है कि "एआई ने सब कुछ बदल दिया" यह बात एक ही समय में गलत और दिशात्मक रूप से उपयोगी है। गलत, क्योंकि हमलावर अभी भी परिचित कमजोरियों के माध्यम से जीतते हैं: कमजोर क्रेडेंशियल, अत्यधिक विशेषाधिकार प्राप्त पहुंच, उजागर प्रबंधन सतहें, असुरक्षित डेसिरियलाइज़ेशन, टूटी हुई सत्र हैंडलिंग, और खराब संपत्ति दृश्यता। उपयोगी, क्योंकि एआई हमलावरों को उन कमजोरियों को तेजी से खोजने और उन्हें जोड़ने में मदद करता है, और ऐसा करते समय उन्हें अधिक विश्वसनीय दिखने में मदद करता है। FortiGate डिवाइसों के खिलाफ AI-सहायक हमलों पर AWS का लेख ठीक यही बात कहता है: अभियान अभी भी उजागर इंटरफेस, कमजोर क्रेडेंशियल और सिंगल-फैक्टर ऑथेंटिकेशन पर निर्भर था। AI ने मूल बातों को प्रतिस्थापित नहीं किया। इसने खराब मूल बातों के दुरुपयोग को तेज कर दिया। (अमेज़न वेब सर्विसेज़, इंक.)

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

एआई सिस्टम अब हमले की सतह का हिस्सा हैं।

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

CISA, NSA, FBI, और भागीदार एजेंसियों ने AI सिस्टम को सुरक्षित रूप से तैनात करने पर अपने संयुक्त मार्गदर्शन में यही बात कही है। उनके 2024 के मार्गदर्शन में कहा गया है कि तेज़ी से अपनाने से AI क्षमताएं दुर्भावनापूर्ण अभिनेताओं के लिए मूल्यवान लक्ष्य बन जाती हैं, जिसमें वे हमलावर भी शामिल हैं जो दुर्भावनापूर्ण उद्देश्यों के लिए तैनात AI सिस्टम को अपने पक्ष में करने की कोशिश कर सकते हैं। मार्गदर्शन में स्पष्ट रूप से कहा गया है कि संगठनों को पारंपरिक आईटी सर्वोत्तम प्रथाओं को एआई सिस्टम पर लागू करना चाहिए, लेकिन यह खतरे के मॉडल, शासन, मॉडल-स्रोत समीक्षा, परिनियोजन से पहले सत्यापन, और न्यूनतम विशेषाधिकार और गहन रक्षा के साथ सख्त पहुँच नियंत्रण और एपीआई सुरक्षा पर भी जोर देता है। दूसरे शब्दों में, एआई परिनियोजन सिर्फ एक और एप्लिकेशन रोलआउट नहीं है। यह एक विशेषाधिकार प्राप्त प्रणाली है जो अक्सर एक ही समय में संवेदनशील डेटा, बाहरी सामग्री और स्वचालित क्रियाओं को छूती है। (संयुक्त राज्य युद्ध विभाग)

यही कारण है कि यूके NCSC और अंतरराष्ट्रीय भागीदारों का सुरक्षित-एआई-विकास मार्गदर्शन 2026 में भी उपयोगी बना हुआ है। यह एआई सुरक्षा को चार जीवनचक्र क्षेत्रों के चारों ओर संरचित करता है: सुरक्षित डिज़ाइन, सुरक्षित विकास, सुरक्षित परिनियोजन, और सुरक्षित संचालन और रखरखाव। यह विशेष रूप से खतरे का मॉडलिंग, आपूर्ति-श्रृंखला सुरक्षा, घटना प्रबंधन, बुनियादी ढांचे और मॉडलों को समझौते से बचाने, और उपयोगकर्ताओं के लिए सही काम करना आसान बनाने का उल्लेख करता है। ये उबाऊ वाक्यांश तब तक लगते हैं जब तक आप यह याद नहीं करते कि आधुनिक एआई सिस्टम वास्तव में क्या करते हैं: टूल कॉल करना, अविश्वसनीय सामग्री का उपभोग करना, प्रॉम्प्ट संग्रहीत करना, एम्बेडिंग संभालना, टोकन का प्रबंधन करना, और कभी-कभी प्रोडक्शन सिस्टम में कार्रवाई करना। एक बार जब आप पूरा वर्कफ़्लो देख लेते हैं, तो जीवनचक्र अनुशासन की आवश्यकता वैकल्पिक नहीं लगती। (एनसीएससी)

OWASP का 2025 LLMs और GenAI एप्लिकेशनों के लिए टॉप 10, उस जीवनचक्र दृष्टिकोण को उन जोखिमों में अनुवादित करने में मदद करता है जिनके साथ इंजीनियर काम कर सकते हैं। यह परियोजना प्रॉम्प्ट इंजेक्शन, संवेदनशील जानकारी का खुलासा, आपूर्ति-श्रृंखला जोखिम, डेटा और मॉडल पॉइज़निंग, अनुचित आउटपुट हैंडलिंग, अत्यधिक एजेंसी, सिस्टम प्रॉम्प्ट लीकेज, वेक्टर और एम्बेडिंग कमजोरियों, भ्रामक जानकारी, और अनियंत्रित खपत को उजागर करती है। ये जोखिम इसलिए महत्वपूर्ण हैं क्योंकि वे उन जगहों का वर्णन करते हैं जहाँ आधुनिक एआई अनुप्रयोग नियमित रूप से उन सीमाओं को धुंधला करते हैं जिन्हें पुराने एप्लिकेशन-सुरक्षा मॉडल अधिक स्पष्ट मानते थे: निर्देश बनाम डेटा, पुनःप्राप्ति बनाम विश्वास, मॉडल आउटपुट बनाम निष्पादन योग्य कार्रवाई, और जानकारी तक पहुंच बनाम उस पर कार्रवाई करने का अधिकार। (OWASP जेन एआई सुरक्षा परियोजना)

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

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

सिस्टम प्रॉम्प्ट लीकेज और वेक्टर या एम्बेडिंग की कमजोरियाँ यह और साबित करती हैं कि एआई सिस्टम पुरानी श्रेणियों में ठीक से फिट नहीं होते हैं। एक लीक हुआ सिस्टम प्रॉम्प्ट छिपी हुई निर्देशों, व्यावसायिक नियमों, टूल की क्षमताओं, या रक्षा मान्यताओं को प्रकट कर सकता है। एम्बेडिंग या रिट्रीवल लेयर्स में कमजोरियाँ मॉडल द्वारा देखे जाने वाले ज्ञान को भ्रष्ट कर सकती हैं, रैंकिंग को विषाक्त कर सकती हैं, या विश्वसनीय संदर्भों में दुर्भावनापूर्ण सामग्री की तस्करी कर सकती हैं। NIST की GenAI प्रोफ़ाइल यहाँ उपयोगी है क्योंकि यह इस बात पर ज़ोर देती है कि संगठन जीवनचक्र के चरण, मॉडल और सिस्टम स्तर, अनुप्रयोग स्तर, और पारिस्थितिकी तंत्र स्तर के अनुसार जोखिम के बारे में सोचें। वह व्यापक दृष्टिकोण आवश्यक है क्योंकि कई AI विफलताएँ किसी एक स्थान पर नहीं होतीं। वे डेटा, मॉडल, पुनर्प्राप्ति, अनुमतियों और उपयोगकर्ता वर्कफ़्लो के बीच की परस्पर क्रिया से उत्पन्न होती हैं। (OWASP जेन एआई सुरक्षा परियोजना)

MITRE ATLAS खतरे-सूचित-रक्षा के दृष्टिकोण से इसी बात को समझाने में मदद करता है। ATLAS, AI-सक्षम प्रणालियों के लिए प्रतिपक्षी की रणनीतियों और तकनीकों का एक ज्ञान-भंडार है, और MITRE का 2025 सुरक्षित AI कार्य बताता है कि AI को अपनाने से खतरों का दायरा बढ़ जाता है और नई कमजोरियाँ सामने आती हैं, जिसके लिए घटना साझाकरण, सत्यापनीय AI कमजोरियों की खोज, और AI रेड-टीमिंग विधियों की आवश्यकता होती है। यह इस बात का सबसे स्पष्ट संकेतों में से एक है कि एआई सुरक्षा "दिलचस्प शोध विषय" के चरण से आगे बढ़ चुकी है। परिपक्व रक्षकों को अब एआई सिस्टम के लिए खतरों और साइबर अभियानों में एआई के दुर्भावनापूर्ण उपयोग के लिए एक सामान्य भाषा की आवश्यकता है, न कि केवल "अपने मॉडलों की निगरानी करें" जैसी सामान्य सलाह की। (माइट्रे एटलस)

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

व्यावहारिक रूप से OWASP-शैली का जोखिम मानचित्र

जोखिम क्षेत्र	उत्पादन में यह कैसा दिखता है	यह क्यों मायने रखती है
प्रॉम्प्ट इंजेक्शन	दस्तावेज़ों, टिकटों, वेबसाइटों, ईमेल, लॉग या उपयोगकर्ता संदेशों में छिपी या स्पष्ट निर्देश मॉडल के व्यवहार को बदलते हैं।	अविश्वसनीय सामग्री को अनधिकृत कार्यों या डेटा लीक में बदल सकता है।
संवेदनशील जानकारी का प्रकटीकरण	प्रॉम्प्ट्स, संदर्भ विंडो, पुनर्प्राप्ति परिणाम, लॉग या आउटपुट रहस्य या विनियमित डेटा प्रकट करते हैं।	प्रमाण-पत्र, व्यक्तिगत रूप से पहचान योग्य जानकारी, व्यापार रहस्य, या सिस्टम निर्देश लीक हो सकते हैं।
आपूर्ति श्रृंखला	मॉडल्स, प्लगइन्स, एजेंट टूल्स, रजिस्ट्रियाँ, पाइथन पैकेज, मॉडल रिपॉजिटरी और कंटेनर इमेज समझौता किए गए या कमजोर रूप से जांचे गए हैं।	हम हमलावरों को मुख्य द्वार के बजाय निर्भरताओं के माध्यम से प्रवेश करने देते हैं।
डेटा और मॉडल विषाक्तन	प्रशिक्षण, फाइन-ट्यूनिंग, या पुनःप्राप्ति कोर्पोरा को हेरफेर किया जाता है।	भविष्य के परिणामों को दूषित करता है और बैकडोर या प्रणालीगत पक्षपात पेश कर सकता है।
अत्यधिक एजेंसी	मजबूत नियंत्रणों के बिना एजेंट बहुत व्यापक रूप से कार्य कर सकते हैं।	मॉडल की गलतियों को परिचालन घटनाओं में बदलता है
सिस्टम प्रॉम्प्ट रिसाव	छिपी हुई निर्देशें उजागर की गई हैं।	डिज़ाइन की धारणाओं, आंतरिक नियमों और संभावित बाईपास मार्गों का खुलासा करता है।
वेक्टर और एम्बेडिंग की कमजोरियाँ	पुनर्प्राप्ति रैंकिंग या ज्ञान इंजेक्शन अप्रत्याशित रूप से व्यवहार करता है।	आइए खराब डेटा निर्णय समय पर मॉडल की "जानकारी" को विकृत करे।
असीमित खपत	क्वेरीज़ या वर्कफ़्लो अनियंत्रित उपयोग को बढ़ावा देते हैं।	लागत, उपलब्धता और डिनायल-ऑफ़-सर्विस जोखिम उत्पन्न करता है।

यह तालिका OWASP 2025 LLM जोखिम सेट का सीधा इंजीनियरिंग रीडिंग है, साथ ही NIST से जीवनचक्र और शासन की रूपरेखा तथा सरकारी साझेदारों से सुरक्षित-परिनियोजन मार्गदर्शन भी शामिल है। महत्वपूर्ण बात लेबल याद करने में नहीं है, बल्कि यह समझने में है कि ये जोखिम सीमाओं पर स्थित हैं — मॉडल और टूल, प्रॉम्प्ट और नीति, डेटा और कार्रवाई, पुनर्प्राप्ति और विश्वास के बीच।OWASP जेन एआई सुरक्षा परियोजना)

एआई स्टैक साधारण बग्स को असाधारण परिणामों के साथ जारी कर रहा है।

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

Ollama MCP सर्वर CVE-2025-15063 पर विचार करें। NVD इसे एक कमांड-इंजेक्शन रिमोट कोड निष्पादन भेद्यता के रूप में वर्णित करता है। एक्ज़ीक्यूट एसिंक् अमलीकरण, प्रमाणीकरण के बिना शोषित किया जा सकता है क्योंकि उपयोगकर्ता द्वारा प्रदान किए गए इनपुट को सिस्टम कॉल में उपयोग करने से पहले ठीक से सत्यापित नहीं किया गया था। उस बग श्रेणी में कुछ भी रहस्यमयी नहीं है। यह उस तरह की समस्या है जिससे सुरक्षा टीमें वर्षों से निपटती आ रही हैं। लेकिन एआई संदर्भ में, इसके निहितार्थ व्यापक हैं क्योंकि MCP-शैली की प्रणालियाँ अक्सर ठीक उसी उद्देश्य से मौजूद होती हैं कि मॉडल को उपकरणों और निष्पादन पथों से जोड़ा जा सके। वहाँ एक बग केवल UI को क्रैश नहीं करता। यह एक ऑर्केस्ट्रेशन लेयर को हमलावर-नियंत्रित पुल में बदल सकता है। (एनवीडी)

Ollama की CVE-2025-63389 एक अलग लेकिन समान रूप से महत्वपूर्ण कहानी बताती है। NVD v0.12.3 से पहले और इसमें शामिल API एंडपॉइंट्स में एक गंभीर प्रमाणीकरण-बाईपास समस्या का वर्णन करता है, जहाँ कई मॉडल-प्रबंधन एंडपॉइंट्स आवश्यक प्रमाणीकरण के बिना उजागर थे, जिससे अनधिकृत संचालन संभव हो गया। एक बार फिर, मूल सीख परिचित है: यदि आपका कंट्रोल प्लेन पहुँच योग्य है और उसकी उचित प्रमाणीकरण नहीं हुई है, तो आपके पास कंट्रोल प्लेन नहीं है। एआई सेटिंग में, इसका मतलब अनधिकृत मॉडल पुल, मॉडल परिवर्तन, सर्विंग व्यवहार में हेरफेर, या व्यापक बुनियादी ढांचे की उन मान्यताओं तक अप्रत्यक्ष पहुँच हो सकता है, जिन्हें टीमें गलती से "आंतरिक" समझती हैं। (एनवीडी)

CVE-2025-51471 के रूप में ट्रैक की गई टोकन-एक्सपोज़र समस्या यह दर्शाती है कि सूक्ष्म कार्यान्वयन विवरण कैसे सुरक्षा सीमाएँ बन सकते हैं। NVD के अनुसार Ollama 0.6.7 ने एक दुर्भावनापूर्ण माध्यम से क्रॉस-डोमेन टोकन एक्सपोज़र और एक्सेस-कंट्रोल बाईपास की अनुमति दी। क्षेत्र एक में मूल्य WWW-प्रमाणिकरण द्वारा लौटाया गया हेडर /api/पुलकागज़ पर, यह कमांड इंजेक्शन की तुलना में संकीर्ण लगता है। व्यवहार में, यह ठीक उसी प्रकार का प्रमाणीकरण-सतह का बग है जो उन वातावरणों में मायने रखता है जहाँ मॉडल, रजिस्ट्री और पुल वर्कफ़्लो एक विश्वसनीय आपूर्ति श्रृंखला बनाते हैं। यदि श्रृंखला उस बिंदु पर कमजोर है जहाँ क्रेडेंशियल का सौदा किया जाता है या उन्हें पुन: उपयोग किया जाता है, तो मॉडल परत सत्र दुरुपयोग के लिए एक और स्थान बन जाती है।एनवीडी)

हाल की CVEs का vLLM परिवार और भी अधिक खुलासा करता है क्योंकि यह दिखाता है कि प्रदर्शन-उन्मुख एआई अवसंरचना कैसे क्लासिक असुरक्षित-डीसीरियलाइज़ेशन और असुरक्षित-लोडिंग समस्याओं को विरासत में ले सकती है। CVE-2025-32444 Mooncake का उपयोग करके vLLM तैनाती में दूरस्थ कोड निष्पादन का वर्णन करता है क्योंकि पिकलबेस्ड सीरियलाइज़ेशन का उपयोग सभी नेटवर्क इंटरफेस पर सुन रहे असुरक्षित ZeroMQ सॉकेट्स पर किया गया था। CVE-2025-29783 ZMQ/TCP पर असुरक्षित डीसीरियलाइज़ेशन के माध्यम से Mooncake वितरित-होस्ट RCE पथ को कवर करता है। CVE-2024-11041 में RCE का दस्तावेजीकरण करता है मैसेज क्यू से हटाना प्रत्यक्ष के कारण पिकल्स लोड करें प्राप्त सॉकेट डेटा पर। इन किसी भी समस्या के लिए एआई जोखिम के नए सिद्धांत की आवश्यकता नहीं है। इन्हें यह याद रखने की आवश्यकता है कि "वितरित इन्फरेंस स्टैक" अभी भी सॉफ़्टवेयर है, अभी भी शत्रुतापूर्ण इनपुट के संपर्क में है, और अभी भी किताब के सबसे पुराने नियम के अधीन है: अविश्वसनीय डेटा को डी-सीरियलाइज़ न करें। (एनवीडी)

CVE-2025-62164 चित्र को अधिक आधुनिक बनाता है। NVD कहता है कि vLLM संस्करण 0.10.2 से 0.11.1 से पहले तक Completions API में मेमोरी-भ्रष्टता की समस्या थी क्योंकि उपयोगकर्ता द्वारा प्रदान किए गए प्रॉम्प्ट एम्बेडिंग्स लोड किए गए थे। टॉर्च लोड करें() पर्याप्त सत्यापन के बिना, और स्परसे टेन्सर अखंडता जाँचों के संबंध में PyTorch 2.8.0 के व्यवहार परिवर्तन ने सीमा से बाहर के लेखन को संभव बना दिया, जिससे सेवा अस्वीकृति और संभावित रूप से दूरस्थ कोड निष्पादन हुआ। यह एक विशेष रूप से मूल्यवान उदाहरण है क्योंकि यह दिखाता है कि कैसे एआई सिस्टम मॉडल-सर्विंग लॉजिक, फ्रेमवर्क डिफ़ॉल्ट्स, और इनपुट मार्गों की परस्पर क्रिया के माध्यम से जोखिम जमा करते हैं, जिन्हें सुरक्षा टीमें अभी तक पारंपरिक अपलोड या RPC सतहों की तरह उसी कड़ाई से निगरानी नहीं कर रही हैं।एनवीडी)

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

यहाँ एक संक्षिप्त CVE मानचित्र है जिसका उपयोग सुरक्षा टीमें प्राथमिकता निर्धारण के लिए कर सकती हैं।

सीवीई	अवयव	मूल समस्या	सुरक्षा का पाठ
सीवीई-2025-15063	ओल्लामा एमसीपी सर्वर	कमांड इंजेक्शन, बिना प्रमाणीकरण वाला आरसीई	टूल-ब्रिज परतों को सख्त इनपुट सत्यापन और एक्सपोज़र नियंत्रण की आवश्यकता होती है।
CVE-2025-63389	ओल्लामा	एपीआई एंडपॉइंट्स पर प्रमाणीकरण बाईपास	मॉडल-प्रबंधन योजनाओं को प्रमाणीकृत और खंडित किया जाना चाहिए।
CVE-2025-51471	ओल्लामा	क्रॉस-डोमेन टोकन का खुलासा	रजिस्ट्री और पुल वर्कफ़्लो पहचान की सीमाएँ हैं, सुविधाएँ नहीं।
सीवीई-2025-32444	मूनकेक के साथ वीएलएलएम	असुरक्षित ZeroMQ पर पिक्ल, आरसीई	वितरित अनुमान में केवल आंतरिक मान्यताओं पर कभी भरोसा न करें।
CVE-2025-29783	मूनकेक के साथ वीएलएलएम	ZMQ/TCP पर असुरक्षित डीसीरियलाइज़ेशन	मॉडल-सर्विंग क्लस्टर्स को नेटवर्क स्कोपिंग और सीरियलाइज़ेशन हाइजीन की आवश्यकता होती है।
CVE-2024-11041	वीएलएलएम	पिकल्स लोड करें मैसेज क्यू में, आरसीई	क्यू और आईपीसी पथों को बाहरी एपीआई की तरह ही समीक्षा की आवश्यकता है।
सीवीई-2025-62164	वीएलएलएम	अप्रमाणित टॉर्च लोड करें() पथ, मेमोरी भ्रष्टता, संभावित आरसीई	एम्बेडिंग और मॉडल-इनपुट पाथवे सुरक्षा-आवश्यक पार्सिंग सतहें हैं।

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

एक वास्तविक एआई सुरक्षा कार्यक्रम कैसा दिखता है

संगठनों द्वारा की जाने वाली सबसे बड़ी भूल यह है कि वे AI की जवाबदेही निर्धारित करने से पहले AI क्षमता खरीद लेते हैं। सुरक्षित AI परिनियोजन पर 2024 की संयुक्त सरकारी मार्गदर्शिका कहती है कि AI-प्रणाली की साइबर सुरक्षा के लिए जिम्मेदार व्यक्ति वही व्यक्ति होना चाहिए जो सामान्यतः संगठन की साइबर सुरक्षा के लिए जिम्मेदार हो। यह एक धोखे से मजबूत सिफारिश है। इसका मतलब है कि AI टीम केवल इसलिए अलग-अलग मान्यताओं, अलग-अलग अपवादों और अलग-अलग जोखिम निर्णयों वाला एक छाया सुरक्षा मॉडल नहीं चला सकती क्योंकि कार्यभार "नवोन्मेषी" है। यदि एआई सिस्टम संवेदनशील डेटा, बाहरी इनपुट, या स्वचालित कार्यों को छूता है, तो इसका स्थान बाकी परिसंपत्ति के समान नियंत्रण अनुशासन के भीतर होना चाहिए। (संयुक्त राज्य युद्ध विभाग)

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

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

चौथा है डेटा अनुशासन। NSA, FBI, CISA, और साझेदारों की 2025 AI डेटा सुरक्षा मार्गदर्शिका कहती है कि डेटा सुरक्षा AI सिस्टम जीवनचक्र में फैली हुई है और चेतावनी देती है कि यदि कोई हमलावर डेटा में हेरफेर कर सकता है, तो वह AI-आधारित सिस्टम के निर्णय तर्क में भी हेरफेर कर सकता है। यही सही मानसिक मॉडल है। प्रशिक्षण डेटा, फाइन-ट्यूनिंग डेटा, पुनःप्राप्ति कॉर्पस, प्रॉम्प्ट टेम्पलेट, टूल आउटपुट, मूल्यांकन डेटासेट, और फीडबैक लूप निष्क्रिय इनपुट नहीं हैं। वे सिस्टम के व्यवहार के हिस्से हैं। सुरक्षा टीमें जो मॉडल वेट्स की रक्षा करते हुए पुनःप्राप्ति स्टोर या प्रॉम्प्ट कैश को अनदेखा करती हैं, वे केवल बाहरी आवरण की रक्षा कर रही हैं और तंत्रिका तंत्र की उपेक्षा कर रही हैं। (संयुक्त राज्य युद्ध विभाग)

पाँचवाँ स्तंभ परिनियोजन से पहले और बाद में सत्यापन है। सरकारी मार्गदर्शन कहता है कि एआई प्रणालियों को परिनियोजन से पहले सत्यापित किया जाना चाहिए; NIST की GenAI प्रोफ़ाइल पूर्व-परिनियोजन परीक्षण और घटना प्रकटीकरण को प्राथमिक विचारों के रूप में रेखांकित करती है; MITRE का Secure AI कार्य सत्यापनीय एआई भेद्यता खोज और एआई रेड टीमिंग की आवश्यकता पर प्रकाश डालता है। कुल मिलाकर, ये स्रोत एक सीधी-सादी बात का संकेत देते हैं: केवल मॉडल की गुणवत्ता, उपयोगकर्ता की संतुष्टि, या विलंबता का मूल्यांकन करना ही पर्याप्त नहीं है। एक वास्तविक एआई सुरक्षा कार्यक्रम के लिए पूर्व-रिलीज़ प्रतिद्वंद्वी परीक्षण, पोस्ट-रिलीज़ घटना समीक्षा, प्रॉम्प्ट-इंजेक्शन और आउटपुट-हैंडलिंग परीक्षण, निर्भरता समीक्षा, एक्सपोज़र स्कैनिंग, और जैसे-जैसे मॉडल, कनेक्टर और वर्कफ़्लो बदलते हैं, निरंतर सत्यापन की आवश्यकता होती है। (संयुक्त राज्य युद्ध विभाग)

छठा स्तंभ लॉगिंग और अवलोकनीयता है जो वास्तव में एआई वर्कफ़्लो को दर्शाती है। पारंपरिक एप्लिकेशन लॉग आवश्यक हैं, लेकिन वे पर्याप्त नहीं हैं। टीमों को यह जानना आवश्यक है कि किसी दिए गए क्रियाकलाप को किस प्रॉम्प्ट या प्राप्त सामग्री ने उत्पन्न किया, किस मॉडल संस्करण ने उत्तर दिया, किन टूल कॉल्स का प्रयास किया गया, कौन सी पहचान का उपयोग किया गया, कौन सी नीति जांचें पास या फेल हुईं, और कौन सी बाहरी सामग्री संदर्भ में आई। IBM का सभी AI तैनातियों, जिसमें शैडो AI भी शामिल है, में दृश्यता और कमजोरियों व विसंगतियों के लिए बेहतर अवलोकनीयता पर जोर देना महत्वपूर्ण है क्योंकि AI सिस्टम अक्सर केवल प्रक्रिया क्रैश या स्पष्ट अलर्ट के कारण नहीं, बल्कि संदर्भ भ्रष्टाचार और अनुमति के दुरुपयोग के कारण भी विफल हो जाते हैं। (आईबीएम)

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

निम्नलिखित संचालन मॉडल कार्यों को व्यवस्थित करने का एक उपयोगी तरीका है।

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

वह तालिका संश्लेषण है, लेकिन यह NIST, CISA-NSA मार्गदर्शन, IBM के ब्रीच रिसर्च, OWASP के LLM जोखिमों और MITRE के थ्रेट-इन्फॉर्म्ड AI कार्य द्वारा दोहराए गए नियंत्रण विषयों का सीधा विस्तार है। मुद्दा यह नहीं है कि AI के चारों ओर एक नई नौकरशाही बनाई जाए। इसका उद्देश्य उच्च-जोखिम प्रणालियों के लिए पहले से मौजूद अनुशासनों को AI द्वारा बाईपास करने की अनुमति देना बंद करना है।एनआईएसटी)

ऐसा डिटेक्शन कंटेंट जो सुरक्षा टीमें वास्तव में उपयोग कर सकें।

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

AI प्रबंधन एंडपॉइंट्स तक संदिग्ध बाहरी पहुँच का पता लगाने के लिए एक व्यावहारिक KQL उदाहरण कुछ इस तरह दिख सकता है:

// संवेदनशील एआई मॉडल प्रबंधन राउट्स तक इंटरनेट-स्रोत पहुँच का पता लगाएँ
AzureDiagnostics
| where RequestUri_s has_any ("/api/pull", "/api/create", "/api/delete", "/api/tags")
| where not(ipv4_is_in_any_range(ClientIP_s, dynamic([
    "10.0.0.0/8",
    "172.16.0.0/12",
    "192.168.0.0/16"
])))
| summarize count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated)
    by ClientIP_s, RequestUri_s, UserAgent_s, Resource, Host_s
| order by count_ desc

यह क्वेरी जानबूझकर सरल रखी गई है। यह AI सुरक्षा को "समाधान" नहीं करती। यह रक्षकों को एक ऐसी जोखिम श्रेणी के लिए शुरुआती बिंदु देती है जिसे हालिया Ollama-संबंधित CVEs ने दर्दनाक रूप से ठोस कर दिया है: मॉडल-प्रबंधन एंडपॉइंट्स और उनसे जुड़े प्रमाणीकरण प्रवाह संवेदनशील हैं। इन्हें हानिरहित सुविधा API की तरह नहीं माना जाना चाहिए। सटीक मार्ग नाम और लॉग स्कीमा भिन्न हो सकते हैं, लेकिन पहचान पैटर्न टिकाऊ है: नियंत्रण-प्लान क्रियाओं को अलग करें, आंतरिक और बाहरी स्रोत में अंतर करें, और किसी भी असामान्य चीज़ की तुरंत जांच करें। उस डिटेक्शन के पीछे का तर्क, ओलामा कंट्रोल-प्लेन मुद्दों के लिए हालिया NVD रिकॉर्ड और AI सिस्टम के लिए सख्त एक्सेस कंट्रोल और API सुरक्षा पर सरकारी मार्गदर्शन के अनुरूप है। (एनवीडी)

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

शीर्षक: एआई रनटाइम द्वारा शुरू की गई संदिग्ध चाइल्ड प्रक्रिया
id: 4d89c0f0-f8e2-4b1d-8f41-ai-runtime-spawn
स्थिति: प्रयोगात्मक
लॉगसोर्स:
  श्रेणी: प्रक्रिया_निर्माण
पहचान:
  पैरेंट_इमेज:
    Image|endswith:
 - '\ollama.exe'
 - '\ollama'
 - '\python.exe'
 - '\python'
 - '\vllm'
  child_image:
    Image|endswith:
 - '\cmd.exe'
 - '\powershell.exe'
      - '\bash'
 - '\sh'
 - '\curl'
 - '\wget'
  condition: parent_image और child_image
fields:
  - Image
  - ParentImage
  - CommandLine
  - ParentCommandLine
level: high

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

ऑफ़ेंसिव वैलिडेशन कहाँ उपयुक्त है, और AI युग में यह क्यों अधिक महत्वपूर्ण है

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

यहीं पर Penligent जैसा प्लेटफ़ॉर्म स्वाभाविक रूप से फिट बैठता है। Penligent की हालिया सार्वजनिक तकनीकी लेखनी बार-बार एक ही विचार पर लौटती है: एआई का मूल्य कमजोरियों का खूबसूरती से सारांश प्रस्तुत करने में नहीं, बल्कि सुरक्षा कार्य के कठिन मध्य भाग को संभालने में है — संदर्भ को संरक्षित करना, हमले के मार्गों पर तर्क करना, शोषण क्षमता को मान्य करना, और ऐसा सबूत तैयार करना जिसे कोई दूसरा इंजीनियर दोहरा सके। इसके "AI in Security" और "AI Pentest Tool" लेख दोनों यह तर्क देते हैं कि भविष्य उन प्रणालियों का है जो कच्चे संकेत से रक्षा योग्य प्रमाण तक जाती हैं, न कि वार्तालाप संबंधी आवरण वाले स्कैनरों का। यह बाजार के अगले चरण का वर्णन करने का एक उचित तरीका है। (पेनलिजेंट)

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

व्यावहारिक निहितार्थ सरल है। यदि आपका संगठन जोखिमों को प्राथमिकता देने के लिए एआई का उपयोग कर रहा है, तो उसे यह साबित करने के लिए दोहराए जाने योग्य सत्यापन का भी उपयोग करना चाहिए कि कौन से जोखिम वास्तव में पहुँच योग्य हैं। यदि आपका संगठन ऐसे एआई एजेंट तैनात कर रहा है जो कार्रवाई कर सकते हैं, तो उसे उन वर्कफ़्लो का प्रतिद्वंद्वी दृष्टिकोण से परीक्षण करना चाहिए। और यदि आपका संगठन SOC के लिए एआई खरीद रहा है, तो उसे यह सुनिश्चित करना चाहिए कि उस सिस्टम का आउटपुट ऐसे परिवर्तनों से जुड़ा हो जिन्हें वास्तव में सत्यापित, सुधारित और पुनः परीक्षण किया जा सके।

सुरक्षा नेताओं को आगे क्या करना चाहिए

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

दूसरा, "सुरक्षा के लिए उपयोग की जाने वाली AI" को "जिस AI को सुरक्षित किया जाना चाहिए" से अलग करें। यदि आवश्यक हो तो उन्हें अलग-अलग समीक्षा पथों पर रखें, लेकिन जोखिम संबंधी मान्यताओं को एक साथ न मिलाएँ। लॉग पढ़ने वाला SecOps सहायक, आंतरिक डेवलपर्स के सामने उजागर मॉडल-सर्विंग क्लस्टर से एक अलग खतरे का मॉडल रखता है, और ये दोनों ही उत्पादन प्रणालियों में टूल एक्सेस वाले एक स्वायत्त एजेंट से भिन्न हैं। NIST का Cyber AI Profile विशेष रूप से इसलिए सहायक है क्योंकि यह AI-सक्षम रक्षा, AI-सक्षम हमला, और स्वयं AI प्रणालियों की सुरक्षा के बीच इस त्रिपक्षीय अंतर को अनिवार्य करता है। (एनसीसीओई)

तीसरा, एआई इंफ्रास्ट्रक्चर के आसपास एक्सेस कंट्रोल और नेटवर्क एक्सपोजर का मानक तुरंत बढ़ाएँ। Ollama और vLLM के आसपास हालिया NVD रिकॉर्ड्स बताते हैं क्यों। मान लें कि मॉडल-मैनेजमेंट APIs, ऑर्केस्ट्रेशन लेयर्स, एजेंट रनटाइम्स, और इन्फरेंस बैकप्लेन्स सुरक्षा-क्रिटिकल सेवाएँ हैं। समीक्षा करें कि कौन सी पहुँच योग्य हैं, वे कैसे प्रमाणीकरण करती हैं, वे क्या खींच सकती हैं, क्या निष्पादित कर सकती हैं, और वे किन पहचानों को विरासत में प्राप्त करती हैं।एनवीडी)

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

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