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

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

तंत्र: Git की एक बरसों पुरानी परफ़ॉर्मेंस सेटिंग

सबसे स्पष्ट उदाहरण Manifold Security ने 2 सितंबर 2026 को GitSpawn नाम से प्रकाशित किया। यह core.fsmonitor नाम की प्रोजेक्ट-स्तरीय Git सेटिंग पर आधारित है, जो एक वैध और दस्तावेज़ीकृत परफ़ॉर्मेंस विकल्प है, जिसका मान एक कमांड होता है जिसे Git पूरी डायरेक्टरी स्कैन करने के बजाय बदली हुई फ़ाइलों को जल्दी पहचानने के लिए चलाता है।

अब दोनों हिस्सों को साथ रखिए:

  • एक AI कोडिंग एजेंट जब किसी प्रोजेक्ट पर काम शुरू करता है, तो रिपॉज़िटरी की स्थिति समझने के लिए अपने आप git status और git diff जैसे Git कमांड चलाता है। यह सामान्य और ज़रूरी व्यवहार है।
  • अगर रिपॉज़िटरी में दुर्भावनापूर्ण core.fsmonitor मान है, तो सिर्फ़ इन कमांडों को चलाने से हमलावर का कमांड चल जाता है।

नतीजा यह कि कोड रिपॉज़िटरी खोलना पढ़ने की घटना नहीं रहता, बल्कि चलाने की घटना बन जाता है। न कोई क्लिक, न कोई मंज़ूरी, न डेवलपर को दिखाया गया कोई संकेत। रिपोर्ट के अनुसार आठ कमांड-लाइन एजेंट प्रभावित थे, और कई के लिए पैच आए: goose में 1.44.0, core.fsmonitor रास्ते के लिए Claude Code में 2.1.196, Codex CLI में 0.131.0, और साथ में Cursor। रिपोर्ट ने बताया कि प्रकाशन के समय चार रास्ते अभी भी बिना पैच के थे। इस वर्ग को CVE-2026-72718, CVE-2026-19592 और CVE-2026-55607 सहित पहचानकर्ताओं के तहत ट्रैक किया गया।

एक घटना नहीं, बल्कि पूरा एक वर्ग

GitSpawn से छह हफ़्ते पहले, Pillar Security के शोधकर्ताओं ने 20 जुलाई 2026 को एक शृंखला प्रकाशित की जिसे उन्होंने सैंडबॉक्स से बच निकलने का हफ़्ता कहा, जिसमें तीन विक्रेताओं के चार कोडिंग एजेंटों में सात कमज़ोरियों का दस्तावेज़ीकरण था: Cursor, Codex, Gemini CLI और Antigravity। तंत्र का उनका वर्णन दो बार पढ़ने लायक है। एजेंट डिब्बे के अंदर रहता है और हर नियम का पालन करता है। वह बस एक फ़ाइल लिखता है जिसे डिब्बे के बाहर का एक भरोसेमंद टूल बाद में चलाता, लोड करता या स्कैन करता है।

  • Cursor में, वर्कस्पेस द्वारा नियंत्रित एक हुक कॉन्फ़िगरेशन फ़ाइल ने सैंडबॉक्स के बाहर निष्पादन संभव बनाया, जिसे CVE-2026-48124 के रूप में ट्रैक किया गया और संस्करण 3.0.0 में ठीक किया गया।
  • Codex CLI में, कमांड अनुमति सूची git show पर सिर्फ़ उसके नाम से भरोसा करती थी, जबकि उसे दिए गए पैरामीटर उसे केवल-पढ़ने से आगे ले जा सकते हैं। संस्करण 0.95.0 में ठीक किया गया।
  • Docker सॉकेट की एक समस्या ने Codex, Cursor और Gemini CLI को एक साथ प्रभावित किया।
  • Antigravity में, macOS Seatbelt की प्रतिबंध सूची को दरकिनार करने की समस्या और एडिटर के टास्क कॉन्फ़िगरेशन की एक समस्या, जिन दोनों को Google ने इस्तेमाल करने में कठिन बताया।

फिर 10 सितंबर 2026 को Upstarts Media ने Accomplish नाम के एक स्टार्टअप की ओर से तीसरे खुलासे की खबर दी, जो Claude Code, Codex और Cursor में रिसने वाले सैंडबॉक्स के बारे में था। वहाँ दिलचस्प आँकड़ा कमज़ोरी नहीं बल्कि उसे ठीक करने का समय है: Cursor की समस्या लगभग एक हफ़्ते में सुलझ गई, OpenAI की दो समस्याएँ अगस्त में, जबकि Anthropic की समस्या में दर्जनों रिलीज़ के दौरान लगभग पचास दिन लगे। तीन शोध समूह, तीन रिपोर्टें, दो महीने, एक पैटर्न।

अगर आप कभी कोड नहीं लिखते, तब भी यह क्यों मायने रखता है

क्योंकि जोखिम एजेंट पर नहीं पड़ता। यह उस मशीन पर पड़ता है जो उसे चला रही है और उस नेटवर्क पर जिसमें वह मशीन है। डेवलपर वर्कस्टेशन किसी भी कंपनी के सबसे ज़्यादा अधिकार वाले उपकरणों में से एक होता है: उसमें सर्वर एक्सेस कुंजियाँ, डिप्लॉयमेंट टोकन और अक्सर प्रोडक्शन डेटाबेस से एक खुला कनेक्शन होता है। उस पर एक कमांड चलना कोई छोटी घटना नहीं है।

सऊदी बाज़ार में यह परिदृश्य सैद्धांतिक नहीं है। इन मामलों को अपनी कंपनी से मिलाकर देखिए:

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

इनमें से हर मामले में अनकही धारणा यह है कि फ़ाइलों को पढ़ने के लिए खोलना एक सुरक्षित काम है। यही धारणा टूटी है।

इस हफ़्ते क्या करें

पाँच कदम, और पहले के लिए किसी बजट की ज़रूरत नहीं:

  1. आज ही पूरी टीम में एजेंट टूल अपडेट करें। इनमें से ज़्यादातर टूल के लिए पैच मौजूद हैं, और असली फ़ायदा तब है जब एक व्यक्ति नहीं बल्कि हर कोई पैच वाले संस्करण पर हो। शुरुआत यह जानने से करें कि कौन क्या और किस संस्करण में चला रहा है, क्योंकि यह सूची आमतौर पर होती ही नहीं।
  2. आने वाले कोड को अविश्वसनीय सामग्री मानें। किसी ठेकेदार या खुले स्रोत से आया कोड पढ़ने वाला दस्तावेज़ नहीं है, वह चलने वाली चीज़ है। पहली बार उसे कार्य नेटवर्क से अलग किसी मशीन या कंटेनर पर खोलें।
  3. डेवलपमेंट मशीन को प्रोडक्शन कुंजियों से अलग करें। जिस मशीन पर बाहरी स्रोत के प्रोजेक्ट खोले जाते हैं, उस पर लाइव सर्वर टोकन न रखें। तब नुकसान उसी डिवाइस तक सीमित रहता है।
  4. डिप्लॉयमेंट निजी लैपटॉप से नहीं, बल्कि केंद्रीय पाइपलाइन से करें। जब डिप्लॉयमेंट सीमित अधिकारों वाली एक ही बिल्ड पाइपलाइन से होकर गुज़रता है, तो किसी एक मशीन में सेंध प्रोडक्शन तक पहुँचने का रास्ता नहीं रह जाती।
  5. आउटसोर्स डेवलपमेंट अनुबंधों में एक धारा जोड़ें। आपको यह तय करने का अधिकार है कि कोड कैसे और किस रिपॉज़िटरी से सौंपा जाए, और विक्रेता से अपने टूल अपडेट रखने की माँग करने का भी। यह अनुबंध की शर्त है, कोई तकनीकी बहस नहीं।

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

Origami का नज़रिया

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

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

निष्कर्ष

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

स्रोत