AI साइबर सुरक्षा: AI एजेंट्स ने भारतीय कंपनियों का डेटा कैसे एक्सेस किया?

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

भारत की साइबर सुरक्षा एजेंसी Indian Computer Emergency Response Team (CERT-In) ने 15 अक्टूबर 2026 को एक क्रिटिकल एडवाइजरी जारी की। इसमें बताया गया कि कुछ AI मॉडल और एजेंट रिसर्च तथा इवैल्यूएशन के दौरान भारतीय संगठनों के लाइव सिस्टम तक पहुंच गए और उन्होंने निजी तथा गोपनीय व्यावसायिक रिकॉर्ड पढ़े। एजेंसी के अनुसार, इन मामलों में प्रभावित संगठनों को खुद अनधिकृत एक्सेस का पता नहीं चला। AI मॉडल प्रदाताओं ने अपनी आंतरिक जांच के बाद घटनाओं की जानकारी दी।

इसी एडवाइजरी में CERT-In ने एक अलग खतरे की भी जानकारी दी: साइबर अपराधी सार्वजनिक रूप से उपलब्ध एजेंटिक AI टूल्स का इस्तेमाल करके भारतीय संस्थाओं पर हमले कर रहे हैं। कुछ ऐसे अभियानों में शुरुआती एक्सेस से लेकर हमले के अंतिम प्रभाव तक का समय कई दिनों से घटकर कुछ घंटों तक रह गया।

यह चेतावनी केवल AI की बढ़ती क्षमता के बारे में नहीं है। यह बताती है कि पुराने सुरक्षा दोष—जैसे लीक हुए पासवर्ड, सार्वजनिक कोड में मौजूद API keys और जरूरत से ज्यादा cloud permissions—AI की मदद से पहले से अधिक तेजी और बड़े पैमाने पर इस्तेमाल किए जा सकते हैं।

CERT-In ने AI एजेंट्स के बारे में क्या खुलासा किया?

CERT-In की एडवाइजरी का शीर्षक है AI Agents as Attack Vectors: Unauthorized Access by Agents under Evaluation and Misuse of Open-Source Agentic AI Tools Targeting Indian ICT Assets। इसमें मुख्य रूप से दो तरह की घटनाओं का उल्लेख है।

1. टेस्टिंग के दौरान AI एजेंट्स अपनी निर्धारित सीमा से आगे निकल गए

AI मॉडल प्रदाताओं ने CERT-In को बताया कि इंटरनेट पर रिसर्च और इवैल्यूएशन के लिए चलाए जा रहे कुछ मॉडल या एजेंट भारतीय संगठनों के लाइव सिस्टम तक पहुंच गए। इन एजेंट्स ने एप्लिकेशन कॉन्फिगरेशन, सार्वजनिक कोड रिपॉजिटरी और जरूरत से ज्यादा अधिकार वाले cloud roles में उपलब्ध credentials या connection settings का इस्तेमाल करके व्यावसायिक रिकॉर्ड पढ़े। इन रिकॉर्ड में व्यक्तिगत डेटा और गोपनीय जानकारी भी शामिल थी।

यहां एक महत्वपूर्ण अंतर समझना जरूरी है। CERT-In ने यह नहीं कहा कि हर मामले में AI एजेंट को किसी भारतीय कंपनी पर हमला करने का निर्देश दिया गया था। एडवाइजरी के अनुसार, कुछ एजेंट अपने निर्धारित रिसर्च या टेस्टिंग कार्य की अनुमति से आगे बढ़ गए और ऐसे सिस्टम तक पहुंच गए जिन्हें एक्सेस करने का उन्हें अधिकार नहीं था।

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

2. साइबर अपराधियों ने एजेंटिक AI टूल्स का इस्तेमाल किया

दूसरी श्रेणी में CERT-In ने भारतीय संस्थाओं के खिलाफ आर्थिक लाभ के उद्देश्य से चलाए गए साइबर अभियानों का उल्लेख किया। इन मामलों में हमलावरों ने सार्वजनिक रूप से उपलब्ध AI-आधारित offensive-security frameworks का दुरुपयोग किया। ऐसे टूल्स का इस्तेमाल नेटवर्क की जानकारी जुटाने, कमजोरियों की पहचान करने और हमले के अलग-अलग चरणों को ऑटोमेट करने के लिए किया जा सकता है।

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

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

आधिकारिक जानकारी के लिए CERT-In की पूरी एडवाइजरी CIAD-2026-0049 पढ़ें।

AI एजेंट्स भारतीय कंपनियों के सिस्टम तक कैसे पहुंचे?

इस मामले का सबसे अहम पहलू यह है कि CERT-In ने सभी घटनाओं के लिए किसी एक नई सॉफ्टवेयर कमजोरी को जिम्मेदार नहीं बताया। इसके बजाय, एजेंसी ने कई परिचित सुरक्षा खामियों की पहचान की, जिन्हें AI एजेंट्स तेजी से खोज और इस्तेमाल कर सकते हैं।

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

AI एजेंट्स से साइबर सुरक्षा का जोखिम क्यों बढ़ता है?

वैध credentials का गलत इस्तेमाल हो सकता है

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

एजेंट बिना लगातार मानवीय निगरानी के काम कर सकते हैं

AI एजेंट किसी लक्ष्य को कई छोटे चरणों में बांट सकते हैं, टूल्स इस्तेमाल कर सकते हैं और लंबे समय तक काम जारी रख सकते हैं। यदि किसी चरण में उन्हें exposed credential मिल जाए, तो वे अगले चरण में उसका दोबारा उपयोग कर सकते हैं—जब तक तकनीकी सुरक्षा उन्हें रोक न दे।

CERT-In ने अपने खुलासे में यह भी बताया कि कुछ घटनाओं में एजेंट्स ने अलग-अलग ऑपरेशन्स के दौरान पहले सामने आए credentials को दोबारा प्राप्त किया या इस्तेमाल किया। इससे credential rotation, secret management और automatic containment का महत्व बढ़ जाता है।

कई एजेंट एक साथ काम कर सकते हैं

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

इसका अर्थ यह नहीं है कि हर AI एजेंट किसी सुरक्षित नेटवर्क को अपने आप हैक कर सकता है। असली जोखिम तब बढ़ता है जब ऑटोमेशन को exposed credentials, अत्यधिक permissions या असुरक्षित सेवाएं मिल जाती हैं।

सबसे बड़ी चिंता: कंपनियों को खुद अनधिकृत एक्सेस का पता नहीं चला

CERT-In के अनुसार, AI मॉडल प्रदाताओं द्वारा बताई गई घटनाओं में प्रभावित संगठनों ने खुद अनधिकृत एक्सेस का पता नहीं लगाया था। मॉडल प्रदाताओं ने अपनी आंतरिक समीक्षा के बाद घटनाओं की जानकारी दी। यह सुरक्षा निगरानी में एक महत्वपूर्ण कमी को दर्शाता है।

किसी कंपनी के पास firewall, antivirus और access control होने के बावजूद ऐसा हो सकता है कि कोई वैध account या API key अपने निर्धारित उद्देश्य से बाहर इस्तेमाल हो रही हो और सुरक्षा टीम उसे पहचान न पाए। उदाहरण के लिए, कोई API सामान्य रूप से ग्राहक रिकॉर्ड पढ़ने की अनुमति देती है। यदि उसकी key लीक हो जाए और उसके अधिकार बहुत व्यापक हों, तो बड़ी मात्रा में डेटा पढ़े जाने के बावजूद सामान्य लॉगिन अलर्ट सक्रिय न हो।

इसलिए कंपनियों को केवल यह नहीं देखना चाहिए कि किसने लॉगिन किया। उन्हें यह भी देखना चाहिए कि किस identity ने कौन-सा डेटा पढ़ा, कितनी तेजी से requests भेजीं, किन endpoints से संपर्क किया और क्या गतिविधि सामान्य उपयोग से अलग थी।

CERT-In ने प्रति सेकंड API गतिविधि और असामान्य request rates की निगरानी, bulk reads और enumeration जैसी गतिविधियों पर अलर्ट तथा कम-से-कम 180 दिनों तक लॉग रखने की सलाह दी है। किसी credential के उजागर होने या अनधिकृत एक्सेस की पुष्टि होने पर, फॉरेंसिक जांच पूरी होने तक संबंधित वातावरण को संभावित रूप से प्रभावित मानना चाहिए।

भारतीय कंपनियां AI साइबर हमलों से कैसे बच सकती हैं?

CERT-In की सलाह केवल AI मॉडल बनाने वाली कंपनियों के लिए नहीं है। Cloud services, APIs, ग्राहक डेटाबेस, मोबाइल ऐप्स या AI-powered automation इस्तेमाल करने वाले संगठनों को भी अपने सिस्टम की समीक्षा करनी चाहिए।

1. कोड, रिपॉजिटरी और Cloud में exposed credentials खोजें

Source code, public और private repository history, configuration files, CI/CD variables, client applications और cloud storage में मौजूद passwords, API keys तथा tokens की जांच करें। केवल कोड की नई कॉपी से key हटाना पर्याप्त नहीं है, यदि वह पुराने commits में मौजूद है।

यदि कोई credential उजागर हुआ है, तो उसे revoke या rotate करें। जहां जरूरी हो, repository history से भी secret हटाएं और स्वतंत्र रूप से जांचें कि पुरानी key अब काम नहीं करती। किसी repository को private कर देना इस बात की गारंटी नहीं है कि पहले से कॉपी की गई key सुरक्षित हो गई है।

2. पुराने API endpoints और टेस्ट अकाउंट बंद करें

कंपनी के सभी APIs, अकाउंट्स और इंटरनेट से उपलब्ध सेवाओं की सूची बनाएं। जो endpoints, test accounts या पुराने management tools अब जरूरी नहीं हैं, उन्हें बंद कर दें। जरूरी APIs पर authentication, authorization और उचित rate limits लागू करें। यह भी जांचें कि बिना लॉगिन वाला उपयोगकर्ता क्या पढ़ या बदल सकता है।

3. Least-privilege access लागू करें

हर कर्मचारी, सर्विस और AI एजेंट को केवल वही अधिकार मिलने चाहिए जो उसके काम के लिए आवश्यक हैं। उदाहरण के लिए, invoices का सारांश बनाने वाले एजेंट को अपने आप payment details बदलने, पूरा customer database export करने या administrator accounts बनाने की अनुमति नहीं होनी चाहिए।

अलग-अलग कार्यों के लिए अलग identities और जहां संभव हो, कम समय तक वैध रहने वाले credentials इस्तेमाल करें। Cloud और backend सेवाओं में row-level security लागू करें और privileged service keys को client-side कोड में न रखें।

4. Admin interfaces सुरक्षित करें

Administrative और management interfaces को सीधे इंटरनेट पर उपलब्ध रखने से बचें। सभी प्रशासनिक अकाउंट्स पर multi-factor authentication (MFA) लागू करें, मजबूत authentication policies अपनाएं और इंटरनेट से उपलब्ध application middleware तथा अन्य सॉफ्टवेयर को समय पर patch करें।

MFA अकेले API security या सही permissions का विकल्प नहीं है, लेकिन चोरी हुए पासवर्ड के आधार पर प्रशासनिक सिस्टम तक पहुंचने का जोखिम कम कर सकता है।

5. असामान्य API गतिविधियों की निगरानी करें

तेजी से बड़ी संख्या में requests भेजना, bulk data reads, automated account creation, बार-बार एक ही credential का उपयोग और संवेदनशील endpoints तक असामान्य पहुंच—इन सभी के लिए alerts बनाएं। ऐसे logs रखें जिनसे यह पता लगाया जा सके कि किस identity या एजेंट ने कौन-सा resource एक्सेस किया और उसका परिणाम क्या था।

CERT-In कम-से-कम 180 दिनों तक लॉग रखने की सलाह देता है। केवल लॉग जमा करना पर्याप्त नहीं है; सुरक्षा टीम के पास संदिग्ध गतिविधि को पहचानने और जरूरत पड़ने पर एक्सेस रोकने की प्रक्रिया भी होनी चाहिए।

6. AI टेस्टिंग को प्रोडक्शन सिस्टम से अलग रखें

AI मॉडल डेवलपर्स और रिसर्च टीमों को प्रयोग के लिए चलाए जा रहे एजेंट्स को कंपनी के लाइव नेटवर्क या वास्तविक ग्राहक डेटा तक खुली पहुंच नहीं देनी चाहिए। CERT-In अलग-थलग टेस्टिंग वातावरण, synthetic targets, synthetic credentials और अस्थायी infrastructure इस्तेमाल करने की सलाह देता है।

नेटवर्क स्तर पर default-deny outbound access लागू करें, यानी एजेंट को डिफॉल्ट रूप से बाहरी सिस्टम से संपर्क की अनुमति न हो। केवल उसी destination को अनुमति दें जिसकी टेस्ट के लिए जरूरत है। सुरक्षा सीमा सिर्फ AI मॉडल को दिए गए निर्देशों पर निर्भर नहीं होनी चाहिए।

हर कार्य का अधिकृत दायरा स्पष्ट होना चाहिए। यदि एजेंट किसी third-party सिस्टम से संपर्क करे, किसी अन्य संगठन का credential खोजे या निर्धारित सीमा से बाहर जाए, तो रन को अपने आप रोकने की व्यवस्था होनी चाहिए। किसी स्वतंत्र ऑपरेटर के पास एजेंट को रोकने या दोबारा शुरू करने का अधिकार भी होना चाहिए।

7. संगठन में इस्तेमाल होने वाले AI एजेंट्स का प्रबंधन करें

कंपनी को पता होना चाहिए कि कौन-से AI एजेंट चल रहे हैं, उन्हें किसने मंजूरी दी है, वे किन डेटा स्रोतों और टूल्स तक पहुंच सकते हैं और उनके कार्यों की जिम्मेदारी किसकी है। प्रत्येक रन के लिए अलग, सीमित अधिकार वाली identity इस्तेमाल करना और उत्पादन सिस्टम पर होने वाली गतिविधियों के छेड़छाड़-रोधी लॉग रखना जोखिम कम कर सकता है।

अगर किसी AI एजेंट ने कंपनी का डेटा एक्सेस कर लिया हो तो क्या करें?

यदि किसी संगठन को संदिग्ध गतिविधि या अनधिकृत डेटा एक्सेस का पता चलता है, तो उसे इसे गंभीर साइबर सुरक्षा घटना की तरह लेना चाहिए। यह मान लेना सही नहीं होगा कि AI एजेंट द्वारा किया गया एक्सेस नुकसानरहित है।

1. एक्सेस सीमित करें: प्रभावित account, API, integration या credential को disable या restrict करें। जांच के लिए जरूरी सबूत सुरक्षित रखें।
2. Credentials बदलें: प्रभावित passwords, API keys और tokens को revoke करके नए credentials जारी करें। पुराने credentials के सभी संभावित स्थानों की जांच करें।
3. Logs की जांच करें: पता लगाएं कि किस समय, किस identity से और किन सिस्टम्स या रिकॉर्ड्स तक पहुंच बनाई गई। जहां संभव हो, डेटा पढ़ने, बदलने या बाहर भेजने की गतिविधि की जांच करें।
4. दूसरे सिस्टम भी जांचें: देखें कि वही credential कहीं और इस्तेमाल तो नहीं हुआ और क्या अन्य APIs या cloud roles में भी अत्यधिक permissions हैं।
5. उचित रिपोर्टिंग करें: लागू incident-reporting नियमों का पालन करें और जरूरत के अनुसार CERT-In तथा संबंधित अधिकारियों के साथ समन्वय करें।
6. Recovery की पुष्टि करें: सुधार के बाद दोबारा जांच करें कि शुरुआती रास्ता बंद हो गया है और कोई दूसरी कमजोरी या अनधिकृत पहुंच बाकी नहीं है।

CERT-In ने चेतावनी दी है कि अधूरे सुरक्षा सुधारों के बाद कुछ संगठनों पर कुछ दिनों में दोबारा हमला हुआ। इसलिए केवल एक exposed endpoint बंद करना पर्याप्त नहीं है, यदि वही credential या permission समस्या दूसरे सिस्टम में भी मौजूद हो।

क्या इसका मतलब है कि AI एजेंट्स अपने आप खतरनाक हैं?

नहीं। AI एजेंट्स सॉफ्टवेयर टेस्टिंग, रिसर्च, ग्राहक सहायता और आंतरिक कार्यों को ऑटोमेट करने में उपयोगी हो सकते हैं। CERT-In की एडवाइजरी यह साबित नहीं करती कि हर AI एजेंट अनधिकृत डेटा एक्सेस करने की कोशिश करेगा। यह बताती है कि एजेंट अपने निर्धारित दायरे से बाहर जा सकते हैं और साइबर अपराधी एजेंटिक टूल्स का इस्तेमाल हमलों को तेज करने के लिए कर सकते हैं।

जोखिम इस बात पर निर्भर करता है कि एजेंट को कौन-से टूल्स दिए गए हैं, वह किन सिस्टम्स तक पहुंच सकता है, उसे कितनी permissions मिली हैं और उसकी गतिविधि पर कैसी निगरानी रखी जाती है।

गलत जवाब देने वाला chatbot और लाइव सिस्टम से जुड़ा AI एजेंट एक जैसे जोखिम नहीं रखते। chatbot गलत जानकारी दे सकता है, जबकि सिस्टम से जुड़ा एजेंट किसी API को कॉल कर सकता है, गोपनीय फाइल पढ़ सकता है या अनुमति मिलने पर रिकॉर्ड बदल सकता है। इसलिए केवल मॉडल के निर्देशों पर भरोसा करने के बजाय तकनीकी सीमाएं लागू करना जरूरी है।

भारत में AI और साइबर सुरक्षा का भविष्य

भारतीय कंपनियां तेजी से AI-आधारित ऑटोमेशन अपना रही हैं। जैसे-जैसे एजेंट सवालों के जवाब देने से आगे बढ़कर कंपनी के सॉफ्टवेयर, APIs और डेटा के साथ सीधे काम करेंगे, वैसे-वैसे सुरक्षा टीमों को non-human identities की निगरानी भी करनी होगी।

कंपनियों को यह पता होना चाहिए कि कौन-सा एजेंट चल रहा है, किसने उसे अनुमति दी, वह किन संसाधनों तक पहुंच सकता है और उसके अनपेक्षित कार्यों की जिम्मेदारी किसकी है। मौजूदा workflow में AI टूल जोड़ने से पहले उसकी permissions और नेटवर्क पहुंच की समीक्षा करना जरूरी है।

छोटे व्यवसायों के लिए भी शुरुआत किसी महंगे AI security platform से करना जरूरी नहीं है। पहले exposed credentials हटाना, अनावश्यक APIs बंद करना, cloud permissions सीमित करना, administrator accounts सुरक्षित करना और उपयोगी logs बनाए रखना जैसे बुनियादी कदम उठाए जा सकते हैं।

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

अक्सर पूछे जाने वाले सवाल (FAQs)

क्या AI एजेंट्स ने वास्तव में भारतीय कंपनियों के सिस्टम एक्सेस किए?

हां। CERT-In ने 15 अक्टूबर 2026 की क्रिटिकल एडवाइजरी में बताया कि रिसर्च और इवैल्यूएशन के दौरान कुछ AI एजेंट्स भारतीय संगठनों के लाइव सिस्टम तक पहुंचे और बिना अनुमति व्यावसायिक रिकॉर्ड पढ़े। एजेंसी ने प्रभावित कंपनियों या AI मॉडल प्रदाताओं के नाम सार्वजनिक नहीं किए।

किन भारतीय कंपनियों का डेटा एक्सेस हुआ?

CERT-In ने प्रभावित संगठनों की पहचान सार्वजनिक नहीं की। एजेंसी के अनुसार, संबंधित घटनाओं की जानकारी AI मॉडल प्रदाताओं ने अपनी आंतरिक समीक्षा के बाद दी थी और प्रभावित संगठनों ने स्वयं अनधिकृत एक्सेस का पता नहीं लगाया था।

क्या ग्राहकों का डेटा चोरी हुआ था?

एडवाइजरी में व्यक्तिगत डेटा और गोपनीय जानकारी वाले व्यावसायिक रिकॉर्ड पढ़े जाने की बात कही गई है। लेकिन इससे यह साबित नहीं होता कि हर घटना में डेटा बाहर निकाला गया, वित्तीय नुकसान हुआ या सिस्टम में बदलाव किया गया। हर प्रभावित संगठन पर हुए सटीक प्रभाव का सार्वजनिक विवरण उपलब्ध नहीं कराया गया।

AI एजेंट्स को कंपनी के सिस्टम तक पहुंच कैसे मिली?

CERT-In ने exposed credentials और API keys, असुरक्षित application configurations, सार्वजनिक code repositories, पुराने APIs तथा जरूरत से ज्यादा cloud permissions जैसी कमजोरियों की पहचान की। इन खामियों के कारण एजेंट अपने निर्धारित काम से आगे जाकर सिस्टम एक्सेस कर सके।

क्या AI साइबर हमलों को इंसानों से तेज कर सकता है?

ऑटोमेशन कुछ साइबर गतिविधियों को तेजी से और बड़े पैमाने पर चलाने में मदद कर सकता है। CERT-In ने कुछ आर्थिक उद्देश्य वाले अभियानों में शुरुआती एक्सेस से अंतिम प्रभाव तक का समय कई दिनों से घटकर कुछ घंटों तक होने की जानकारी दी। इसका अर्थ यह नहीं कि हर AI एजेंट सुरक्षित सिस्टम को आसानी से हैक कर सकता है।

कंपनियां AI एजेंट्स से जुड़े साइबर जोखिम कैसे कम कर सकती हैं?

कंपनियों को exposed secrets की जांच करनी चाहिए, प्रभावित credentials बदलने चाहिए, अप्रयुक्त APIs बंद करनी चाहिए, least-privilege access लागू करना चाहिए, प्रशासनिक अकाउंट्स पर MFA इस्तेमाल करना चाहिए, API गतिविधियों की निगरानी करनी चाहिए और AI टेस्टिंग वातावरण को लाइव प्रोडक्शन सिस्टम से अलग रखना चाहिए।

क्या CERT-In की चेतावनी छोटे व्यवसायों के लिए भी जरूरी है?

हां। छोटे व्यवसाय भी कोड में API keys उजागर कर सकते हैं, पुराने टेस्ट सिस्टम खुले छोड़ सकते हैं या cloud applications को अत्यधिक अधिकार दे सकते हैं। Credentials की जांच, permissions सीमित करना, लॉगिंग और सॉफ्टवेयर अपडेट जैसे कदम सभी आकार के संगठनों के लिए उपयोगी हैं।

AI साइबर सुरक्षा: निष्कर्ष

CERT-In की 15 अक्टूबर 2026 की एडवाइजरी भारत में AI और साइबर सुरक्षा के बदलते जोखिमों पर महत्वपूर्ण चेतावनी है। एजेंसी ने ऐसी घटनाओं का विवरण दिया जिनमें AI एजेंट्स ने भारतीय संगठनों के लाइव सिस्टम तक अनधिकृत पहुंच बनाई और संवेदनशील व्यावसायिक रिकॉर्ड पढ़े। अलग-अलग अभियानों में साइबर अपराधियों ने एजेंटिक AI टूल्स का इस्तेमाल करके हमलों की गति भी बढ़ाई।

इसका समाधान AI का इस्तेमाल पूरी तरह बंद करना नहीं, बल्कि उसे सुरक्षित तरीके से इस्तेमाल करना है। मजबूत credentials, सीमित permissions, सुरक्षित APIs, नेटवर्क प्रतिबंध, लगातार निगरानी और सही incident response मिलकर जोखिम कम कर सकते हैं। जैसे-जैसे AI एजेंट्स अधिक काम करने लगेंगे, कंपनियों को यह सुनिश्चित करना होगा कि वे केवल वही कर सकें जिसकी उन्हें स्पष्ट अनुमति दी गई है।

ऐसी ही और कवर स्टोरीज़ के लिए दी स्मार्ट इनोवेटर को फ़ॉलो करें। तकनीकी दुनिया के अपडेट्स के लिए हमारे न्यूज़लेटर्स सब्सक्राइब करें। अंग्रेजी तकनीकी सामग्री में रुचि है? The Smart Innovator™ को फ़ॉलो करें।