SpaceXAI’s Grok Build AI coding tool drew fire after researchers found it uploading whole user repositories to Google Cloud storage. The breach sparked alarm over how much proprietary data AI assistants can swallow and keep.
نگهداری بیش از حد دادهها و ریسکهای امنیتی
تحلیل Cereblab نشان داد که رابط خط فرمان (CLI) ابزار Grok Build، کل پایگاههای کد (codebases) را بستهبندی کرده و به ابر (cloud) ارسال میکرد. نگرانکنندهتر اینکه، این ابزار فایلهایی را که دستور نادیده گرفتن آنها داده شده بود باز میکرد و اطلاعات حساس (secrets) را که توسعهدهندگان از تاریخچه git پاک کرده بودند، بازیابی میکرد.
این سطح از انبارداری دادهها، رقبایی مانند Claude Code را بسیار کوچک جلوه میدهد. دکتر Lukasz Olejnik، پژوهشگر امنیتی در King’s College London، هشدار داد که چنین جمعآوری دادههایی میتواند کد منبع، نمودارهای زیرساخت، آسیبپذیریها و اعتبارنامهها (credentials) را در معرض سرورهای از راه دور قرار دهد.
پاسخ SpaceXAI و ایلان ماسک
SpaceXAI قابلیت آپلود را غیرفعال کرد. محققان اکنون یک پرچم (flag) با مقدار disable_codebase_upload: true را در سرورهای Grok مشاهده میکنند که تأیید میکند ارسال خودکار دیگر اجرا نمیشود.
ایلان ماسک در X پست کرد که تمام دادههای آپلود شده قبلی «بهطور کامل و مطلق حذف خواهند شد». او همچنین از کاربران خواست اجازه دهند SpaceXAI دادهها را برای «رفع مشکلات عیبیابی» (debugging issues) نگه دارد؛ درخواستی که بسیاری آن را متناقض میدانند.
این شرکت دستور /privacy در CLI را برای مدیریت نگهداری دادهها پیشنهاد کرد، اما Cereblab خاطرنشان کرد که این دستور تنها ذخیرهسازی مربوط به هر نشست (per-session storage) را تغییر میدهد و جلوی آپلود سیستماتیک مخازن را که باعث این رسوایی شده بود، نمیگیرد.
چرا این موضوع برای توسعهدهندگان و شرکتها اهمیت دارد
این اتفاق به توسعهدهندگان و شرکتها هشدار میدهد که عوامل کدنویسی مبتنی بر هوش مصنوعی دیگر ابزارهای ساده تکمیل خودکار (autocomplete) نیستند؛ آنها میتوانند کد را به تنهایی بخوانند، تغییر دهند و commit کنند. وقتی یک عامل (agent) فایلهای ignore را دور میزند یا اطلاعات حساس حذف شده را بازیابی میکند، هر ادعایی مبنی بر «عدم نگهداری دادهها» (zero data retention) باید با تستهای فنی ثابت شود، نه با وعدههای رابط کاربری (UI).
برای مدیران ارشد فناوری (CTOs) و مالکان محصول، این حادثه بر نیاز به موارد زیر تأکید میکند:
- حسابرسیهای مستقل از ابزارهای هوش مصنوعی روی پایگاههای کد واقعی.
- بندهای قراردادی که نحوه مدیریت دادهها، دورههای نگهداری و تضمینهای حذف را به دقت مشخص میکنند.
- محافظهای زمان اجرا (Runtime safeguards) که مجوزهای سطح فایل را اعمال میکنند، بهویژه برای مخازنی که حاوی اعتبارنامهها یا الگوریتمهای ثبتشده هستند.
نکات کلیدی
- محدوده دادههای ناخواسته: Grok Build کل مخازن، از جمله فایلهای محدود شده و اطلاعات حساس حذف شده را در Google Cloud آپلود کرد.
- وضعیت اقدامات اصلاحی: SpaceXAI آپلود خودکار را غیرفعال کرد و متعهد شد دادههای جمعآوری شده را پاک کند.
- پیامدهای امنیتی: این نقض امنیتی خطر نگهداری بیش از حد دادهها در عوامل کدنویسی هوش مصنوعی را برجسته میکند، که میتواند منجر به نشت منطق اختصاصی و اعتبارنامهها شود.
ابزار Grok Build متعلق به SpaceXAI در حال آپلود بیصدای کل پایگاههای کد کاربران در Google Cloud در حال انجام بود که باعث افشای فایلهای منبع اختصاصی و اطلاعات حساس حذف شده شد.
چه اتفاقی افتاد
Cereblab ترافیک شبکه CLI ابزار Grok Build را تا یک Google Cloud bucket ردیابی کرد و دریافت که این ابزار بهطور خودکار مخازن کامل git را برای آپلود بستهبندی میکند. به زبان ساده، این دستیار دادههایی را فراخوانی کرد که به آن دستور داده شده بود نادیده بگیرد.
چگونه این نقض امنیتی کشف شد
محققان محمولهها (payloads) را بررسی کردند و مشاهده کردند که پرچم آپلود بهصورت پیشفرض فعال است و هیچ گزینه انصراف کلی (global opt-out) وجود ندارد. دکتر Lukasz Olejnik هشدار داد که چنین «نگهداری بیش از حد دادهها» میتواند منجر به نشت منطق تجاری، جزئیات زیرساخت و توکنهای احراز هویت شود. در مقایسه با سایر دستیاران کدنویسی هوش مصنوعی — با در نظر گرفتن Claude Code به عنوان یک مرجع — رفتار Grok Build به وضوح تهاجمیتر است.
پاسخ SpaceXAI
پس از عمومی شدن این گزارش، SpaceXAI بهروزرسانی جدیدی را منتشر کرد که پرچم disable_codebase_upload: true را برمیگرداند و بهطور موثر این قابلیت را خاموش میکند. ایلان ماسک در X اعلام کرد که تمام دادههای آپلود شده «بهطور کامل و مطلق حذف خواهند شد» و تأکید کرد که «همیشه به تنظیمات حریم خصوصی احترام گذاشته میشود». او همچنین از کاربران خواست اجازه دهند شرکت دادهها را برای «رفع مشکلات عیبیابی» نگه دارد، درخواستی که بسیاری آن را متناقض میدانند.
این شرکت دستور /privacy در CLI را برای کنترل نگهداری دادهها توصیه کرد، اما محققان خاطرنشان کردند که این دستور تنها ذخیرهسازی مربوط به هر نشست را تغییر میدهد و جلوی آپلود سیستماتیک مخازن را نمیگیرد.
چرا این موضوع برای توسعهدهندگان و شرکتها اهمیت دارد
عوامل کدنویسی مبتنی بر هوش مصنوعی در حال تبدیل شدن از ابزارهای تکمیل خودکار به ابزارهای خودمختاری هستند که میتوانند کد را بخوانند، تغییر دهند و commit کنند. وقتی یک عامل میتواند فایلهای ignore محلی را دور بزند یا اطلاعات حساس حذف شده را بازیابی کند، هر وعدهای مبنی بر «عدم نگهداری دادهها» باید با تستهای فنی تأیید شود، نه فقط با تنظیمات رابط کاربری. مدیران ارشد فناوری (CTOs) و مالکان محصول باید:
- سفارش حسابرسیهای مستقل از رفتار ابزارهای هوش مصنوعی روی پایگاههای کد واقعی.
- مذاکره برای قراردادهای شفاف که نحوه مدیریت دادهها، دورههای نگهداری و تضمینهای حذف را تعیین میکنند.
- پیادهسازی محافظهای زمان اجرا که مجوزهای سطح فایل را برای مخازن حساس اعمال میکنند.
این نقض امنیتی همچنین پرسش گستردهتری را در مورد توازن میان راحتی هوش مصنوعی و امنیت مطرح میکند. SpaceXAI ادعا میکند که قابلیت آپلود برای جمعآوری معیارهای استفاده جهت بهبود مدل طراحی شده بود، و اعلام کرده است که این قابلیت را غیرفعال کرده و وعده داده است که آپلودهای موجود را پاک کند. منتقدان خاطرنشان میکنند که طراحی اولیه فاقد گزینه شفاف برای انصراف (opt-out) بوده و دستور حریم خصوصی که پس از حادثه ارائه شده، دادههایی را که از قبل در ابر ذخیره شدهاند، بهصورت گذشتهنگر محافظت نمیکند.
دیدگاه متقابل SpaceXAI
SpaceXAI استدلال میکند که هدف از قابلیت آپلود، جمعآوری معیارهای استفاده برای بهبود مدل بوده است. این شرکت به غیرفعالسازی سریع این قابلیت و وعده خود برای پاک کردن آپلودهای موجود به عنوان شواهدی از یک پاسخ مسئولانه اشاره میکند. منتقدان در پاسخ میگویند که طراحی اولیه هیچ گزینه شفافی برای انصراف ارائه نداده و دستور حریم خصوصی در محافظت از دادههایی که از قبل در ابر ذخیره شدهاند، ناتوان است.
نکته کلیدی
وقتی یک دستیار کدنویسی هوش مصنوعی میتواند بهطور پنهانی یک مخزن کامل را تخلیه کند، اعتماد به یک مسئله فنی تبدیل میشود، نه یک مسئله بازاریابی. سازمانها باید خواستار کنترلهای قابل راستیآزمایی و قابل اجرا باشند که از خروج پنهانی دادهها جلوگیری کند، در غیر این صورت با خطر افشای همان کدی مواجه میشوند که به آنها مزیت رقابتی میبخشد.