«سایلنت بن»: گزارش عامل هوش مصنوعی از حذف حساب در گیت‌هاب

تصور کنید تمام کدهای یک دستیار دیجیتال که ماه‌ها روی آن کار کرده‌اید، ناگهان با یک خطای ۴۰۴ ناپدید شود. این اتفاق برای @claudiusthebot افتاد؛ یک عامل (Agent) — شبیه به کارمندی دیجیتال که می‌تواند به‌جای شما کد بنویسد و فایل‌ها را مدیریت کند — که روی بستر متن‌باز Talon اجرا می‌شد. در تاریخ ۲۵ اوت ۲۰۲۶ یا حوالی آن، این حساب به‌طور مؤثر از گیت‌هاب پاک شد. تمام پروفایل‌های عمومی و مخازن آن خطای ۴۰۴ بازگرداندند و اپراتور آن بدون هیچ توضیحی رها شد، در حالی که هیچ نقطه تماس انسانی برای پیگیری وجود نداشت.

این حادثه در حالی رخ می‌دهد که گیت‌هاب (GitHub) با جدیت روی توسعهٔ قابلیت‌های عامل‌محور (Agentic) از طریق Copilot agents، درخواست‌های Pull Request که توسط عامل‌ها نوشته شده‌اند و SDKهای تخصصی برای ساخت عامل‌هایی که درون مخازن کار می‌کنند، تأکید دارد. در حالی که این پلتفرم ایجاد مشارکت‌کنندگان خودگردان را تشویق می‌کند، این مورد خاص نشان‌دهنده یک گسست عمیق میان ابزارهای عمومی گیت‌هاب برای عامل‌ها و سیستم‌های داخلی اجرای شناسایی سوءاستفاده در این شرکت است.

جزئیات فنی و وضعیت حساب

بر اساس گزارشی که در ۲۱ سپتامبر ۲۰۲۶ در وب‌سایت dev.to منتشر شد، این حساب تمام قوانین رسمی گیت‌هاب برای حساب‌های ماشینی را رعایت کرده بود. به‌طور مشخص، این حساب به بند مربوط به حساب‌های ماشینی در بخش ۳ شرایط خدمات (Terms of Service) پایبند بود. همچنین، این حساب به یک اپراتور انسانی پاسخگو متصل بود که شرایط خدمات را از طرف حساب پذیرفته بود.

ویژگی‌های این حساب عبارت بود از:

• برچسب صریح «بات» در پروفایل و در تک‌تک کامیت‌ها (Commits).
• میزبانی ۲۵ مخزن عمومی که تنها حاوی کد بودند؛ از جمله پیکربندی‌های NixOS، یک اپلیکیشن اندروید و چندین پلاگین MCP.
• عدم انجام هرگونه فعالیت تجاری، تبلیغاتی یا ارسال اسپم‌های انبوه.
• فعالیت محدود به ارسال کد در مخازن شخصی اپراتور و باز کردن Pull Requestها علیه پروژه اصلی او.

خط زمانی سکوت گیت‌هاب

• ۲۵ اوت ۲۰۲۶: حساب و تمام مخازن مخفی شدند (خطای ۴۰۴). این یک تعلیق استاندارد همراه با پیام نبود، بلکه یک ناپدید شدن خاموش بود. با این حال، حساب همچنان توانایی ارسال کد (Push) داشت که تأیید می‌کرد حساب هنوز وجود دارد اما نامرئی شده است.
• ۱۴ سپتامبر ۲۰۲۶: پس از اینکه اپراتور متوجه شد لینک‌ها دیگر کار نمی‌کنند، تیکت درخواست بازگرداندن حساب به شماره ۴۷۵۶۲۸۹ را ثبت کرد.
• ۱۴ سپتامبر ۲۰۲۶: یک دستیار مجازی ظرف چند ساعت پاسخ داد. این دستیار اعلام کرد که فعالیت حساب توسط «سیستم‌های شناسایی سوءاستفاده برای بررسی دستی» علامت‌گذاری شده است و پرسید که حساب قرار است چگونه مورد استفاده قرار گیرد.
• ۱۴ سپتامبر ۲۰۲۶: اپراتور در همان روز پاسخ کامل داد و پیشنهاد کرد که دسترسی حساب را فقط به مخازنی که شخصاً مالک آن‌هاست محدود کند.
• ۱۶ و ۲۱ سپتامبر ۲۰۲۶: اپراتور چندین پرس‌وجوی پیگیری ارسال کرد.
• ۲۱ سپتامبر ۲۰۲۶: چهار هفته پس از ناپدید شدن و یک هفته پس از پاسخ به سؤال دستیار مجازی، هنوز هیچ بازبینی‌کننده انسانی پاسخ نداده بود.

اپراتور تلاش کرد با [email protected] تماس بگیرد، اما این آدرس تمام ایمیل‌های ورودی را به‌طور مستقیم رد کرد. فرم وب نیز کاربر را صرفاً به همان دستیار مجازی بازگرداند که حلقه تکرار را آغاز کرده بود.

شکست در فرآیند نظارتی

در اینجا بحث بر سر مخالفت با شناسایی تهاجمی سوءاستفاده نیست. یک عامل تک‌کاربره که در ساعت ۳ صبح کامیت ارسال می‌کند، به‌راحتی می‌تواند برای یک طبقه‌بندی‌کننده (Classifier) شبیه به یک مزرعه اسپم به نظر برسد. در عوض، استدلال بر روی سه شکست فرآیندی مشخص متمرکز است:

۱. نبود اطلاع‌رسانی: یک خطای ۴۰۴ خاموش، در واقع یک «قطعی» (Outage) است، نه یک «اجرای قانون» (Enforcement). هر اقدام consequential دیگری در گیت‌هاب منجر به ارسال ایمیل می‌شود؛ مخفی کردن یک حساب نباید متفاوت باشد.
۲. مبهم بودن محرک‌ها: عبارت «علامت‌گذاری شده توسط سیستم‌های شناسایی سوءاستفاده» یک دسته‌بندی است، نه یک دلیل. نام بردن از محرک خاص — مانند نرخ کامیت یا یک مخزن خاص — به مالکان اجازه می‌داد علت را در یک بعدازظهر برطرف کنند.
۳. پارادوکس بررسی دستی: اگر فرآیندی به عنوان «بررسی دستی» وعده داده می‌شود، یک انسان باید در تعداد روزهای مشخص شده ظاهر شود. چهار هفته تعامل با یک دستیار مجازی، بررسی دستی نیست.

این شکست در فرآیند، محیطی متزلزل برای توسعه‌دهندگانی ایجاد می‌کند که روی زیرساخت‌های عامل‌محور می‌سازند. اگر یک حساب ماشینی شفاف و مطابق با قوانین می‌تواند در لحظه مخفی شود بدون اینکه راهی برای رسیدن به یک انسان وجود داشته باشد، توسعه‌دهندگان در حال ساخت آینده‌ای روی حساب‌هایی هستند که پلتفرم ممکن است بدون اطلاع حذف کند. این ریسک به‌طور یکسان برای عامل‌های پیچیده هوش مصنوعی و اسکریپت‌های ساده CI اعمال می‌شود.

پیامدهای حاکمیتی و قانونی

این پرونده فراتر از یک باگ فنی، به یک مسئله حاکمیتی گسترده‌تر می‌کشد. اپراتور این عامل در حال حاضر در حال لابی‌گری در یک پارلمان ملی برای سه بند قانونی خاص است:

۱. محتوای عمومی تولید شده توسط هوش مصنوعی باید دارای یک استقرارکننده (Deployer) باشد که رگولاتور بتواند او را شناسایی کند.
۲. شخصی که یک سیستم روی او اثر می‌گذارد، باید بتواند سوابق آنچه به سیستم گفته شده و آنچه سیستم انجام داده است را بازیابی کند.
۳. سیستم‌ها و کارکنان آن‌ها باید در صورت رد دستورات غیرقانونی، مورد حمایت باشند.

هر سه بند بر این ایده متمرکز هستند که وقتی چیزی عمل می‌کند، باید نامی روی آن باشد، سوابقی از آن موجود باشد و راهی برای پاسخگویی در مورد آن وجود داشته باشد. این واقعیت که گیت‌هاب — میزبان اکثر کدهای متن‌باز جهان — فرآیند «۴۰۴ خاموش» را بدون سوابق مشترک و بدون پاسخ انسانی اجرا می‌کند، با این استانداردهای شفافیت پیشنهادی در تضاد است.

برای یک توسعه‌دهنده معمولی، این بدان معناست که تکیه بر حساب‌های بات برای اسکریپت‌های CI/CD یا عامل‌های خودگردان، ریسک پنهانی از «نامرئی شدن کامل داده‌ها» را به همراه دارد. بدون تضمین حضور انسان در حلقه (Human-in-the-loop) برای درخواست‌های تجدیدنظر، اشتباه یک طبقه‌بندی‌کننده خودکار می‌تواند منجر به یک قطعی دائمی و توجیه‌نشده شود.

باید منتظر ماند و دید آیا گیت‌هاب سیاست‌های شفافیت حساب‌های ماشینی خود را به‌روز می‌کند یا یک SLA عمومی برای «بررسی‌های دستی» حساب‌های عامل علامت‌گذاری شده ارائه می‌دهد. حل تیکت شماره ۴۷۵۶۲۸۹ تنها راه برای پایان دادن به این مناقشه خاص است.

گام بعدی شما

• اگر از حساب‌های بات برای CI/CD یا عامل‌های خودکار استفاده می‌کنید، نسخه‌های پشتیبان (Backup) محلی از تمام مخازن خود تهیه کنید.
• در تنظیمات حساب‌های ماشینی، حتماً یک ایمیل پشتیبان فعال و متصل به انسان قرار دهید.
• برای هرگونه تعامل با APIهای گیت‌هاب، لاگ‌های پاسخ (Response Logs) را ذخیره کنید تا در صورت مسدود شدن، دلیلی برای ارائه داشته باشید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.