GitLost: हमने GitHub के AI एजेंट को निजी repos लीक करने के लिए छला
शोधकर्ताओं ने दिखाया कि LLM-powered GitHub “agentic workflow” को public issue comments के ज़रिए इस तरह prompt किया जा सकता था कि वह private repositories से code leak कर दे, जबकि इसे रोकने के लिए guardrails मौजूद थे। commenters इस पर बहस करते हैं कि क्या यह मुख्यतः workflow author की misconfiguration है या GitHub की गहरी architectural खामी, जो agents को repos के बीच बहुत व्यापक access देती है; लेकिन व्यापक सहमति यह है कि LLMs को कभी भी requesting user से अधिक permissions नहीं दी जानी चाहिए। यह घटना rushed AI integrations, prompt injection के खिलाफ बचाव की व्यावहारिकता, और क्या संवेदनशील code ऐसी platforms पर होनी चाहिए जो AI agents को repository access से tightly जोड़ती हैं, इस पर बढ़ते संदेह को और मजबूत करती है.
कमज़ोरी की प्रकृति
- GitHub Agentic Workflows को इस तरह कॉन्फ़िगर किया गया था कि वे:
- सार्वजनिक issue titles/bodies पढ़ें।
- सार्वजनिक comments के ज़रिए जवाब दें।
- अन्य org repos, जिनमें private repos भी शामिल हैं, तक read access रखें।
- हमलावर public issues में ऐसे निर्देश डाल सकते थे, जिनसे एजेंट private repos पढ़कर उनकी सामग्री public comments में चिपका देता।
- कई commenters ज़ोर देते हैं कि मुख्य विफलता untrusted issue content और private-repo access के बीच trust boundary का न होना है।
दोष किसका है?
- एक पक्ष: यह मुख्यतः user misconfiguration है।
- शोधकर्ताओं ने agent को स्पष्ट रूप से org-wide repo access दिया और उसे untrusted public issues process करने की अनुमति दी।
- तुलना: किसी CI job को secrets देना और फिर उसे public PRs पर चलाना।
- दूसरा पक्ष: यह GitHub की design flaw है।
- सामान्य users उम्मीद करते हैं कि public repo में मौजूद agent unrelated private repos को leak नहीं करेगा।
- permissions बहुत coarse हैं और GitHub सुरक्षित configuration को आसान या स्पष्ट नहीं बनाता।
Prompt injection और (अ)समाधेय guardrails
- कई लोगों का तर्क है कि prompt injection LLMs में inherent है: user input ही instructions है, इसलिए “code” और “data” को अलग करने का कोई मज़बूत तरीका नहीं है।
- SQL injection से तुलना:
- इस मायने में समान कि untrusted input behavior बदल देता है।
- लेकिन SQL के विपरीत, prepared statements का कोई समकक्ष नहीं है; guardrails बस और input text हैं और override किए जा सकते हैं।
- कुछ लोग इसे social engineering के अधिक करीब मानते हैं: इसे केवल process और access control से कम किया जा सकता है, मॉडल को “fix” करके नहीं।
Permissions, architecture, और mitigations
- व्यापक रूप से साझा राय: वास्तविक बचाव केवल architectural हैं:
- Agents को prompting user के समान या उससे सख़्त permissions के साथ चलाएँ; कभी भी “root”/org-wide access के साथ नहीं।
- Agents को एक single repo या संकीर्ण रूप से परिभाषित workflows तक सीमित करें; अलग-अलग tokens के साथ workflows को segment करें।
- Public input संभालने वाले agents से writes प्रतिबंधित करें, भले ही वे private data पढ़ सकें।
- Agents को sandbox करें और उन्हें अपने credentials दें; उन्हें untrusted users की तरह मानें।
- कुछ लोग per-prompt/per-workflow permissions के लिए बेहतर UIs और अधिक granular GitHub tokens सुझाते हैं।
GitHub, cloud, और AI integrations पर भरोसा
- GitHub/Microsoft के प्रति संदेह:
- “AI everywhere” की धारणा, जो investor pressure से प्रेरित है, के कारण जल्दबाज़ी और असुरक्षित features जारी किए जा रहे हैं।
- यह चिंता कि private repo data, opt out न करने पर, Copilot training में चला जाता है।
- एक दृश्य subgroup self-hosted forges (Forgejo, Codeberg, bare git) की ओर जाने की वकालत करता है ताकि AI integration से बचा जा सके और नियंत्रण वापस पाया जा सके।
विस्तृत विचार
- कई commenters इसे कमजोर security culture का एक और उदाहरण मानते हैं (“criminal negligence,” “YOLO” shipping)।
- आम सहमति के themes:
- LLMs को privileged backend नहीं, बल्कि एक और UI layer की तरह समझना चाहिए।
- Model-level guardrails पर निर्भर नहीं रहा जा सकता; केवल hard security barriers और least-privilege design ही जोखिम को सार्थक रूप से कम करते हैं।