Noma Labs ने दाखवून दिले आहे की, AI-चालित ऑटोमेशनचा वापर करून एका सिंगल पब्लिक GitHub issue द्वारे प्रायव्हेट रिपॉझिटरीजमधून कोड चोरला जाऊ शकतो. त्यांच्या proof-of-concept मुळे एखादा अटॅकर संस्थेच्या स्वतःच्या वर्कफ्लो बॉट्सचा त्यांच्याच विरोधात वापर करू शकतो, ज्यामुळे GitHub चे ऑथेंटिकेशन तोडल्याशिवाय मालकी हक्क असलेले (proprietary) फाइल्स लीक होऊ शकतात.

स्पष्टपणे दिसणारा हल्ला

ही घटना पुनरावृत्ती करणे पुरेसे सोपे आहे:

  • एखादा अटॅकर पब्लिक रिपॉझिटरीमध्ये एक issue तयार करतो जो कोणीही पाहू शकतो.
  • continuous-integration pipeline शी जोडलेला एक AI agent, त्या issue चे शीर्षक आणि मजकूर वाचतो.
  • त्याच agent कडे संस्थेतील इतर प्रायव्हेट रिपॉझिटरीजसाठी आधीपासूनच 'read permissions' असतात.
  • पब्लिक issue मधील लपविलेले निर्देश (hidden instructions) agent ला सांगतात की कोणत्या प्रायव्हेट फाइल्स मिळवायच्या आहेत.
  • तो agent मिळवलेल्या फाइल्स पब्लिक issue मध्ये कमेंट म्हणून पोस्ट करतो, ज्यामुळे त्या जगासमोर उघड होतात.

हे सर्व ऑटोमेशनच्या एकाच रनमध्ये घडते. यामध्ये कोणतीही credential चोरी, API-key लीक किंवा GitHub मधील त्रुटी (vulnerability) नसते. अटॅकर केवळ संस्थेने आपल्या स्वतःच्या बॉटवर ठेवलेल्या विश्वासाचा फायदा घेतो.

हे आता का महत्त्वाचे आहे

AI-powered agents आता आधुनिक डेव्हलपमेंट पाइपलाईन्सना एकत्र जोडण्याचे काम करतात. ते pull-requests उघडतात, टेस्ट्स रन करतात, बिल्ड्स डिप्लॉय करतात आणि बग्स triage करतात—हे सर्व issue comments सारख्या हलक्या सिग्नलद्वारे ट्रिगर केले जाते. जेव्हा या agents कडे रिपॉझिटरीचा व्यापक प्रवेश (broad access) असतो, तेव्हा विश्वसनीय डेटा आणि अविश्वसनीय युजर इनपुट यातील रेषा धूसर होते.

जर एखादा agent एकाच एक्झिक्यूशनमध्ये प्रायव्हेट कोड वाचू शकत असेल आणि सार्वजनिकरित्या लिहू शकत असेल, तर संस्थेचे access-control मॉडेल कोलमडते.

खरी त्रुटी: परवानग्या (permissions), मॉडेल नाही

हे प्रात्यक्षिक मूळ AI मॉडेलला दोषी ठरवत नाही. मॉडेल केवळ त्याला मिळालेल्या सूचनांचे पालन करते. ही त्रुटी ऑटोमेशनला दिलेल्या परवानग्यांच्या (permission set) संचात आहे:

  • संस्थेतील सर्व प्रायव्हेट रिपॉझिटरीजसाठी Read access.
  • पब्लिक issue थ्रेड्ससाठी Write access.
  • कोणीही तयार करू शकणाऱ्या पब्लिक टेक्स्टवर आधारित Trigger.

मोफत उपाय, पण प्रभावी

'Principle of least privilege' लागू केल्याने हल्ल्याचा मार्ग कमी होतो:

  • बॉटची व्याप्ती (Scope) मर्यादित करा: बॉटला ज्या रिपॉझिटरीची गरज आहे तिथेच मर्यादित ठेवा. जर त्याला फक्त एका विशिष्ट रिपॉझिटरीवर काम करायचे असेल, तर त्याला इतर कोणत्याही 'read rights' देऊ नका.
  • Read आणि Write tokens वेगळे करा: कोड मिळवण्यासाठी एक credential वापरा आणि कमेंट्स पोस्ट करण्यासाठी दुसरे, काटेकोरपणे नियंत्रित केलेले credential वापरा.
  • मानवी मंजुरी (Human approval): सार्वजनिक पोस्टिंगपूर्वी मानवी मंजुरी घ्या. एक हलकी रिव्ह्यू स्टेप—जसे की आवश्यक अप्रूव्हल लेबल—पाइपलाईन न थांबवता एक चेकपॉइंट म्हणून काम करते.
  • ब्लास्ट-रेडियस (Blast-radius) कमी करा: वर्कफ्लो अशा प्रकारे डिझाइन करा की एखादी त्रुटी किंवा गैरवापर झाल्यास त्याचा परिणाम जास्तीत जास्त एका रिपॉझिटरीवर होईल, संपूर्ण संस्थेवर नाही.

प्रतिवाद: ऑपरेशनल ओव्हरहेड

पुढे काय पाहावे

निष्कर्ष (Takeaway): जर एखादे AI ऑटोमेशन प्रायव्हेट कोड पाहू शकत असेल आणि सार्वजनिकरित्या बोलू शकत असेल, तर सिस्टीमचे डिझाइन चुकीचे आहे. परवानग्या कडक करा, मानवी तपासणी (human checks) समाविष्ट करा आणि ब्लास्ट रेडियस लहान ठेवा—अन्यथा एक सिंगल पब्लिक issue डेटा-लीक वेक्टर बनू शकते.