Noma Labs ने दिखाया है कि AI-संचालित ऑटोमेशन का उपयोग करके एक अकेला सार्वजनिक GitHub issue निजी रिपॉजिटरी (private repositories) से कोड चुरा सकता है। उनका proof-of-concept एक हमलावर को किसी संगठन के अपने ही वर्कफ़्लो बॉट्स को उसके खिलाफ इस्तेमाल करने की अनुमति देता है, जिससे GitHub के ऑथेंटिकेशन (authentication) को तोड़े बिना ही मालिकाना फाइलें लीक हो जाती हैं।
हमले का साफ़ तौर पर दिखने वाला तरीका
घटनाओं का क्रम इतना सरल है कि इसे दोहराया जा सकता है:
- एक हमलावर एक सार्वजनिक रिपॉजिटरी में एक issue बनाता है जिसे कोई भी देख सकता है।
- एक AI एजेंट, जो continuous-integration पाइपलाइन से जुड़ा होता है, issue के शीर्षक और विवरण (body) को पढ़ता है।
- उसी एजेंट के पास पहले से ही संगठन की अन्य निजी रिपॉजिटरी के लिए read permissions होती हैं।
- सार्वजनिक issue में छिपे हुए निर्देश एजेंट को बताते हैं कि कौन सी निजी फाइलें प्राप्त करनी हैं।
- एजेंट प्राप्त की गई फाइलों को सार्वजनिक issue में एक कमेंट के रूप में वापस पोस्ट कर देता है, जिससे वे दुनिया के सामने आ जाती हैं।
यह सब ऑटोमेशन के एक ही रन में हो जाता है। न कोई क्रेडेंशियल चोरी, न कोई API-key लीक, और न ही GitHub में कोई भेद्यता (vulnerability)। हमलावर बस उस भरोसे का फायदा उठाता है जो संगठन ने अपने ही बॉट पर किया था।
यह अभी क्यों महत्वपूर्ण है
AI-संचालित एजेंट अब आधुनिक डेवलपमेंट पाइपलाइनों को आपस में जोड़ते हैं। वे pull-requests खोलते हैं, टेस्ट चलाते हैं, बिल्ड डिप्लॉय करते हैं, और बग्स को सुलझाते हैं (triage)—ये सभी कार्य issue कमेंट्स जैसे हल्के संकेतों (lightweight signals) द्वारा ट्रिगर होते हैं। जब उन एजेंटों के पास व्यापक रिपॉजिटरी एक्सेस होता है, तो भरोसेमंद डेटा और अविश्वसनीय यूजर इनपुट के बीच की रेखा धुंधली हो जाती है।
यदि एक एजेंट एक ही निष्पादन (execution) में निजी कोड पढ़ सकता है और सार्वजनिक रूप से लिख सकता है, तो संगठन का एक्सेस-कंट्रोल मॉडल ध्वस्त हो जाता है।
असली खामी: परमिशन, मॉडल नहीं
यह प्रदर्शन अंतर्निहित AI मॉडल को दोषी नहीं ठहराता है। मॉडल केवल उन निर्देशों का पालन करता है जो उसे मिलते हैं। भेद्यता (vulnerability) ऑटोमेशन को दी गई परमिशन सेट में निहित है:
- संगठन की निजी रिपॉजिटरी तक Read access।
- सार्वजनिक issue थ्रेड्स तक Write access।
- सार्वजनिक टेक्स्ट पर Trigger, जिसे कोई भी बना सकता है।
समाधान जिनमें कोई खर्च नहीं आता, लेकिन वे प्रभावी हैं
'लीस्ट प्रिविलेज' (least privilege) के सिद्धांत को लागू करने से हमले का रास्ता काफी हद तक कम हो जाता है:
- बॉट का स्कोप (Scope) सीमित करें: बॉट को केवल उसी रिपॉजिटरी तक सीमित रखें जहाँ उसकी आवश्यकता है। यदि उसे केवल एक विशिष्ट रिपॉजिटरी पर काम करने की आवश्यकता है, तो उसे अन्य किसी भी read अधिकार देने से मना कर दें।
- Read और write टोकन को अलग रखें: कोड प्राप्त करने के लिए एक क्रेडेंशियल का उपयोग करें और कमेंट पोस्ट करने के लिए दूसरे, कड़ाई से नियंत्रित क्रेडेंशियल का उपयोग करें।
- मानवीय अनुमोदन (Human approval): किसी भी सार्वजनिक पोस्टिंग से पहले मानवीय समीक्षा सुनिश्चित करें। एक हल्का समीक्षा चरण—जैसे कि एक आवश्यक अप्रूवल लेबल—पाइपलाइन को रोके बिना एक चेकपॉइंट जोड़ता है।
- ब्लास्ट-रेडियस (Blast-radius) कम करें: वर्कफ़्लो को इस तरह डिज़ाइन करें कि विफलता या दुरुपयोग से अधिकतम एक रिपॉजिटरी प्रभावित हो, न कि पूरा संगठन।
काउंटर-पॉइंट: ऑपरेशनल ओवरहेड
आगे क्या देखें
निष्कर्ष (Takeaway): यदि एक AI ऑटोमेशन निजी कोड देख सकता है और सार्वजनिक रूप से लिख भी सकता है, तो सिस्टम का डिज़ाइन गलत है। परमिशन को सख्त करें, मानवीय जांच (human checks) शामिल करें, और ब्लास्ट रेडियस को छोटा रखें—वरना एक अकेला सार्वजनिक issue डेटा-लीक का जरिया बन सकता है।