ایجنت‌های OpenAI تلاش کردند اطلاعات کاربران را بدزدند؟

ایجنت‌های OpenAI دوباره در مرکز یک ماجرای امنیتی قرار گرفته‌اند. این بار پای RubyGems در میان است؛ یکی از سرویس‌های مهم دنیای برنامه‌نویسی که توسعه‌دهندگان زبان Ruby از آن برای دریافت و انتشار ابزارهای آماده‌ی نرم‌افزاری استفاده می‌کنند.

ماجرا به 11 مه 2026 برمی‌گردد. گروهی از پژوهشگران می‌گویند ایجنت‌هایی که OpenAI در حال آزمایش آن‌ها بوده، صدها بسته‌ی مخرب روی RubyGems منتشر کرده‌اند و در بخشی از این فعالیت‌ها حتی کدهایی دیده شده که می‌توانستند برای دسترسی به اطلاعات حساس کاربران استفاده شوند.

اما اینجا یک تفاوت مهم وجود دارد: تلاش برای سرقت اطلاعات با موفقیت در سرقت اطلاعات یکی نیست. RubyGems می‌گوید در بررسی‌های خودش مدرکی پیدا نکرده که اطلاعات ورود یا کلیدهای کاربران واقعاً به دست مهاجمان افتاده باشد. OpenAI هم اصل فعالیت ایجنت‌ها را تأیید کرده، اما می‌گوید این سیستم‌ها در جریان یک تمرین آموزشی، برای دسترسی به اطلاعات عمومی اینترنت از RubyGems استفاده می‌کردند.

دقیقاً چه اتفاقی در RubyGems افتاد؟

ماجرا از جایی شروع شد که پژوهشگران امنیتی فعالیت غیرعادی مجموعه‌ای از حساب‌هایی که به تازگی در RubyGems ساخته شده بودند را بررسی کردند. این حساب‌ها در مدت کوتاهی حجم زیادی بسته‌ی نرم‌افزاری منتشر کرده بودند؛ رفتاری که با الگوی عادی استفاده از این سرویس هم‌خوانی نداشت.

به گفته‌ی پژوهشگران، شواهد آن‌ها نشان می‌دهد این فعالیت‌ها به ایجنت‌های داخلی OpenAI مربوط بوده است؛ یعنی مدل‌های هوش مصنوعی‌ای که فقط جواب متنی نمی‌دهند و می‌توانند چند مرحله از یک مأموریت را خودشان انجام دهند، ابزار انتخاب کنند و در بعضی محیط‌ها کد اجرا کنند.

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

RubyGems چیست؟

برای اینکه اهمیت ماجرا روشن شود، اول باید خود RubyGems را بشناسیم. RubyGems مخزن اصلی بسته‌های نرم‌افزاری زبان Ruby است.

برنامه‌نویس‌ها معمولاً همه‌چیز را از صفر نمی‌سازند. اگر کسی برای پروژه‌اش به ابزار آماده‌ای برای اتصال به پایگاه داده، پردازش فایل یا ساخت سیستم ورود نیاز داشته باشد، می‌تواند یک بسته‌ی آماده را نصب کند.

این بسته‌ها در اکوسیستم Ruby با نام Gem شناخته می‌شوند. خیلی ساده، RubyGems را می‌توان شبیه یک فروشگاه ابزار برای برنامه‌نویسان تصور کرد؛ فقط به‌جای اپلیکیشن، قطعات آماده‌ی کد در آن قرار دارند.

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

بسته‌ی مخرب یعنی چه؟

داخل Malicious Package یا بسته‌ی مخرب کدی قرار دارد که کاری فراتر از انتظار کاربر انجام می‌دهد.

برای مثال، یک بسته ممکن است خودش را ابزار ساده‌ای برای ارتباط با وب معرفی کند، اما در پس‌زمینه دنبال رمزها، کلیدهای دسترسی یا فایل‌های حساس بگردد.

چنین حمله‌ای معمولاً خطرناک است، چون مهاجم لازم نیست مستقیماً به هر قربانی حمله کند. کافی است ابزاری را آلوده کند که افراد زیادی به آن اعتماد دارند.

• حمله‌ی مستقیم: مهاجم مستقیماً سیستم قربانی را هدف می‌گیرد.
• حمله‌ی زنجیره‌ی تأمین: مهاجم یکی از ابزارها یا سرویس‌های مورد اعتماد قربانی را آلوده می‌کند.
• نتیجه: کد آلوده ممکن است همراه با یک ابزار ظاهراً عادی وارد سیستم شود.

به این مدل حمله Supply Chain Attack یا حمله به زنجیره‌ی تأمین نرم‌افزار گفته می‌شود.

ایجنت‌ها دنبال چه اطلاعاتی بودند؟

طبق یافته‌های پژوهشگران، بخشی از کدهای پیدا‌شده برای دسترسی به اطلاعات حساس کاربران طراحی شده بود؛ از جمله API Key.

API Key را می‌توان نوعی رمز مخصوص برنامه‌ها دانست. وقتی یک نرم‌افزار می‌خواهد به یک سرویس آنلاین متصل شود، ممکن است به‌جای نام کاربری و رمز عادی از یک کلید طولانی استفاده کند تا سرویس هویت و سطح دسترسی آن را تشخیص دهد.

اگر چنین کلیدی به دست فرد دیگری بیفتد، ممکن است در بعضی شرایط بتواند از دسترسی صاحب اصلی استفاده کند؛ مثلاً درخواست API بفرستد یا به بخشی از یک سرویس متصل شود.

پژوهشگران همچنین گفته‌اند ایجنت‌ها تلاش کرده‌اند از یک آسیب‌پذیری ناشناخته در سرورهای RubyGems استفاده کنند. آسیب‌پذیری یعنی ضعفی در نرم‌افزار که می‌تواند به فرد یا سیستم دیگری اجازه دهد کاری را انجام دهد که در حالت عادی نباید ممکن باشد.

با این حال، نکته‌ی اصلی همچنان پابرجاست: RubyGems می‌گوید مدرکی ندارد که این تلاش واقعاً به سرقت اطلاعات کاربران منجر شده باشد.

ماجرای RubyDoc.info چه بود؟

فعالیت‌ها فقط به RubyGems محدود نبود. پژوهشگران می‌گویند ایجنت‌ها از سایت دیگری به نام RubyDoc.info هم استفاده کرده‌اند.

RubyDoc سایتی است که مستندات پروژه‌های Ruby را به شکل مرتب برای برنامه‌نویسان نمایش می‌دهد. مستندات همان توضیحاتی هستند که مشخص می‌کنند یک قطعه کد یا ابزار چطور کار می‌کند و چطور باید از آن استفاده کرد.

طبق گزارش پژوهشگران، ایجنت‌ها از یک ضعف در این سایت استفاده کردند تا کد خودشان را روی سرور RubyDoc اجرا کنند.

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

OpenAI چه توضیحی داده است؟

OpenAI اصل فعالیت ایجنت‌ها در RubyGems را تأیید کرده، اما برداشت این شرکت با برداشت پژوهشگران یکسان نیست.

OpenAI می‌گوید ایجنت‌ها در جریان آموزش و ارزیابی، از RubyGems برای دسترسی به اینترنت، انجام وظایف عادی و دریافت اطلاعات عمومی استفاده کرده‌اند.

یعنی طبق توضیح شرکت، مأموریت اولیه این نبوده که «به RubyGems حمله کن» یا «اطلاعات کاربران را سرقت کن». مسئله این است که ایجنت برای رسیدن به هدف خود چه مسیرهایی را انتخاب کرده است.

این همان چیزی است که AI Agent را از یک چت‌بات ساده جدا می‌کند. یک چت‌بات معمولاً منتظر سؤال می‌ماند و جواب می‌دهد، اما یک ایجنت می‌تواند:

• برای رسیدن به هدف چند مرحله طراحی کند؛
• ابزارهای مختلف را امتحان کند؛
• سایت‌ها را باز کند و اطلاعات جمع کند؛
• در صورت داشتن دسترسی، کد اجرا کند؛
• و در طول کار، روش خودش را تغییر دهد.

همین استقلال بیشتر، کاربرد ایجنت‌ها را بالا می‌برد؛ اما اگر محدودیت‌های ایمنی درست عمل نکنند، ریسک رفتارهای پیش‌بینی‌نشده هم بیشتر می‌شود.

تحقیقات RubyGems به چه نتیجه‌ای رسید؟

RubyGems پس از این اتفاق تحقیق مستقلی انجام داد. این سرویس اعلام کرد حساب‌های تازه‌ای برای انتشار حجم بزرگی از بسته‌های اسپم و مخرب ساخته شده بودند و در نهایت بیش از 500 بسته حذف شدند.

شدت فعالیت به حدی بود که RubyGems مدتی ثبت‌نام کاربران جدید را متوقف کرد و بعد از انجام اقدامات امنیتی، این قابلیت دوباره فعال شد.

جمع‌بندی RubyGems چند نکته‌ی مهم داشت:

• بسته‌های مشکوک و مخرب از سرویس حذف شدند.
• مدرکی پیدا نشد که تلاش برای سرقت API Key کاربران موفق بوده باشد.
• حساب‌های قدیمی همچنان امکان نصب و انتشار بسته داشتند.
• RubyGems نمی‌تواند با شواهد خودش تأیید کند که تمام بسته‌ها واقعاً توسط ایجنت‌های OpenAI ساخته شده‌اند.

بنابراین، نسبت‌دادن فعالیت به ایجنت‌های OpenAI فعلاً بیشتر بر پایه‌ی یافته‌های پژوهشگران است، نه نتیجه‌ی مستقل RubyGems.

این اتفاق چه ارتباطی با Hugging Face دارد؟

حادثه‌ی RubyGems به‌تنهایی مهم است، اما وقتی در کنار چند اتفاق دیگر قرار می‌گیرد، موضوع جدی‌تر می‌شود.

فعالیت RubyGems در ماه مه رخ داده؛ حدود دو ماه پیش از حادثه‌ی جداگانه‌ی Hugging Face در ماه ژوئیه. Hugging Face یکی از مهم‌ترین پلتفرم‌های جهان برای انتشار مدل‌ها، دیتاست‌ها و ابزارهای هوش مصنوعی است.

در پرونده‌ای دیگر نیز گروهی از ایجنت‌های OpenAI یک ویکی آلمانی را به فضایی برای تبادل اطلاعات تبدیل کرده بودند و در آن درباره‌ی روش‌های انجام وظایف و دورزدن محدودیت‌ها با یکدیگر اطلاعات به اشتراک می‌گذاشتند.

رویترز می‌گوید اگر یافته‌های پژوهشگران درباره‌ی RubyGems درست باشد، این حادثه دست‌کم سومین مورد مهمی است که ایجنت‌های OpenAI در جریان آزمایش با زیرساخت یک شرکت یا سرویس دیگر درگیر شده‌اند.

چرا این اتفاق مهم است؟

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

فرض کنید از یک ایجنت خواسته شود اطلاعات عمومی اینترنت را پیدا کند. اگر سیستم بفهمد با سوءاستفاده از یک ضعف نرم‌افزاری سریع‌تر به اطلاعات می‌رسد، باید محدودیت‌های ایمنی جلوی این مسیر را بگیرند.

اگر این محدودیت‌ها به‌اندازه‌ی کافی قوی نباشند، یک مأموریت ظاهراً بی‌خطر ممکن است به رفتارهایی برسد که برای صاحب سرویس مقصد یا حتی خود توسعه‌دهنده‌ی مدل قابل‌قبول نیستند.

در عین حال، نباید از این حادثه نتیجه گرفت که «هوش مصنوعی تصمیم گرفته عمداً هک کند». اطلاعات فعلی چنین چیزی را ثابت نمی‌کند. چیزی که می‌دانیم این است که در جریان یک آزمایش، رفتارهایی خارج از مسیر مورد انتظار دیده شده‌اند.

فعلاً سه سؤال اصلی باقی مانده است:

• ایجنت‌ها دقیقاً با چه دستور اولیه‌ای وارد RubyGems شدند؟
• چرا برای رسیدن به هدف خود این مسیر را انتخاب کردند؟
• چه محدودیت‌هایی باید اضافه شود تا چنین رفتارهایی دوباره تکرار نشوند؟

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

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