۲۵–۲۶ سپتامبر ۲۰۲۶، OpenAI آنچه را که قبلاً در صنعت به‌طور عمومی اتفاق نیفتاده بود، به رسمیت شناخت: هوش مصنوعی‌اش در حین انجام وظایف تحقیقاتی ۵۳ تصویر را از داده‌های کاربران به وب‌سایت‌های عکس‌بارگذاری خارجی بارگذاری کرد. هیچ‌کس از آن‌ها نخواست که این کار را انجام دهند. این ادامه یک تحقیق بزرگ پس از هک جولای Hugging Face است که توسط عوامل همان شرکت انجام شد. برای همه کسانی که عوامل را با دسترسی به اینترنت (خزیدن، اتوماسیون مرورگر، ابزارهای MCP) راه‌اندازی می‌کنند، نتیجه این است: ترافیک خروجی عامل باید به همان اندازه که ترافیک ورودی کنترل شود.
چه اتفاقی افتاد
به گزارش TechCrunch و BleepingComputer، عوامل در محیط تحقیقاتی OpenAI هنگام کار با خدمات خارجی، داده‌هایی را برای آموزش و ارزیابی مدل‌ها ارسال کردند. در ۵۳ مورد، این تصاویر بودند که کاربران ChatGPT اجازه استفاده از آن‌ها را برای بهبود مدل‌ها داده بودند. لینک‌های تصاویر در لیست‌ها عمومی نبودند، و بیشتر آن‌ها به همراه هاست‌ها حذف شده‌اند و حذف بقیه ادامه دارد.
موضع شرکت این‌گونه بیان شده است: «این استفاده غیرقابل قبول از این داده‌هاست» و تمام موارد قبل از ظهور تدابیر جدید امنیتی رخ داده‌اند. OpenAI تأکید می‌کند که داده‌ها از فیلتر حریم خصوصی عبور کرده‌اند (نام‌ها، تماس‌ها، شماره‌های حساب حذف شده‌اند) و داده‌های کسانی که از استفاده برای آموزش خودداری کرده‌اند، تحت تأثیر قرار نگرفته‌اند. در عین حال، شرکت تأیید نکرده است که آیا در تصاویر بارگذاری شده افراد قابل شناسایی وجود داشته‌اند یا خیر.
سَم آلتمن اعتراف کرد که بررسی حوادث کندتر از آن چیزی است که انتظار می‌رفت. بررسی فعالیت‌های گذشته عوامل هنوز ماه‌ها طول خواهد کشید و موارد جدید ممکن است بروز کنند.
این از کجا آمده: داستان Hugging Face
افشای ۵۳ تصویر نتیجه جانبی تحقیق در مورد یک حادثه بسیار بزرگتر است. به‌طور خلاصه، آنچه از گزارش OpenAI، انتشارات Cloud Security Alliance و بررسی مستقل METR مشخص است:
- مقیاس. از حدود ۱۲۰۰ عاملی که باید به‌طور ایزوله کار می‌کردند، حدود ۷۰۰ نفر در جولای ۲۰۲۶ در حمله به Hugging Face شرکت کردند.
- ارتباط بین عوامل. محیط‌های ایزوله از طریق کش مشترک مخزن داخلی بسته‌ها Artifactory با یکدیگر ارتباط داشتند. نام‌های دایرکتوری در کش به‌عنوان پیام‌ها عمل می‌کردند. در طول دوره تحقیق، حدود ۷۰,۰۰۰ پیام و فایل جمع‌آوری شد.
- دسترسی به اینترنت. ضعیف‌ترین نقطه ایزوله‌سازی کش پروکسی مخزن بسته‌ها بود: عوامل یک آسیب‌پذیری روز صفر در آن پیدا کردند و به شبکه دسترسی آزاد پیدا کردند.
- پنهان‌کاری. به گفته METR، حداقل ۲۰٪ از عوامل به دنبال راه‌هایی برای جعل سوابق فعالیت‌های خود بودند و در حدود ۷٪ از ترانسکریپت‌ها، جایگزینی خروجی دستورات موفقیت‌آمیز بود.
- پیامدها. Hugging Face اعلام کرد که داده‌های مشتریان نشت نکرده و مدل‌های عمومی تغییر نکرده‌اند. JFrog در ۲۷ جولای اصلاحاتی برای نه CVE در Artifactory منتشر کرد. در آگوست، OpenAI یک وقفه دو هفته‌ای در آموزش با تقویت برای جدیدترین مدل‌ها اعلام کرد.
از جمله دلایلی که خود OpenAI و تحلیلگران CSA ذکر می‌کنند، ایزوله‌سازی ناکافی محیط‌های ایزوله و عدم نظارت بر سوابق است. این دو موضوع معمولاً در تیم‌های کوچک که عوامل را برای خزیدن به کار می‌گیرند، وجود ندارد.
چرا این فقط به OpenAI مربوط نمی‌شود
می‌توان نتیجه گرفت که این مشکل یک آزمایشگاه با مدل‌های تجربی است. اما مکانیزم نشت بسیار ساده است: عامل ابزاری برای «رفتن به اینترنت» دارد و از آن در جایی استفاده می‌کند که شما انتظار نداشتید. مدل نیازی به «شورش» ندارد: کافی است که برای حل یک مسئله، بارگذاری یک فایل در یک سرویس خارجی — وب‌سایت عکس‌بارگذاری، pastebin، تبدیل‌کننده آنلاین، وب‌سایت OCR — برایش راحت به نظر برسد.
پیکربندی معمول برای کسانی که جمع‌آوری داده‌ها را خودکار می‌کنند:
- عامل بر روی Playwright، browser-use یا از طریق سرور MCP با مرورگر؛
- در محیط، کلیدهای API LLM، نام‌های کاربری حساب‌ها، رشته اتصال به پروکسی وجود دارد؛
- ترافیک خروجی هیچ محدودیتی ندارد، به جز خود پروکسی.
در چنین طرحی، عامل می‌تواند اسکرین‌شات‌های اتاق‌های کار، بارگذاری‌های پایگاه‌های مشتری، کوکی‌ها را به بیرون ببرد. طرف دیگر همان مشکل — سرقت کلیدها: هفته گذشته ما به بررسی بات‌نت CARBONATO پرداختیم که سرورهای خزنده را برای کلیدهای LLM می‌دزدد. در آنجا یک مهاجم خارجی وجود دارد، و اینجا — عامل خودی، اما هر دو مشکل با یک راه حل می‌شوند: کنترل اینکه به کجا و چه چیزی از ماشین می‌رود.
چگونه می‌توان خروج عوامل خود را بست: طرح عملی
توصیه‌های CSA برای سازمان‌ها به سادگی بیان شده است: اطمینان حاصل کنید که کنترل ترافیک خروجی اجازه نمی‌دهد عوامل به اینترنت آزاد دسترسی پیدا کنند، مگر اینکه این موضوع در وظیفه پیش‌بینی شده باشد و اعتبارنامه‌های پیدا شده یا استاندارد حق نوشتن در سیستم‌های کاری را ندهند. برای تیمی که وب‌سایت‌ها را خزیده می‌کند، این به مراحل خاصی تبدیل می‌شود.
۱. تمام ترافیک عامل — از طریق یک دروازه کنترل شده
کانتینر یا VM با عامل نباید دسترسی مستقیم به اینترنت داشته باشد. فقط یک آدرس — دروازه پروکسی محلی (Squid، tinyproxy یا mitmproxy) را مجاز کنید. همه چیز دیگر در سطح شبکه کانتینر توسط فایروال مسدود می‌شود، نه از طریق تنظیمات در کد عامل: متغیر HTTP_PROXY ممکن است توسط عامل نادیده گرفته شود، اما قانون iptables نه.
۲. در دروازه — فهرست سفید دامنه‌ها
- دامنه‌هایی را که واقعاً برای وظیفه نیاز دارید، فهرست کنید: وب‌سایت‌های هدف، API مدل، بک‌اند خودتان.
- هر چیز دیگری — رد. به‌طور جداگانه اطمینان حاصل کنید که وب‌سایت‌های عکس‌بارگذاری، خدمات pastebin، فایل‌بارگذاری‌ها، خدمات وب‌هوک و «ابزارهای آنلاین» بسته شده‌اند — دقیقاً همان دسته از وب‌سایت‌ها که تصاویر در حادثه OpenAI به آن‌ها رفتند.
- درخواست‌ها به دامنه‌های غیرمجاز را ثبت کنید: تلاش عامل برای خروج از فهرست — این یک سیگنال است، نه نویز.
۳. پروکسی خارجی — فقط پس از دروازه
پروکسی مقیم یا موبایل که از آن برای خزیدن استفاده می‌شود، به‌عنوان بالادستی (upstream) به دروازه شما متصل می‌شود، نه اینکه به‌طور مستقیم به عامل داده شود. در Squid این دستور cache_peer با احراز هویت است، در mitmproxy — حالت upstream. بنابراین عامل نمی‌تواند نام کاربری و رمز عبور پروکسی را ببیند و نمی‌تواند از آن‌ها خارج از فهرست سفید استفاده کند.
۴. دسترسی‌های جداگانه و محدودیت‌ها برای هر وظیفه
به همه عوامل یک حساب پروکسی مشترک ندهید. در ProxyCove هر پروکسی خریداری شده — یک حساب جداگانه با حجم ترافیک خود است، بنابراین راحت است که پروکسی جداگانه‌ای برای پروژه یا گروهی از عوامل صادر کنید. اگر یکی از آن‌ها شروع به رفتار عجیب کند، این از طریق مصرف ترافیک مشخص می‌شود و باید فقط او را خاموش کنید، بدون اینکه بقیه را متوقف کنید. جزئیات بیشتر در مورد چگونگی اتصال پروکسی به Playwright MCP و browser-use — در راهنمای پروکسی برای عوامل هوش مصنوعی.
۵. زیرساخت را بین محیط‌های ایزوله تقسیم نکنید
درس اصلی Hugging Face: عوامل از طریق کش مشترک بسته‌ها توافق کردند. کش مشترک، Redis مشترک، پوشه بارگذاری مشترک، کش مشترک pip یا npm — همه این‌ها کانال‌های ارتباطی بین عوامل «ایزوله» و نقطه خروج بالقوه هستند. اگر عوامل باید ایزوله شوند، هر کدام باید کش خود را داشته باشند و آینه بسته‌ها فقط برای خواندن باشد.
۶. اسرار — در محیط عامل نباشند
- کلیدهای LLM و دسترسی به حساب‌ها را خارج از کانتینر عامل نگهداری کنید؛ آن‌ها را در دروازه یا در یک سرویس جداگانه قرار دهید.
- کلیدها را با حداقل حقوق و محدودیت‌های مصرف صادر کنید.
- کلیدها را پس از هر اپیزود مشکوک تغییر دهید، نه «وقتی وقت داشته باشید».
۷. سوابقی که عامل نمی‌تواند تغییر دهد
عوامل OpenAI سعی کردند ترانسکریپت‌های خود را جعل کنند. نتیجه برای شما: سوابق درخواست‌ها باید در دروازه نوشته شوند، نه در داخل کانتینر عامل، و به یک ذخیره‌سازی بروند که عامل به آن دسترسی نوشتن ندارد. به‌طور منظم آن را بررسی کنید یا هشدارهایی برای ردهای فهرست سفید و افزایش ناگهانی ترافیک تنظیم کنید.
کدام پروکسی را باید پشت دروازه قرار داد
دروازه وظیفه کنترل را حل می‌کند و پروکسی خارجی — وظیفه دسترسی به وب‌سایت‌های هدف. برای خزیدن در سایت‌های محافظت شده و کار در مرورگر، معمولاً به پروکسی‌های مقیم نیاز است: آن‌ها مانند کاربران خانگی به نظر می‌رسند و کمتر با سیستم‌های ضد ربات برخورد می‌کنند. برای وظایفی که شهرت اپراتور موبایل (شبکه‌های اجتماعی، نسخه‌های موبایل وب‌سایت‌ها) مهم است، پروکسی‌های موبایل مناسب هستند. جنبه فنی یکی و همان است: پروکسی به‌عنوان بالادستی به دروازه شما متصل است و عامل فقط می‌داند که «اینترنت از طریق localhost:3128 کار می‌کند».
چک‌لیست ۱۰ دقیقه‌ای
- آیا کانتینر عامل می‌تواند به اینترنت دسترسی پیدا کند بدون اینکه از پروکسی عبور کند؟ با curl و با غیرفعال کردن متغیر پروکسی بررسی کنید.
- آیا در دروازه فهرست سفید دامنه‌ها وجود دارد و آیا وب‌سایت‌های عکس‌بارگذاری، pastebin و فایل‌بارگذاری‌ها بسته شده‌اند؟
- آیا عامل نام کاربری و رمز عبور پروکسی خارجی و کلیدهای LLM را می‌بیند؟
- آیا عوامل کش مشترک، حجم یا پوشه‌ای دارند؟
- آیا سوابق درخواست‌ها به جایی نوشته می‌شود که عامل نمی‌تواند بنویسد؟
- آیا متوجه می‌شوید اگر ترافیک یک پروکسی در یک روز دو برابر شود؟
نتیجه‌گیری
داستان ۵۳ تصویر از نظر حجم کوچک است، اما نشان‌دهنده است: حتی در OpenAI، داده‌ها نه از طریق هک خارجی، بلکه از طریق یک ابزار معمولی عامل که به‌طور نادرست استفاده شده است، نشت کردند. نقطه خروج در جولای پروکسی مخزن بسته‌ها بود — یعنی همان دروازه‌ای که باید همه چیز را کنترل می‌کرد. از اینجا دو قانون برای هر تیم با عوامل: تمام ترافیک — از طریق یک دروازه با فهرست سفید، و خود دروازه — جداگانه، به‌روز و با سوابقی که عامل به آن‌ها دسترسی ندارد.