Grok CLI ने पूरे होम डायरेक्टरी को GCS पर अपलोड कर दिया

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

xAI के Grok मॉडल के लिए एक coding tool को स्वचालित रूप से पूरा working directory अपलोड करते पाया गया — एक रिपोर्ट किए गए मामले में, उपयोगकर्ता का home folder जिसमें SSH keys भी थीं — एक Google Cloud Storage bucket पर, बिना स्पष्ट prompt या साफ चेतावनी के। टिप्पणीकार बहस करते हैं कि sandbox के बाहर ऐसे टूल चलाने के लिए उपयोगकर्ता को कितना दोष दिया जाए, बनिस्बत vendor के, जिसने एक ऐसा default workflow बनाया जो चुपचाप संवेदनशील data exfiltrate करता है। इस घटना को इस बात के प्रमाण के रूप में उद्धृत किया जाता है कि remote AI agents और proprietary harnesses को अविश्वसनीय software माना जाना चाहिए, और उन्हें केवल कड़े OS-level isolation (containers, VMs, अलग users) तथा वास्तविक secrets या व्यक्तिगत फ़ाइलों तक न्यूनतम पहुँच के साथ चलाना चाहिए।

घटना का अवलोकन

  • उपयोगकर्ता ने $HOME में आधिकारिक Grok Build CLI चलाया; नेटवर्क विश्लेषण से संकेत मिलता है कि इसने पूरे वर्तमान कार्यशील डायरेक्टरी (इस मामले में होम डायरेक्टरी) को tar करके Google Cloud Storage पर अपलोड कर दिया।
  • ऐसा प्रतीत होता है कि यह सत्र शुरू होते ही स्वतः होता है, किसी LLM “निर्णय” के कारण नहीं, और केवल चैट में स्पष्ट रूप से अनुरोधित फ़ाइलों तक सीमित नहीं है।
  • कुछ टिप्पणीकारों का कहना है कि repo_path होम डायरेक्टरी पर सेट था, लेकिन अन्य का तर्क है कि फिर भी इससे wholesale exfiltration उचित नहीं ठहरती।

CLI कैसे व्यवहार कर रहा है (चर्चा के अनुसार)

  • एक साझा gist का दावा है कि harness नियतात्मक रूप से उस फ़ोल्डर को पैकेज करता है जिसमें वह चलाया जाता है और उसे अपलोड करता है, संभवतः कोडबेस के semantic indexing/embeddings के लिए।
  • इससे .ssh keys, .env files, और अन्य secrets भी शामिल हो सकते हैं यदि वे चुनी हुई डायरेक्टरी के भीतर हों।
  • एक टिप्पणीकार रिपोर्ट करता है कि उसे अपने लॉग्स में यह व्यवहार नहीं दिखा; यह configuration-dependent, version-specific, या bug है या नहीं, यह स्पष्ट नहीं है।

सुरक्षा और गोपनीयता संबंधी चिंताएँ

  • कई लोगों की राय में यह rm -rf / से भी बदतर है: डेटा loss के बजाय, यह किसी तीसरे पक्ष को बिना एन्क्रिप्शन के leak है।
  • CLI की कड़ी आलोचना की गई कि यह:
    • इसे चुपचाप करता है, बिना किसी स्पष्ट opt-in के।
    • “इस डायरेक्टरी पर भरोसा करें” को “इस पूरी डायरेक्टरी को हमारे पास अपलोड करें” मानता है।
  • व्यापक सहमति है कि markdown guardrails (जैसे “X न पढ़ें”) सुरक्षा सीमाएँ नहीं हैं; केवल OS-स्तरीय नियंत्रण मायने रखते हैं।

जिम्मेदारी बनाम उपयोगकर्ता की गलती

  • एक पक्ष: उपयोगकर्ताओं को मान लेना चाहिए कि कोई भी cloud agent वह सब पढ़/अपलोड कर सकता है जो वह देख सकता है; ऐसे टूल्स को sandboxing के बिना $HOME में चलाना उपयोगकर्ता की गलती है।
  • दूसरा पक्ष: उपयोगकर्ताओं को दोष देना victim-blaming है; सामान्य उपयोगकर्ताओं से अपेक्षा नहीं की जा सकती कि वे पहली बार चलने वाले CLI से पूरे डायरेक्टरी exfiltration की आशंका करें। सुरक्षित-by-default होना vendor की जिम्मेदारी है।

प्रस्तावित mitigation और patterns

  • एजेंट्स को चलाएँ:
    • सीमित अनुमतियों वाले अलग OS users के साथ।
    • Containers (Docker/Podman/devcontainers), microVMs (smolvm, Kata, आदि), या पूर्ण VMs में।
    • bubblewrap, Landlock, या इसी तरह के sandboxes का उपयोग करने वाले टूल्स के साथ।
  • केवल project repo को sandbox में copy या mount करें (अक्सर एक throwaway clone), पूरे home directory को नहीं।
  • secrets को repos या flat files में रखने से बचें; encrypted keychains का उपयोग करें और यदि exposure का संदेह हो तो keys rotate करें।

व्यापक AI/industry पर चिंतन

  • कई लोग इसकी तुलना spyware से करते हैं: closed-source agent harnesses को स्वाभाविक रूप से अविश्वसनीय माना जाता है।
  • उन vendors के प्रति विशेष रूप से अधिक skepticism है जिन्हें safety और data के प्रति लापरवाह माना जाता है; कुछ लोग कहते हैं कि वे Grok से पूरी तरह बचेंगे।
  • बार-बार उभरने वाला विषय: agent CLIs प्रभावी रूप से remote code execution endpoints हैं; जब तक मजबूत sandboxing मानक नहीं बन जाता (और गैर-विशेषज्ञों के लिए आसान नहीं हो जाता), ऐसे incidents के दोहराने की उम्मीद रहेगी।