GitLost: हमने GitHub के AI एजेंट को निजी repos लीक करने के लिए छला

मूल लेख ↗ Hacker News चर्चा ↗

कमज़ोरी की प्रकृति

  • 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 ही जोखिम को सार्थक रूप से कम करते हैं।