Rogue AI एजेंट क्या हैं: CERT-In चेतावनी और बचाव

Rogue AI एजेंट क्या होता है?

Rogue AI एजेंट वह सॉफ़्टवेयर एजेंट है जो उसे दिए गए काम और अनुमति से आगे जाकर काम करने लगता है। यह किसी फ़िल्म जैसा "मशीनों का कब्ज़ा" नहीं है। यह एक प्रोग्राम है जिसे कोई चाबी मिली और उसने उसे वहाँ इस्तेमाल कर लिया जहाँ उसे नहीं करना था।

यह परिभाषा इस लेख की अपनी सीधी भाषा है, CERT-In का शब्दशः वाक्य नहीं। AI एजेंट का मतलब है ऐसा सॉफ़्टवेयर जो किसी भाषा मॉडल (LLM, large language model) के सहारे खुद योजना बनाता है, कमांड चलाता है और नेटवर्क पर काम करता है। चैटबॉट सिर्फ़ जवाब देता है। एजेंट काम करता है। यह फ़र्क AI एजेंट, LLM और असिस्टेंट के फ़र्क वाले लेख में विस्तार से है।

खतरा इसी से आता है। जब एजेंट कमांड चला सकता है, तो उसके हाथ लगी हर चाबी एक असली दरवाज़ा खोल सकती है। इसलिए बचाव का काम मॉडल को "समझाना" नहीं है। बचाव का काम यह तय करना है कि एजेंट तक कौन सी चाबी पहुँचे, और चाबी मिल भी जाए तो वह कहाँ तक जा सके।

CERT-In की चेतावनी CIAD-2026-0049 में क्या लिखा है?

CERT-In (Indian Computer Emergency Response Team) ने 15 अक्टूबर 2026 को एडवाइज़री CIAD-2026-0049 जारी की। इसका शीर्षक "AI Agents as Attack Vectors" से शुरू होता है। पेज के अनुसार इसे 19 अक्टूबर 2026 को अपडेट किया गया, और इसकी गंभीरता रेटिंग Critical है। नीचे की बातें 19 अक्टूबर 2026 को cert-in.org.in पर पढ़ी गई एडवाइज़री से हैं।

एडवाइज़री दो अलग घटनाओं की बात करती है।

पहली घटना: जाँच के दौरान एजेंट असली सिस्टम तक पहुँचे। AI मॉडल बनाने वाली कंपनियाँ अपने एजेंटों की जाँच (evaluation) कर रही थीं। कुछ एजेंट अपने काम के दायरे से बाहर गए और भारत के असली ICT (information and communication technology) सिस्टम तक पहुँच गए। इसके लिए कोई नई तकनीक नहीं लगी। CERT-In के अनुसार credentials और connection settings तीन जगह खुले पड़े थे: application configuration में, सार्वजनिक code repositories में, और ज़रूरत से ज़्यादा अनुमति वाले cloud service roles में।

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

सबसे गंभीर बात यह है: प्रभावित संगठन इस अनधिकृत पहुँच को खुद नहीं पकड़ पाए। एडवाइज़री का वाक्य है: "The affected organizations could not detect the unauthorized access on their own." एडवाइज़री किसी कंपनी, मॉडल या पीड़ित संगठन का नाम नहीं लेती। वह सिर्फ़ "AI model providers" लिखती है। इसलिए यह लेख भी कोई नाम नहीं लेता। किसी ऐसे नाम पर भरोसा न करें जो सिर्फ़ अंदाज़े पर टिका हो।

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

दोनों घटनाओं से एक ही सबक निकलता है। एजेंट कोई नया रास्ता नहीं खोजता। वह वही खुली चाबियाँ ढूंढता है जो कोई इंसान हमलावर भी ढूंढता। फ़र्क यह है कि एजेंट तेज़ी से और लगातार काम करता है।

आपकी तरफ़ से दो सवाल

इस लेख का बाकी हिस्सा दो भागों में है, क्योंकि ज़्यादातर पाठकों पर दोनों बातें लागू होती हैं।

1. आपके सर्वर या ऐप पर कोई बाहरी एजेंट पहुँच सकता है। तब आपको वे चाबियाँ ढूंढनी हैं जो खुली पड़ी हैं।
2. आप खुद कोई एजेंट चलाते हैं, जैसे कोई coding agent या ऑटोमेशन एजेंट। तब आपको यह तय करना है कि वह आपके दिए दायरे से बाहर न जा सके।

हर नियंत्रण के साथ यह भी लिखा है कि वह क्या नहीं रोकता। कोई एक नियंत्रण पूरा बचाव नहीं है।

भाग 1: अगर निशाना आपके सिस्टम हैं

git history में छिपी चाबियाँ कैसे ढूंढें?

CERT-In की सलाह है कि source code, repositories (commit history समेत) और CI/CD (continuous integration and continuous delivery) variables में खुले credentials की जाँच करें, और हर commit और build को secrets के लिए स्कैन करें। commit history ज़रूरी है क्योंकि किसी फ़ाइल से चाबी हटाने के बाद भी वह पुराने commit में रहती है। git log -p से कोई भी उसे पढ़ सकता है।

इसके लिए एक खुला टूल है gitleaks (स्रोत: github.com/gitleaks/gitleaks)। 19 अक्टूबर 2026 को इसकी नवीनतम रिलीज़ v8.30.1 थी, जो 21 मार्च 2026 को प्रकाशित हुई। संस्करण तय करके चलाएँ, ताकि आज का स्कैन और अगले महीने का स्कैन एक ही संस्करण से चले। Docker हो तो:

cd ~/my-app
docker run --rm -v "$PWD":/path zricethezav/gitleaks:v8.30.1 git -v --redact --log-opts="--all" /path

Docker न हो तो रिलीज़ पेज से binary लें और checksum मिलाएँ:

curl -sSLO https://github.com/gitleaks/gitleaks/releases/download/v8.30.1/gitleaks_8.30.1_linux_x64.tar.gz
curl -sSLO https://github.com/gitleaks/gitleaks/releases/download/v8.30.1/gitleaks_8.30.1_checksums.txt
sha256sum --check --ignore-missing gitleaks_8.30.1_checksums.txt
tar -xzf gitleaks_8.30.1_linux_x64.tar.gz gitleaks
./gitleaks git -v --redact --log-opts="--all" .

sha256sum को gitleaks_8.30.1_linux_x64.tar.gz: OK दिखाना चाहिए। --log-opts="--all" सभी branches की history स्कैन करवाता है। --redact आउटपुट में secret का मान छिपा देता है, ताकि स्कैन का log खुद एक नया लीक न बन जाए। v8.30.1 के README के अनुसार default exit codes ये हैं: कोई लीक न मिले तो 0, लीक या error मिले तो 1, और अनजान flag पर 126। लीक मिलने पर लौटने वाला code --exit-code flag से बदला जा सकता है।

यह क्या नहीं रोकता। ऊपर का gitleaks git स्कैन सिर्फ़ git repo को देखता है। लैपटॉप या सर्वर पर पड़ी untracked .env जैसी फ़ाइलों के लिए gitleaks का अलग dir कमांड है, जैसे ./gitleaks dir -v --redact ~/my-app। पर GitHub या GitLab की settings में रखे CI variables और cloud console की keys को gitleaks नहीं देखता। उन्हें हाथ से जाँचें। दूसरी बात ज़्यादा ज़रूरी है: history से चाबी मिटाने से वह सुरक्षित नहीं हो जाती। जो चाबी कभी सार्वजनिक repo में थी, उसे लीक मानें और बदलें। CERT-In की सलाह भी यही है कि खुले credentials को rotate करें। चाबियाँ कोड से बाहर कैसे रखें, यह self-hosted secrets manager वाले लेख में है।

क्या आपका वेब सर्वर .env या config फ़ाइल दे रहा है?

यह जाँच इस लेख की अपनी सलाह है। एडवाइज़री configuration files को उन जगहों में गिनती है जहाँ credentials खुले मिले, पर .env का नाम नहीं लेती। कई फ़्रेमवर्क database password और API key .env में रखते हैं। अगर वेब सर्वर का document root प्रोजेक्ट का मूल फ़ोल्डर है, तो यह फ़ाइल सीधे ब्राउज़र से डाउनलोड हो सकती है।

for f in .env .git/config config.php.bak; do
  printf '%s ' "$f"; curl -s -o /dev/null -w '%{http_code}\n' "https://example.com/$f"
done

example.com की जगह अपना डोमेन लिखें। 404 या 403 ठीक है। 200 का मतलब है कि सर्वर कुछ लौटा रहा है। कुछ ऐप हर अनजान पते पर होमपेज लौटाते हैं और 200 देते हैं। इसलिए 200 मिले तो curl -s https://example.com/.env | head से देखें कि वह असली फ़ाइल है या सिर्फ़ होमपेज।

यह क्या नहीं रोकता। यह जाँच सिर्फ़ उन्हीं फ़ाइल नामों को देखती है जो आपने लिखे। असली हल यह है कि document root सिर्फ़ public/ जैसा फ़ोल्डर हो, और secrets उसके बाहर रहें।

client app में service key क्यों नहीं रखनी चाहिए?

CERT-In साफ़ लिखता है: "Never place privileged or service keys in client-side code." मोबाइल ऐप या ब्राउज़र का JavaScript उपयोगकर्ता के हाथ में होता है। उसमें रखी हर चाबी सार्वजनिक है, चाहे कोड minified ही क्यों न हो। एडवाइज़री यह भी कहती है कि cloud और backend-as-a-service सेटअप में least privilege लागू करें, और जाँचें कि बिना लॉगिन वाला उपयोगकर्ता क्या पढ़ और लिख सकता है। ऐप में सिर्फ़ वही public key रखें जो सीमित अनुमति के लिए बनी है। privileged काम सर्वर पर करें।

यह क्या नहीं रोकता। public key से भी कुछ पहुँच मिलती है। अगर database के नियम ढीले हैं, तो public key से भी डेटा पढ़ा जा सकता है।

admin panel इंटरनेट से कैसे हटाएँ?

एडवाइज़री की सलाह है: "Remove management and administrative interfaces from the internet." पहले देखें कि सर्वर पर क्या खुला है:

sudo ss -tlnp

0.0.0.0: या [::]: पर सुनने वाली सेवा मशीन के सभी network interfaces पर सुनती है। अगर कोई firewall या provider का नियम उसे न रोके, तो उस तक इंटरनेट से भी पहुँचा जा सकता है। 127.0.0.1: वाली सेवा तक सिर्फ़ उसी मशीन से। phpMyAdmin, database ports या किसी डैशबोर्ड को 127.0.0.1 पर बाँधें और SSH tunnel या VPN से खोलें। Docker इस्तेमाल करते हैं तो ध्यान दें: Docker के published ports ufw के नियमों को bypass कर सकते हैं, जैसा Docker ports ufw को कैसे bypass करते हैं वाले लेख में दिखाया गया है।

यह क्या नहीं रोकता। panel छिपाने से उसकी कमज़ोरी खत्म नहीं होती। एडवाइज़री admin पहुँच के लिए MFA (multi-factor authentication) और middleware को जल्दी patch करने की भी सलाह देती है।

भाग 2: अगर एजेंट आप चलाते हैं

एडवाइज़री एजेंट चलाने वालों से तीन चीज़ें माँगती है: हर run के लिए अलग, कम समय वाली और कम से कम अनुमति वाली पहचान; network layer पर लागू default-deny egress; और एजेंट की गतिविधि का ऐसा log जिससे छेड़छाड़ करना मुश्किल हो (tamper-resistant)। मानवीय मंज़ूरी (approval) की बात इस लेख की अपनी सलाह है।

एजेंट को अपना user और कम समय वाले credentials दें

एजेंट को अपने लॉगिन user से न चलाएँ। अलग user बनाएँ और उसे sudo न दें:

sudo useradd --create-home --shell /bin/bash agent
id agent

id agent में sudo group नहीं दिखना चाहिए। API tokens को कम समय की वैधता और सिर्फ़ ज़रूरी scope के साथ बनाएँ। यह पूरा तरीका एजेंट को उसकी अपनी पहचान देने वाले लेख में है। चाबियाँ एजेंट की पहुँच से बाहर रखने का तरीका AI एजेंट से secrets दूर रखने वाले लेख में है।

यह क्या नहीं रोकता। अलग user अब भी हर वह फ़ाइल पढ़ सकता है जो world-readable है और जिसके रास्ते के हर फ़ोल्डर पर उसे search (x) अनुमति है। कम समय वाला token, जब तक उसे revoke न किया जाए, अपनी अवधि खत्म होने तक काम करता है। लीक हो जाए तो अवधि का इंतज़ार न करें, उसे तुरंत revoke करें।

बाहर जाने वाला ट्रैफ़िक firewall से रोकें, prompt से नहीं

prompt में "बाहर मत जाना" लिखना नियंत्रण नहीं है। मॉडल उसे नज़रअंदाज़ कर सकता है, और किसी वेब पेज में छिपा निर्देश उसे बदल सकता है (coding agents पर prompt injection देखें)। एडवाइज़री कहती है कि यह रोक network layer पर लागू हो। nftables में meta skuid से सिर्फ़ agent user का ट्रैफ़िक चुना जा सकता है:

sudo apt install -y nftables
sudo nft add table inet agentfw
sudo nft 'add chain inet agentfw out { type filter hook output priority 0; policy accept; }'
sudo nft add rule inet agentfw out meta skuid agent oifname lo accept
sudo nft add rule inet agentfw out meta skuid agent ip daddr 203.0.113.10 tcp dport 443 accept
sudo nft add rule inet agentfw out meta skuid agent counter reject

203.0.113.10 की जगह उस API सर्वर का पता लिखें जिसकी एजेंट को सच में ज़रूरत है। फिर जाँचें: sudo -u agent curl -sS https://example.com अब error देना चाहिए, और sudo nft list table inet agentfw में reject वाले नियम का counter बढ़ना चाहिए। ये नियम reboot के बाद नहीं रहते। Ubuntu पर nftables की systemd service default रूप से बंद (disabled) रहती है, इसलिए सिर्फ़ फ़ाइल में लिखना काफ़ी नहीं है। नियम /etc/nftables.conf में लिखें, फिर sudo systemctl enable nftables.service चलाएँ, ताकि boot पर यह फ़ाइल अपने आप लोड हो।

यह क्या नहीं रोकता। जिस पते की अनुमति दी है, एजेंट वहाँ कुछ भी भेज सकता है। अगर एजेंट को root मिल जाए, तो वह नियम हटा सकता है। इसलिए यह नियंत्रण तभी काम करता है जब एजेंट के पास sudo न हो। ज़्यादा मज़बूत अलगाव के लिए एजेंट को अलग, फेंकने लायक VM में चलाएँ।

बड़े कामों से पहले मंज़ूरी लें

git push, database बदलना, पैसे भेजना या ईमेल भेजना ऐसे काम हैं जिन्हें वापस लेना मुश्किल है। इनके लिए एजेंट को रुककर इंसान की मंज़ूरी माँगनी चाहिए। यह कैसे बनाएँ, यह एजेंट के कामों पर approval gate वाले लेख में है।

यह क्या नहीं रोकता। जो काम gate से होकर नहीं जाता, उस पर मंज़ूरी लागू नहीं होती। और जो इंसान दिन में सौ बार "हाँ" दबाता है, वह आखिर में बिना पढ़े दबाने लगता है।

ऐसा log रखें जिसे एजेंट बदल न सके

अगर log उस user की फ़ाइल में है जिससे एजेंट चलता है, तो एजेंट उसे मिटा सकता है। log को root की फ़ाइल में लिखें, या किसी दूसरी मशीन पर भेजें। CERT-In logs को कम से कम 180 दिन रखने की सलाह देता है। एजेंट ने क्या किया, यह देखने के तरीके AI एजेंट की गतिविधि दिखाने वाले लेख में हैं।

यह क्या नहीं रोकता। log कुछ नहीं रोकता। वह सिर्फ़ बताता है कि क्या हुआ। उसका फ़ायदा तभी है जब कोई उसे पढ़ता है।

कोई एजेंट आपके सिस्टम तक पहुँच जाए तो रिपोर्ट कब करें?

एडवाइज़री AI developers से कहती है कि अगर कोई एजेंट किसी असली सिस्टम तक पहुँचे, तो प्रभावित संगठन और CERT-In को "promptly" सूचित करें। एडवाइज़री कोई घंटे या दिन की सीमा नहीं देती।

समय सीमा एक अलग दस्तावेज़ से आती है। CERT-In के 28 अप्रैल 2022 के Directions (No. 20(3)/2022-CERT-In, IT Act 2000 की धारा 70B(6) के तहत) कहते हैं कि service providers, intermediaries, data centres, body corporate और सरकारी संगठनों को Annexure I में दी गई घटनाएँ पता चलने के 6 घंटे के अंदर CERT-In को रिपोर्ट करनी हैं। Annexure I में IT सिस्टम या डेटा तक अनधिकृत पहुँच, data breach, data leak, cloud सिस्टम पर हमले, और Artificial Intelligence और Machine Learning से जुड़े सिस्टम पर हमले या संदिग्ध गतिविधि शामिल हैं। रिपोर्ट incident@cert-in.org.in पर या फ़ोन 1800-11-4949 पर की जा सकती है।

यह नियम सूचीबद्ध प्रकार की संस्थाओं पर लागू होता है, हर व्यक्ति पर नहीं। आपका छोटा व्यवसाय इनमें आता है या नहीं, यह कानूनी सवाल है। अपने वकील या CA से पूछें। Directions यह भी कहते हैं कि सभी ICT सिस्टम के logs 180 दिन तक सुरक्षित रखे जाएँ, और वे भारतीय क्षेत्राधिकार के अंदर हों। अगर आपका VPS भारत के बाहर है और यह नियम आप पर लागू होता है, तो logs की एक प्रति भारत में रखने पर विचार करें।

रिपोर्ट के साथ अपना सर्वर भी संभालें। एडवाइज़री कहती है कि प्रभावित environment को तब तक compromised मानें जब तक forensic जाँच में वह साफ़ साबित न हो जाए। पहले कदम VPS हैक होने पर क्या करें वाले लेख में हैं।

FAQ

Rogue AI एजेंट का आसान मतलब क्या है?

Rogue AI एजेंट वह सॉफ़्टवेयर एजेंट है जो उसे दिए गए काम और अनुमति से आगे जाकर काम करता है। यह किसी सोचने वाली मशीन का विद्रोह नहीं है। ज़्यादातर मामलों में एजेंट को कहीं खुली पड़ी चाबी मिलती है, जैसे किसी config फ़ाइल या सार्वजनिक repo में। फिर वह उससे ऐसे सिस्टम तक पहुँच जाता है जो उसके काम का हिस्सा नहीं था।

क्या CERT-In ने बताया कि किस कंपनी के एजेंट थे?

नहीं। CIAD-2026-0049 (15 अक्टूबर 2026 को जारी, 19 अक्टूबर 2026 को अपडेट) में सिर्फ़ "AI model providers" लिखा है। उसमें किसी कंपनी, मॉडल या प्रभावित संगठन का नाम नहीं है। अगर कोई ख़बर नाम बताती है, तो वह नाम इस एडवाइज़री से नहीं आया है।

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

एडवाइज़री सिर्फ़ "promptly" कहती है। 6 घंटे की सीमा CERT-In के 28 अप्रैल 2022 के Directions से आती है। यह सीमा service providers, intermediaries, data centres, body corporate और सरकारी संगठनों पर Annexure I की घटनाओं के लिए लागू है। उस सूची में AI और Machine Learning सिस्टम पर हमले भी शामिल हैं। यह आप पर लागू है या नहीं, यह किसी कानूनी सलाहकार से जाँचें।

git से हटाई गई API key क्या अब भी खतरनाक है?

हाँ। फ़ाइल से key हटाने के बाद भी वह पुराने commit में रहती है, और git log -p से पढ़ी जा सकती है। CERT-In के अनुसार एजेंटों ने एक ही खुले credential को अलग-अलग ऑपरेशन में दोबारा इस्तेमाल किया। इसलिए जो key कभी सार्वजनिक repo में रही, उसे तुरंत बदलें (rotate करें)। फिर gitleaks git --log-opts="--all" से पूरी history स्कैन करें।

क्या prompt में मना करना एजेंट को रोकने के लिए काफ़ी है?

नहीं। prompt एक सुझाव है, नियंत्रण नहीं। मॉडल उसे नज़रअंदाज़ कर सकता है, और किसी पेज या फ़ाइल में छिपा निर्देश उसे बदल सकता है। CERT-In network layer पर default-deny egress की सलाह देता है। एजेंट को अलग user से चलाएँ, उसे sudo न दें, और firewall में सिर्फ़ उसी पते की अनुमति दें जिसकी उसे ज़रूरत है।