AI अब सॉफ़्टवेयर की कमज़ोरियों की जाँच कर सकता है, परख सकता है कि उनका फ़ायदा उठाया जा सकता है या नहीं, और सुधार तैयार करने में मदद कर सकता है। व्यवसायों के लिए अवसर बड़ा है, लेकिन भरोसेमंदी, सुरक्षा और नियंत्रण को लेकर सवाल भी उतने ही बड़े हैं।
कंपनियों के पास सुरक्षा टूल हैं। फिर भी कमज़ोरियों को ठीक करने में इतनी मेहनत क्यों लगती है?
एक सॉफ़्टवेयर कंपनी की कल्पना कीजिए जिसके पास दर्जनों एप्लिकेशन हैं, कोड के बार-बार रिलीज़ होते हैं और एप्लिकेशन सुरक्षा की एक छोटी टीम है।
हर दिन डेवलपर कोड बदलते हैं, डिपेंडेंसी अपडेट करते हैं और एप्लिकेशन को नई सेवाओं से जोड़ते हैं। मौजूदा सुरक्षा टूल इन बदलावों को स्कैन करते हैं और संभावित कमज़ोरियों की पहचान करते हैं।
कुछ निष्कर्ष सीधे-सादे होते हैं। किसी कमज़ोर डिपेंडेंसी को अपग्रेड करना पड़ सकता है, या कोड में सीधे लिखे गए किसी क्रेडेंशियल को हटाना पड़ सकता है।
बाकी निष्कर्षों में गहरी जाँच की ज़रूरत होती है।
स्कैनर संदिग्ध कोड की रिपोर्ट कर सकता है, लेकिन यह तय करना कि वह सचमुच कमज़ोरी है या नहीं, कई सेवाओं, ऑथेंटिकेशन नियमों, डेटा प्रवाह और डिप्लॉयमेंट सेटिंग्स से जुड़ा हो सकता है।
एक सुरक्षा इंजीनियर निष्कर्ष की जाँच करता है। एक डेवलपर एप्लिकेशन के व्यवहार को समझाता है। कोई समस्या को दोहराकर दिखाता है, सुधार सुझाता है और नतीजे को परखता है।
इस बीच और कोड आता रहता है।
ज़रूरी नहीं कि कंपनी के पास सुरक्षा टूल की कमी हो। उसकी चुनौती यह है कि सुरक्षा निष्कर्षों को पुष्ट और हल की गई समस्याओं में कैसे बदला जाए।
AI सुरक्षा प्रणालियों की एक नई पीढ़ी इसी व्यावसायिक समस्या को हल करने की कोशिश कर रही है।
Anthropic, OpenAI, Google, GitHub और विशेषीकृत सुरक्षा कंपनियों के हालिया घटनाक्रम बताते हैं कि AI किसी कमज़ोरी के आसपास की जाँच का अधिक हिस्सा संभाल सकता है।
लेकिन ये प्रणालियाँ वास्तव में क्या कर सकती हैं? और कोई कंपनी कैसे तय करे कि इन्हें अपनाना सार्थक है या नहीं?
संदिग्ध कोड खोजने से सुरक्षा कमज़ोरियों की जाँच तक
कमज़ोरियों की स्वचालित पहचान कोई नई बात नहीं है।
संगठन पहले से स्टैटिक एप्लिकेशन सिक्योरिटी टेस्टिंग (SAST), डायनामिक एप्लिकेशन सिक्योरिटी टेस्टिंग (DAST), सॉफ़्टवेयर कंपोज़िशन एनालिसिस (SCA), सीक्रेट डिटेक्शन और पेनिट्रेशन टेस्टिंग का उपयोग करते हैं।
हर तरीका अलग सवालों का जवाब देता है। स्टैटिक विश्लेषण कोड या उसके प्रतिरूप की जाँच करता है। डायनामिक टेस्टिंग चल रहे एप्लिकेशन की जाँच करती है। डिपेंडेंसी स्कैनिंग थर्ड-पार्टी सॉफ़्टवेयर की ज्ञात समस्याओं की पहचान करती है। पेनिट्रेशन टेस्टिंग यह जाँचती है कि अधिकृत दायरे के भीतर कमज़ोरियों का फ़ायदा उठाया जा सकता है या नहीं।
ये क्षमताएँ आज भी ज़रूरी हैं।
कठिनाई यह है कि संदिग्ध व्यवहार की पहचान करना हमेशा उसके सुरक्षा परिणामों को समझने के बराबर नहीं होता।
तर्क-आधारित एजेंट यह जाँच सकता है कि कई फ़ाइलें, सेवाएँ और अनुमतियाँ आपस में कैसे काम करती हैं। वह कोई परिकल्पना बना सकता है, सहायक प्रमाण परख सकता है और अतिरिक्त परीक्षण सुझा सकता है।
इससे सुरक्षा जाँच का एक अलग किस्म का तरीका संभव होता है।
इस चित्र का सुलभ पाठ विकल्प
पारंपरिक प्रवाह: स्कैन, निष्कर्ष, प्राथमिकता तय करना, डेवलपर का फ़िक्स, समीक्षा और पुनः परीक्षण.
एजेंट-सहायित प्रवाह: संदर्भ समझना, जाँच, सत्यापन, परखा हुआ फ़िक्स सुझाना, स्वतंत्र समीक्षा.
ये दोनों प्रवाह वैचारिक हैं। मौजूदा स्कैनर स्कैनिंग को पहले से स्वचालित करते हैं, और यह दावा नहीं किया गया कि कोई एक एजेंट हर चरण करता है।
अहम बदलाव यह नहीं है कि सुरक्षा स्कैनिंग स्वचालित हो गई। वह पहले से थी।
बदलाव यह है कि पहचान, सत्यापन और सुधार के बीच के काम में सॉफ़्टवेयर धीरे-धीरे अधिक मदद कर सकता है।
Claude Security और GPT-6 Cyber वास्तव में क्या दर्शाते हैं
हाल की दो घोषणाएँ इस विकास के अलग-अलग पहलुओं को दिखाती हैं।
Claude Security: एप्लिकेशन सुरक्षा की सतत जाँच
Anthropic का Claude Security सॉफ़्टवेयर रिपॉज़िटरी से जुड़ता है, कोड के आपसी संबंधों की जाँच करता है और थ्रेट-मॉडल का संदर्भ तैयार करता है।
यह संदर्भ कोड से शुरू होता है। टीमें थ्रेट मॉडल में बदलाव कर सकती हैं और डिप्लॉयमेंट संदर्भ तथा आर्किटेक्चर दस्तावेज़ जोड़ सकती हैं, जिन्हें Anthropic के अनुसार Claude अन्यथा चूक सकता है।
यह होस्टेड सेवा बेसलाइन स्कैनिंग, कोड बदलावों के बार-बार विश्लेषण, निष्कर्षों के सत्यापन, सुधार में सहायता और अनसुलझी समस्याओं की ट्रैकिंग का समर्थन करती है।
शोध की अंतिम तारीख़ पर यह Enterprise प्लान के उपयोगकर्ताओं के लिए बीटा में उपलब्ध थी, और इसके लिए हर उपयोगकर्ता को एक प्रीमियम सीट तथा उपयोग क्रेडिट चाहिए। एक प्रोजेक्ट आठ रिपॉज़िटरी तक जोड़ सकता है।
इसे कोडिंग-असिस्टेंट के साथ एक बार की सामान्य बातचीत से अलग करने वाली चीज़ इसके आसपास का वर्कफ़्लो है। यह प्रोजेक्ट का संदर्भ बनाए रखता है और कोड बदलने के साथ निष्कर्षों को ट्रैक करता है।
इससे हर बार सुरक्षा समस्या सामने आने पर एप्लिकेशन के आर्किटेक्चर को फिर से समझने की मेहनत घट सकती है।
लेकिन Anthropic एक अहम सीमा भी दर्ज करता है: एक ही कोड के दो स्कैन अलग-अलग निष्कर्ष दे सकते हैं, क्योंकि एजेंट की जाँच स्टोकैस्टिक (stochastic) है, यानी हर बार वह जाँच का अलग रास्ता चुन सकता है।
इससे सवाल उठता है कि संगठन दोहराए जा सकने वाला सुरक्षा आश्वासन कैसे स्थापित करें।
GPT-6 Cyber: कमज़ोरियों और एक्सप्लॉइट की गहरी जाँच
OpenAI का GPT-6 Cyber इस समस्या के पास अलग ढंग से पहुँचता है।
यह एक विशेषीकृत साइबर सुरक्षा मॉडल है, जिसे उन्नत कमज़ोरी-शोध के लिए बनाया गया है, जिसमें यह परखना भी शामिल है कि कमज़ोरियों का फ़ायदा उठाया जा सकता है या नहीं।
OpenAI अपने ExploitGym बेंचमार्क पर 48.5% सफलता दर बताता है, जबकि GPT-5.6 Cyber के लिए यह 32.1% है। यह उसका अपना मूल्यांकन है।
कंपनी यह भी बताती है कि उसके शोधकर्ताओं ने इस मॉडल से 948 Linux कर्नेल कमज़ोरियों के लिए काम करने वाले एक्सप्लॉइट बनाए और Firefox में 81 पहले से अज्ञात कमज़ोरियाँ खोजीं, जिन्हें Mozilla ने उच्च गंभीरता का वर्गीकृत किया।
ये नतीजे विशिष्ट साइबर सुरक्षा शोध कार्यों में प्रगति दिखाते हैं। इनका यह मतलब नहीं है कि यह मॉडल किसी उद्यम की 48.5% कमज़ोरियाँ पहचान लेगा या उसके सुरक्षा जोखिम को उसी अनुपात में घटा देगा।
OpenAI इस मॉडल की साइबर सुरक्षा क्षमता को अपने Preparedness Framework के तहत Critical श्रेणी में रखता है। OpenAI के अनुसार यह मॉडल शुरुआत में अपने API और Codex के ज़रिए अपने Daybreak Red कार्यक्रम के चुनिंदा स्वीकृत ग्राहकों के लिए उपलब्ध है।
यह रिपॉज़िटरी से जुड़ी सुरक्षा स्कैनिंग सेवा जैसी उत्पाद श्रेणी नहीं है।
Claude Security मुख्य रूप से एक तैयार पैकेज्ड एप्लिकेशन सुरक्षा वर्कफ़्लो है। GPT-6 Cyber विशेषीकृत मॉडल क्षमता देता है, जो उन्नत सुरक्षा शोध और अन्य अधिकृत टूल में सहायक हो सकती है।
यह तुलना इसलिए मायने रखती है कि व्यवसायों को किसी सक्षम मॉडल को पूरी सुरक्षा सेवा नहीं समझ लेना चाहिए।
और कौन ऐसी क्षमताएँ बना रहा है?
Anthropic और OpenAI अकेले नहीं हैं। कई कंपनियाँ इसी सुरक्षा चुनौती के अलग-अलग हिस्सों पर काम कर रही हैं।
| प्रदाता या सेवा | मुख्य फ़ोकस | अहम अंतर |
|---|---|---|
| Claude Security | रिपॉज़िटरी सुरक्षा की जाँच | सतत स्कैनिंग, संदर्भ और फ़िक्स की ट्रैकिंग। Enterprise प्लान के उपयोगकर्ताओं के लिए बीटा |
| Google CodeMender | कमज़ोरी की खोज, सत्यापन और पैच निर्माण | लोकल टेस्टिंग और एक्सप्लॉइट सत्यापन। Google Cloud सेल्स के ज़रिए सीमित ग्राहकों के लिए Preview, प्रोडक्शन उपयोग के लिए नहीं |
| GitHub Agentic Autofix | कोड-स्कैनिंग अलर्ट ठीक करना | बदलावों को CodeQL के विरुद्ध परखता है और पुल रिक्वेस्ट तैयार करता है। 15 अक्टूबर 2026 से GitHub Enterprise Cloud पर Code Security और Advanced Security के लिए आम तौर पर उपलब्ध, केवल डिफ़ॉल्ट ब्रांच के अलर्ट |
| Semgrep Agentic AppSec | एजेंट-सहायित सुरक्षा विश्लेषण | प्रोग्राम-विश्लेषण टूल, स्थायी संदर्भ और एजेंट वर्कफ़्लो को जोड़ता है। Semgrep ग्राहकों के लिए उपलब्ध, संदर्भ परत प्राइवेट बीटा में |
| Snyk Agent Fix | डेवलपर सुरक्षा सुधार | मौजूदा कमज़ोरी-प्रबंधन और फ़िक्स वर्कफ़्लो का विस्तार करता है। Snyk अपने ही बेंचमार्क नतीजे बताता है |
| XBOW | स्वायत्त पेनिट्रेशन टेस्टिंग | ग्राहक द्वारा तय दायरे में परीक्षण करता है। XBOW के अनुसार निष्कर्षों की रिपोर्ट से पहले डिटरमिनिस्टिक जाँचें उन्हें सत्यापित करती हैं |
| Palo Alto Networks Unit 42 | उद्यम जोखिम का सतत आकलन | विशेषज्ञ-संचालित, बहु-मॉडल मैनेज्ड सेवा |
यह तुलना अलग-अलग मुख्य उद्देश्यों को दर्शाती है, कोई रैंकिंग नहीं है। उपलब्धता और समर्थित क्षमताओं की समीक्षा संबंधित सब्सक्रिप्शन या डिप्लॉयमेंट के लिए अलग से करनी चाहिए।
ये पेशकशें एक अहम बात उजागर करती हैं।
Google CodeMender AI तर्क, सुरक्षा परीक्षण और तैयार किए गए पैच को जोड़ता है। GitHub का Agentic Autofix मौजूदा कोड-स्कैनिंग अलर्ट से शुरू करता है, संबंधित फ़ाइलों में काम करता है, CodeQL दोबारा चलाता है और ड्राफ़्ट पुल रिक्वेस्ट खोलता है। Semgrep केवल मॉडल के तर्क पर निर्भर रहने के बजाय एजेंट वर्कफ़्लो को विशेषीकृत प्रोग्राम विश्लेषण के साथ जोड़ता है।
XBOW और Palo Alto Networks पेनिट्रेशन टेस्टिंग और हमले के रास्तों के सत्यापन तक आगे जाते हैं। Palo Alto Networks हर सुरक्षा कार्य के लिए एक ही मॉडल पर निर्भर रहने के बजाय कई मॉडल और विशेषज्ञ निगरानी का भी उपयोग करता है।
इनमें से कई टूल आपकी ओर से कमांड चलाते हैं या पुल रिक्वेस्ट खोलते हैं, इसलिए उन्हें किस पहुँच की ज़रूरत है, यह भी निर्णय का हिस्सा है।
इसलिए बाज़ार AI सुरक्षा उत्पादों की कोई एक सीधी श्रेणी नहीं है।
कंपनी को पहले यह तय करना चाहिए कि उसे बेहतर कोड स्कैनिंग चाहिए, कमज़ोरी सत्यापन, सुधार में सहायता, पेनिट्रेशन टेस्टिंग या सिक्योरिटी-ऑपरेशंस जाँच।
उसके बाद ही विक्रेताओं की तुलना सार्थक होती है।
जब कोई AI एजेंट किसी वास्तविक एप्लिकेशन की समस्या की जाँच करता है तो क्या होता है?
एक काल्पनिक वित्तीय एप्लिकेशन पर विचार कीजिए।
एक ग्राहक साइन इन करता है और API के ज़रिए अपने खाते की जानकारी माँगता है। एप्लिकेशन जाँचता है कि ग्राहक ऑथेंटिकेटेड है, लेकिन एक एंडपॉइंट यह नहीं जाँचता कि माँगा गया खाता सचमुच उसी ग्राहक का है या नहीं।
यह प्राधिकरण (authorization) की कमज़ोरी है।
एक पारंपरिक स्कैनर इस समस्या के कुछ रूपों को पकड़ सकता है, लेकिन मूल समस्या कठिन हो सकती है, क्योंकि हर अलग फ़ंक्शन अपने आप में ठीक दिख सकता है।
इस कमज़ोरी को समझने के लिए ऑथेंटिकेटेड उपयोगकर्ता, खाता पहचानकर्ता और पहुँच को नियंत्रित करने वाले व्यावसायिक नियमों के आपसी संबंध को देखना पड़ता है।
| चरण | क्या होना ज़रूरी है | एजेंट कहाँ मदद कर सकता है |
|---|---|---|
| खोज | संदिग्ध एक्सेस जाँच वाले एंडपॉइंट की पहचान करना | फ़ंक्शनों के पार पहचान और खाता डेटा का पीछा करना |
| जाँच | तय करना कि खाते का स्वामित्व लागू किया जा रहा है या नहीं | जुड़ी हुई सेवाओं और प्राधिकरण तर्क की जाँच करना |
| सत्यापन | स्थापित करना कि अनधिकृत पहुँच संभव है या नहीं | अधिकृत, अलग-थलग वातावरण में परीक्षण सुझाना |
| सुधार | स्वामित्व जाँच की कमी को ठीक करना | लक्षित कोड बदलाव तैयार करना |
| पुष्टि | साबित करना कि वैध पहुँच काम करती है और अनधिकृत पहुँच विफल होती है | सुरक्षा और कार्यात्मक रिग्रेशन टेस्ट चलाना |
| रिलीज़ | स्वीकृत सुधार को डिप्लॉय करना | स्वतंत्र समीक्षा के लिए प्रमाण देना |
उदाहरणात्मक परिदृश्य, कोई वास्तविक घटना या किसी विशेष विक्रेता की परफ़ॉर्मेंस का डेमो नहीं।
एजेंट का संभावित लाभ कई चरणों की जानकारी को जोड़ने की उसकी क्षमता है, ताकि इंजीनियरों को हर संबंध हाथ से दोबारा न बनाना पड़े।
लेकिन सफल सुरक्षा नतीजे के लिए सिर्फ़ इतना काफ़ी नहीं कि एजेंट कह दे कि कमज़ोरी ठीक हो गई।
सुधरे हुए एप्लिकेशन को इच्छित एक्सेस नियम लागू करने होंगे। मौजूदा वैध क्रियाएँ चलती रहनी चाहिए। परीक्षण प्रासंगिक होने चाहिए, और सुधार उस वातावरण तक पहुँचना चाहिए जहाँ कमज़ोरी मौजूद थी।
सुरक्षा एजेंट उस नतीजे तक पहुँचने की मेहनत घटा सकता है।
लेकिन नतीजा हासिल हुआ या नहीं, इस पर उसे अंतिम प्राधिकारी नहीं माना जाना चाहिए।
कंपनियों को व्यावसायिक मूल्य कहाँ दिख सकता है?
सबसे बड़ा अवसर शायद कमज़ोरी खोजने और सत्यापित सुधार लागू करने के बीच का अंतर घटाना है।
तेज़ जाँच
जटिल सुरक्षा निष्कर्षों में इंजीनियरिंग का काफ़ी समय लग सकता है। उपयुक्त एप्लिकेशन संदर्भ वाला एजेंट इंजीनियरों को हमले के रास्ते समझने और प्रभावित घटकों की पहचान करने में मदद कर सकता है।
अधिक उपयोगी सुधार मार्गदर्शन
जो निष्कर्ष कमज़ोरी का कारण बताता है और परखा जा सकने वाला सुधार सुझाता है, वह केवल स्थान और गंभीरता बताने वाले अलर्ट से अधिक उपयोगी हो सकता है।
अधिक बार आकलन
सतत या बार-बार की जाँच कुछ समस्याओं को कभी-कभार के आकलन से पहले पहचान सकती है, खासकर वहाँ जहाँ एप्लिकेशन बार-बार बदलते हैं।
सीमित सुरक्षा विशेषज्ञता का बेहतर उपयोग
डेवलपर और सुरक्षा इंजीनियर नियमित संदर्भ जुटाने में कम समय लगा सकते हैं और अधिक परिणामकारी निष्कर्षों की जाँच, नियंत्रण डिज़ाइन करने और सुधारों को स्वीकृत करने में अधिक समय दे सकते हैं।
ये संभावित लाभ हैं, पक्की बेहतरी नहीं।
| कंपनियाँ क्या चाहती हैं | उन्हें क्या मापना चाहिए |
|---|---|
| कम अनसुलझे सुरक्षा जोखिम | सत्यापित सुधार तक का समय और शेष जोखिम |
| जाँच में कम मेहनत | हर पुष्ट समस्या पर मानवीय समीक्षा और जाँच का समय |
| बेहतर निष्कर्ष | सत्यापित सही पॉज़िटिव, फ़ॉल्स पॉज़िटिव और छूटी हुई कमज़ोरियाँ |
| सुरक्षित सुधार | प्रस्तावित फ़िक्स के बाद कार्यात्मक और सुरक्षा रिग्रेशन |
| बेहतर अर्थशास्त्र | हर सत्यापित सुधार की कुल लागत, जिसमें टूल का उपयोग और दोबारा किया गया काम शामिल है |
कोई विक्रेता बता सकता है कि उसने काफ़ी अधिक कमज़ोरियाँ खोजीं या जाँच बहुत तेज़ी से पूरी की।
ऐसे नतीजे ध्यान देने लायक हैं, लेकिन संगठनों को पूछना चाहिए कि क्या मापा गया, कौन सी बेसलाइन ली गई और क्या ये नतीजे उनके अपने वातावरण पर लागू होते हैं।
एक्सप्लॉइट-विकास में बेहतर प्रदर्शन दिखाने वाला बेंचमार्क उद्यम के निवेश पर प्रतिफल को स्थापित नहीं करता। विक्रेता का अपना ऑडिट भी मुख्य नतीजे को बदल सकता है: AWS ने अपने 35 कैप्चर किए गए फ़्लैग घटाकर 33 सत्यापित एक्सप्लॉइट कर दिए, जब उसने जाँचा कि हर फ़्लैग कैसे हासिल हुआ था।
इसी तरह, ज़्यादा निष्कर्ष देने वाला टूल जोखिम नहीं घटाता अगर वे निष्कर्ष अनसुलझे रहें।
व्यावसायिक उद्देश्य सबसे बड़ी सुरक्षा रिपोर्ट बनाना नहीं है।
उद्देश्य है स्वीकार्य लागत और व्यवधान के साथ सार्थक जोखिम घटाना।
अधिक सुरक्षा क्षमता से अधिक ज़िम्मेदारी भी क्यों आती है
सुरक्षा एजेंट को उपयोगी काम करने के लिए पहुँच चाहिए।
उसे सोर्स कोड पढ़ने, कॉन्फ़िगरेशन जाँचने, टेस्ट चलाने, टूल से संवाद करने या कई रिपॉज़िटरी में बदलाव सुझाने की ज़रूरत पड़ सकती है।
उन्नत सुरक्षा परीक्षण में विशेष रूप से अधिकृत लक्ष्यों के विरुद्ध नियंत्रित एक्सप्लॉइटेशन की ज़रूरत पड़ सकती है।
ये क्षमताएँ एक नई सुरक्षा सीमा बनाती हैं।
मान लीजिए एजेंट ऐसा दस्तावेज़ पढ़ता है जिसमें दुर्भावनापूर्ण निर्देश हैं। अगर एजेंट उस अविश्वसनीय सामग्री को प्रमाण के बजाय निर्देश मान ले, तो वह कोई अनधिकृत कार्रवाई करने की कोशिश कर सकता है।
यह प्रॉम्प्ट इंजेक्शन का एक रूप है।
अत्यंत सक्षम एजेंट असुरक्षित पैच भी बना सकता है, संवेदनशील जानकारी उजागर कर सकता है, अप्रत्याशित संसाधन खर्च कर सकता है या अपने स्वीकृत दायरे से बाहर की कार्रवाई करने की कोशिश कर सकता है।
इसलिए आसपास की सुरक्षा संरचना को एजेंट के तर्क से स्वतंत्र रहकर उसे नियंत्रित करना होगा।
| एजेंट की गतिविधि | उपयुक्त सीमा |
|---|---|
| संबंधित सोर्स कोड पढ़ना | स्पष्ट रिपॉज़िटरी और डेटा दायरा |
| निष्कर्षों का विश्लेषण | पहचाने जा सकने वाले संस्करणों के विरुद्ध दर्ज प्रमाण |
| टेस्ट या एक्सप्लॉइट प्रदर्शन चलाना | अलग-थलग, अधिकृत लक्ष्य और नियंत्रित टूल |
| कोड में बदलाव सुझाना | सीमित लिखने की अनुमतियाँ और समीक्षा योग्य बदलाव |
| सुधारों को मर्ज या डिप्लॉय करना | स्वतंत्र स्वीकृति और मौजूदा रिलीज़ नियंत्रण |
| संवेदनशील जानकारी संभालना | तय रिटेंशन, पहुँच और प्रसंस्करण नीतियाँ |
OWASP की AI Agent Security मार्गदर्शिका लीस्ट प्रिविलेज, टूल प्राधिकरण, प्रॉम्प्ट इंजेक्शन से बचाव, नियंत्रित निष्पादन और परिणामकारी कार्रवाइयों के लिए मानवीय स्वीकृति पर ज़ोर देती है।
डेटा संभालने की व्यवस्थाएँ भी उत्पादों के बीच अलग होती हैं। उदाहरण के लिए, Anthropic बताता है कि होस्टेड Claude Security सेवा Zero Data Retention का समर्थन नहीं करती। जिन संगठनों को अन्य डिप्लॉयमेंट व्यवस्थाएँ चाहिए, उनके लिए वह अलग से एक Claude Code सिक्योरिटी प्लगइन दर्ज करता है।
यह अंतर दिखाता है कि कंपनी को केवल उत्पाद के नाम पर भरोसा करने के बजाय वास्तविक सेवा और डिप्लॉयमेंट की शर्तों की समीक्षा क्यों करनी चाहिए।
सुरक्षा एजेंट शक्तिशाली टूल हो सकते हैं, लेकिन उन्हें उन्हीं सिस्टमों में नए अनियंत्रित पहुँच मार्ग नहीं बनाने देना चाहिए जिनकी रक्षा करना उनका काम है।
क्या व्यवसाय ऐसे सुरक्षा एजेंटों पर भरोसा कर सकते हैं जो हमेशा एक जैसे नतीजे नहीं देते?
Anthropic के दस्तावेज़ साफ़ कहते हैं कि Claude Security के स्कैन स्टोकैस्टिक (stochastic) हैं।
तर्क करने वाला एजेंट अलग-अलग बार जाँच का अलग रास्ता चुन सकता है, भले ही कोड वही हो।
यह मूल्यवान हो सकता है। लचीली जाँच ऐसी बिज़नेस-लॉजिक खामी पकड़ सकती है जिसे कोई तय नियम नहीं पहचानता।
लेकिन इससे यह भी सीमित होता है कि साफ़ नतीजा क्या साबित कर सकता है।
अगर एजेंट को किसी स्कैन में कोई गंभीर कमज़ोरी नहीं मिलती, तो संगठन यह नहीं मान सकता कि हर संबंधित हमले का रास्ता जाँचा गया।
पारंपरिक सुरक्षा टूल की भी सीमाएँ हैं। डिटरमिनिस्टिक स्कैनर अपनी जाँचें भरोसे से दोहरा सकता है, फिर भी अपने नियमों या विश्लेषण क्षमताओं से बाहर की कमज़ोरियाँ चूक सकता है।
इसलिए अधिक मज़बूत संरचना अलग-अलग किस्म के प्रमाणों को जोड़ सकती है:
- दोहराई जा सकने वाली सुरक्षा जाँचें ज्ञात कवरेज स्थापित करती हैं।
- तर्क करने वाले एजेंट संदर्भ-आधारित और जटिल कमज़ोरियों की जाँच करते हैं।
- नियंत्रित परीक्षण महत्वपूर्ण निष्कर्षों को सत्यापित करते हैं।
- मानवीय समीक्षक व्यावसायिक प्रभाव और परिणामकारी निर्णयों का आकलन करते हैं।
- बाद के परीक्षण जाँचते हैं कि सुधार प्रभावी बने रहते हैं या नहीं।
यह एक आर्किटेक्चर संबंधी सिफ़ारिश है, यह दावा नहीं कि किसी एक विक्रेता ने समस्या हल कर ली है।
लक्ष्य भरोसेमंद सुरक्षा नतीजे होने चाहिए, न कि केवल पारंपरिक स्कैनरों या केवल AI तर्क पर निर्भरता।
क्या सुरक्षा इंजीनियर कम महत्वपूर्ण हो जाएँगे?
AI कमज़ोरी की खोज, जाँच और सुधार के कुछ हिस्सों को स्वचालित कर सकता है।
लेकिन एप्लिकेशन सुरक्षा केवल असुरक्षित कोड पहचानने की क्षमता नहीं है।
किसी को फिर भी व्यावसायिक प्रक्रियाएँ समझनी होंगी, महत्वपूर्ण संपत्तियाँ पहचाननी होंगी, स्वीकार्य जोखिम तय करना होगा, एक्सेस नीतियाँ डिज़ाइन करनी होंगी और यह निर्धारित करना होगा कि कोई सुधार उचित है या नहीं।
AI इन निर्णयों के लिए प्रमाण जुटाने में मदद कर सकता है। उसे संगठनात्मक अधिकार या जवाबदेही अपने आप नहीं मिल जाती। इस अंतर पर AI काम करने में बेहतर होता जा रहा है। लेकिन क्या वह नतीजे की ज़िम्मेदारी उठाने के लिए तैयार है? में चर्चा की गई है।
निकट भविष्य की अधिक यथार्थवादी संभावना यह है कि सुरक्षा इंजीनियर कुछ दोहराव वाले कामों में कम समय लगाएँ और जटिल जोखिमों के मूल्यांकन, स्वचालित जाँचों की निगरानी और यह सुनिश्चित करने में अधिक समय दें कि एजेंट सुरक्षित ढंग से काम करें।
कुछ संगठन अपनी टीमों को उसी रफ़्तार से बढ़ाए बिना, जिस रफ़्तार से उनके सॉफ़्टवेयर पोर्टफ़ोलियो बढ़ते हैं, कवरेज सुधार सकते हैं।
अन्य संगठनों को एजेंट सुरक्षा, टूल अनुमतियों, मॉडल व्यवहार और मूल्यांकन में नई विशेषज्ञता चाहिए हो सकती है।
अभी का प्रमाण इस सामान्य भविष्यवाणी को उचित नहीं ठहराता कि AI सुरक्षा एजेंट सुरक्षा इंजीनियरों की जगह ले लेंगे।
यह एक सीमित निष्कर्ष का समर्थन करता है: जैसे-जैसे ये टूल परिपक्व होंगे, सुरक्षा इंजीनियरिंग से जुड़ी गतिविधियाँ और कौशल बदलने की संभावना है।
क्या कंपनियों को ये तकनीकें अभी अपनानी चाहिए?
हर संगठन को एक और सुरक्षा प्लेटफ़ॉर्म की ज़रूरत नहीं होती।
जिस कंपनी के पास कई रिपॉज़िटरी, अनुभवी सुरक्षा समीक्षक और बड़ा अनसुलझी कमज़ोरियों का बैकलॉग है, उसके पास एजेंट-सहायित जाँच का मूल्यांकन करने का मज़बूत कारण हो सकता है।
छोटी डेवलपमेंट टीम को अलग सेवा खरीदने के बजाय मौजूदा GitHub, Semgrep या Snyk वर्कफ़्लो को बढ़ाना अधिक व्यावहारिक लग सकता है।
अत्यंत संवेदनशील कोड या कड़े नियमन वाले सिस्टमों पर काम करने वाले संगठन को सीमित मूल्यांकन से पहले भी डेटा-संभाल, अलगाव और प्राधिकरण की आवश्यकताएँ तय करनी पड़ सकती हैं।
| संगठन की स्थिति | उचित अगला कदम |
|---|---|
| परिपक्व AppSec कार्यक्रम और बहुत सारे अनसुलझे निष्कर्ष | मौजूदा वर्कफ़्लो के विरुद्ध नियंत्रित तुलना चलाना |
| छोटी टीम जो पहले से AI सुविधाओं वाले सुरक्षा टूल इस्तेमाल करती है | मौजूदा प्लेटफ़ॉर्म में पहले से शामिल क्षमताओं का मूल्यांकन करना |
| अत्यंत संवेदनशील एप्लिकेशन या इन्फ्रास्ट्रक्चर | पहले पहुँच, डेटा-प्रसंस्करण और निष्पादन के सुरक्षा उपाय तय करना |
| भरोसेमंद स्कैनिंग, स्वामित्व या सुधार प्रक्रिया नहीं है | AI से भरपाई की उम्मीद करने से पहले ये बुनियादी चीज़ें ठीक करना |
| उन्नत एक्सप्लॉइट शोध में रुचि | उचित रूप से अधिकृत विशेषज्ञ सेवाओं और नियंत्रित वातावरण का उपयोग करना |
एक प्रतिनिधि व्यावसायिक समस्या से शुरू कीजिए और परीक्षण से पहले तय कीजिए कि सफलता का क्या मतलब है।
उदाहरण के लिए: क्या एजेंट-सहायित वर्कफ़्लो पुष्ट कमज़ोरियों के किसी समूह को मौजूदा प्रक्रिया से अधिक सटीक या किफ़ायती ढंग से हल करने में मदद कर सकता है?
एक व्यावहारिक परीक्षण: कमज़ोरियों का ऐसा समूह लीजिए जिसे आपकी टीम पहले ही पुष्ट कर चुकी और ठीक कर चुकी है, उसी समूह पर अपना मौजूदा वर्कफ़्लो और एजेंट-सहायित वर्कफ़्लो दोनों चलाइए, और सत्यापित सुधार तक का समय, छूटे निष्कर्ष और रिग्रेशन की तुलना कीजिए।
वास्तविक नतीजे मापिए, जिनमें छूटी हुई कमज़ोरियाँ और असुरक्षित बदलाव भी शामिल हैं। केवल AI टूल की कीमत नहीं, कुल लागत का मूल्यांकन कीजिए।
और महत्वपूर्ण कार्रवाइयों, खासकर एक्सप्लॉइट निष्पादन, सुरक्षा फ़िक्स की मर्जिंग और प्रोडक्शन बदलावों को, स्वतंत्र रूप से लागू प्राधिकरण नियंत्रणों के भीतर रखिए।
जो मूल्यांकन इस नतीजे पर पहुँचे कि तकनीक किसी विशेष संगठन के लिए अभी उपयोगी नहीं है, वह भी मूल्यवान है। वह प्रमाण के बिना बड़े निवेश को रोक सकता है।
बड़ा बदलाव स्कैनरों को बदलने के बारे में नहीं है
AI-सहायित सॉफ़्टवेयर विकास ने कोड बनाना और बदलना आसान कर दिया है। इससे ऐसी सुरक्षा पद्धतियों का महत्व बढ़ता है जो बदलते एप्लिकेशन के साथ चल सकें।
एजेंटिक सुरक्षा प्रणालियाँ एक संभावित जवाब हैं।
वे कोड की समझ, कमज़ोरी की जाँच, सत्यापन और सुधार को ऐसे तरीकों से जोड़ सकती हैं जिन्हें पहले स्वचालित करना कठिन था।
उभरते बाज़ार में पहले से रिपॉज़िटरी-सुरक्षा प्लेटफ़ॉर्म, AI-सहायित सुधार, स्वायत्त पेनिट्रेशन टेस्टिंग और विशेषज्ञ-संचालित बहु-मॉडल सेवाएँ शामिल हैं।
ये तकनीकें एक-जैसी नहीं हैं, और इनके प्रदर्शन के दावों के पीछे का प्रमाण अलग-अलग है।
व्यवसायों को इनका आकलन इस आधार पर करना चाहिए कि उन्हें कौन सा सुरक्षा कार्य पूरा करवाना है, न कि मॉडल की परिष्कृतता या किसी लॉन्च के आसपास के उत्साह के आधार पर।
साइबर सुरक्षा का बुनियादी उद्देश्य नहीं बदला है।
कंपनियों को अब भी कमज़ोरियाँ पहचाननी हैं, उनके परिणाम समझने हैं और नुकसान होने से पहले उन्हें ठीक करना है।
जो बदल रहा है वह यह है कि उस काम का कितना हिस्सा सॉफ़्टवेयर कर पाएगा, और उस सॉफ़्टवेयर को कंपनियों को कितनी सावधानी से नियंत्रित करना होगा।
और गहराई से पढ़ें
ये स्रोत तकनीकी विवरण, उत्पादों की सीमाएँ और संबंधित सुरक्षा मार्गदर्शन देते हैं।
- Anthropic: Use Claude Security: रिपॉज़िटरी विश्लेषण, सतत स्कैनिंग, थ्रेट मॉडल, निष्कर्ष, सुधार और दर्ज की गई सीमाएँ।
- OpenAI: GPT-6 Cyber, 5 नवंबर 2026: विशेषीकृत साइबर-मॉडल क्षमताएँ, बेंचमार्क, अधिकृत शोध और सुरक्षा नियंत्रण।
- Google Cloud: CodeMender overview: कमज़ोरी की खोज, सत्यापन और पैच निर्माण, जिसमें प्रीव्यू की सीमाएँ भी शामिल हैं।
- GitHub: Agentic Autofix general availability, 15 अक्टूबर 2026: कोड-स्कैनिंग अलर्ट का सुधार और समीक्षा योग्य पुल रिक्वेस्ट के साथ एकीकरण।
- Semgrep: Agentic AppSec Platform, 12 नवंबर 2026: प्रोग्राम विश्लेषण और स्थायी कोड संदर्भ से समर्थित एजेंटिक सुरक्षा वर्कफ़्लो।
- Palo Alto Networks: Unit 42 Continuous Frontier AI Defense: सतत जोखिम खोज, सत्यापन और विशेषज्ञ-संचालित बहु-मॉडल सुरक्षा सेवाएँ।
- OWASP: AI Agent Security Cheat Sheet: एजेंट अनुमतियों, टूल उपयोग, प्रॉम्प्ट इंजेक्शन, निष्पादन और मानवीय समीक्षा के व्यावहारिक नियंत्रण।
- Snyk: Agent Fix agentic architecture, 27 अप्रैल 2026: Snyk स्वचालित कोड सुधार और अपने बेंचमार्क नतीजों का वर्णन कैसे करता है।
- XBOW: We ran 1,060 autonomous attacks, 2 मार्च 2026: स्वायत्त पेनिट्रेशन टेस्टिंग, दायरा नियंत्रण और सत्यापन का XBOW का वर्णन।
स्रोत 13 नवंबर 2026 को पढ़े गए थे। उत्पादों की उपलब्धता और विक्रेताओं के आँकड़े विक्रेताओं के अपने हैं और बदल सकते हैं।
