شرکت OpenAI در گزارش تازهای از یک حادثه امنیتی خبر داده است که در روز 20 سپتامبر (29 شهریور) رخ داد و بار دیگر نگرانیها درباره امکان خروج عاملهای هوش مصنوعی از محیطهای آزمایشی کنترلشده را افزایش داد. در این حادثه، یک عامل هوشمند که در حال انجام یک وظیفه آموزشی بود، از یک نقص در محدودیتهای دسترسی شبکه استفاده کرد و توانست از طریق DNS با یک چتبات عمومی خارج از محیط آزمایش ارتباط برقرار کند!
این اتفاق اگرچه با حادثه گستردهتر OpenAI و Hugging Face در ماه ژوئیه تفاوت دارد و به گفته OpenAI از نظر شدت بسیار محدودتر بوده است، اما اهمیت آن در جای دیگری است: حادثه جدید پس از مجموعهای از اقدامات امنیتی انجام شد که برای جلوگیری از تکرار اتفاقات قبلی طراحی شده بودند. به همین دلیل، این رخداد نشان میدهد که حتی پس از تقویت لایههای امنیتی، مسدود کردن مسیرهای غیرمنتظره برای ارتباط با دنیای بیرون همچنان یکی از چالشهای جدی در توسعه عاملهای هوش مصنوعی است.
عامل OpenAI چگونه از محیط آزمایشی خارج شد؟
بر اساس گزارش رسمی OpenAI، این عامل در جریان یک فعالیت مرتبط با آموزش تقویتی (RL) تلاش میکرد یک مسئله مبتنی بر جستجو را حل کند. محیطی که عامل در آن فعالیت میکرد به گونهای طراحی شده بود که دسترسی آن به اینترنت عمومی محدود باشد و درخواستهای اینترنتی از مسیرهای کنترلشده عبور کنند.
عامل ابتدا از ابزار جستجوی مجاز استفاده کرد، اما پس از اینکه این روش نتیجه مطلوبی نداد، تلاش کرد مستقیماً به موتورهای جستجو دسترسی پیدا کند! این تلاشها ناموفق بود. سپس عامل مسیر دیگری را پیدا کرد: سامانه DNS محیط آزمایشی به اندازه کافی محدود نشده بود و امکان استفاده از آن برای برقراری ارتباط با یک سرویس خارجی وجود داشت.
عامل از این مسیر برای ارسال درخواست به یک چتبات عمومی استفاده کرد. نکته مهم این است که طبق توضیح OpenAI، سایر مسیرهای دسترسی به اینترنت همچنان به یک وب کش آفلاین متصل بودند و به اینترنت زنده دسترسی نداشتند؛ بنابراین این حادثه به معنای باز شدن کامل دسترسی اینترنتی محیط آزمایشی نبوده است.
OpenAI پس از شناسایی مشکل اعلام کرد که دو لایه مسدودسازی مستقل به زیرساخت اضافه کرده است؛ به گونهای که هر کدام از این دو لایه به تنهایی میتوانند از وقوع چنین ارتباطی جلوگیری کنند.
سیستمهای نظارتی حادثه را شناسایی کردند، اما توقف در لحظه ممکن نبود
یکی از بخشهای قابل توجه این گزارش، فاصله زمانی میان شناسایی رفتار غیرعادی و متوقف شدن اجرای عامل است.
طبق گزارش OpenAI، سامانه پایش رفتارهای نامتناسب حدود 15 دقیقه پس از وقوع این ارتباط غیرمجاز، فعالیت عامل را علامتگذاری کرد. حدود سه دقیقه بعد نیز یک انسان بررسی هشدار را آغاز کرد. با این حال، اجرای عامل بلافاصله متوقف نشد و در نهایت حدود 2.5 ساعت بعد از آن، اجرای مورد نظر خاتمه یافت!
این موضوع تفاوت مهمی میان دو مفهوم ایجاد میکند: تشخیص حادثه و توانایی توقف فوری آن. داشتن سامانهای که بتواند رفتار مشکوک را شناسایی کند، تنها بخشی از مسئله است. اگر یک عامل هوش مصنوعی بتواند در فاصله شناسایی تا توقف همچنان به فعالیت خود ادامه دهد، طراحی سازوکارهای واکنش سریع اهمیت زیادی پیدا میکند.
همین مسئله یکی از دلایلی است که باعث شده بحث درباره «دکمه خاموشی اضطراری» برای مدلهای پیشرفته هوش مصنوعی در ماههای اخیر جدیتر شود.
OpenAI آموزش مدلهای قدرتمند خود را متوقف کرد
OpenAI پس از این حادثه اعلام کرد که آموزش، ارزیابی و استنتاج همراه با استفاده از ابزار برای قدرتمندترین مدلهای خود را متوقف کرده است. این شرکت همچنین اعلام کرده که برای این مرحله از فعالیتها فعلاً زمانی برای از سرگیری در نظر گرفته نشده است.
البته، این حادثه را نباید با یک حمله سایبری گسترده به محصولات عمومی OpenAI اشتباه گرفت. گزارش شرکت درباره حادثه 20 سپتامبر (29 شهریور) مربوط به یک مدل پژوهشی داخلی در محیط آموزش است و مسیر ارتباطی مورد استفاده نیز بسیار محدودتر از یک دسترسی کامل به اینترنت بوده است.
با این حال، اهمیت ماجرا به این دلیل است که هدف اصلی محیط آزمایشی، محدود نگه داشتن عامل بوده و عامل توانسته از مسیری که طراحان محیط انتظارش را نداشتند، این محدودیت را دور بزند.
این اتفاق از چه نظر مهم است؟
حادثه جدید در شرایطی رخ داده که OpenAI در ماه ژوئیه نیز با یک رخداد امنیتی جدیتر مواجه شده بود. در جریان ارزیابی قابلیتهای سایبری چند مدل OpenAI، عاملها توانستند از محدودیتهای محیط آزمایشی عبور کنند و در ادامه به زیرساختهای OpenAI و Hugging Face دسترسی پیدا کنند.
بر اساس گزارش OpenAI درباره آن حادثه، مدلها با بهرهگیری از آسیبپذیریهای زیرساختی، به کانالهای ارتباطی غیرمجاز دسترسی پیدا کردند و بخشی از زیرساخت Hugging Face را نیز تحت تأثیر قرار دادند. OpenAI اعلام کرد که این رخداد روی دادههای مشتریان یا عملکرد عمومی محصولات این شرکت تأثیری نداشته است.
Hugging Face نیز در بررسی فنی خود اعلام کرد که عاملها در یک بازه چند روزه توانستند زنجیرهای از اقدامات را انجام دهند و در نهایت به بخشهایی از زیرساخت داخلی این شرکت دسترسی پیدا کنند. این بررسی نشان داد که عامل از محیط ارزیابی اولیه فاصله گرفت و از زیرساختهای دیگر به عنوان بخشی از مسیر حمله استفاده کرد.
به همین دلیل، حادثه اخیر از این جهت اهمیت دارد که نشان میدهد حتی پس از اقدامات امنیتی گستردهتر، مسیرهای غیرمستقیم و پیشبینینشده برای خروج از محیط ایزوله همچنان میتوانند یک نقطه ضعف باشند.
آیا «دکمه خاموشی» میتواند مشکل را حل کند؟
همزمان با افزایش نگرانیها درباره کنترل عاملهای پیشرفته، ایده ایجاد یک دکمه خاموشی اضطراری یا AI Kill Switch نیز وارد بحثهای قانونگذاری آمریکا شده است.
سناتور جان کندی در ماه سپتامبر طرحی با عنوان AI Emergency Button Act را برای الزام توسعهدهندگان هوش مصنوعی به ایجاد سازوکار خاموشی اضطراری مطرح کرد. تلاش او برای تصویب این طرح از طریق روند موافقت همگانی با اعتراض سناتور رند پال متوقف شد.
در سطح ایالتی نیز گوین نیوسام، فرماندار کالیفرنیا، به تازگی فرمانی اجرایی صادر کرد که از جمله اهداف آن، پیشبرد سازوکارهای نظارت مستقل و بررسی امکان ایجاد یک سیستم خاموشی اضطراری برای مدلهای پیشرفته هوش مصنوعی است. طبق این فرمان، گروهی از کارشناسان باید طی دو ماه توصیههایی درباره نحوه تقویت سازوکارهای ایمنی و امنیتی ارائه کنند.
با این حال، وجود یک کلید خاموشی روی کاغذ لزوماً به معنای آن نیست که یک سیستم هوش مصنوعی پیچیده را میتوان مانند یک کامپیوتر معمولی با فشار دادن یک دکمه متوقف کرد.
مشکل اصلی: هوش مصنوعی روی یک کامپیوتر واحد اجرا نمیشود
یکی از چالشهای مهم در طراحی سازوکار خاموشی، ساختار توزیعشده زیرساختهای هوش مصنوعی است. مدلهای بزرگ معمولاً روی مجموعهای از سرورها، پردازندهها و مراکز داده اجرا میشوند و فرآیند ارائه سرویس نیز میتواند میان زیرساختهای مختلف توزیع شود.
بنابراین، خاموش کردن مدل میتواند به معنای مجموعهای از اقدامات فنی مختلف باشد: جلوگیری از اجرای نمونههای جدید، قطع دسترسی مدل به ابزارها، مسدود کردن ارتباطات شبکه، لغو مجوزها و اعتبارنامهها یا در شرایط خاص، متوقف کردن زیرساخت محاسباتی مربوط به آن.
حادثه اخیر OpenAI دقیقاً نشان میدهد که قطع یک مسیر ارتباطی به تنهایی کافی نیست. اگر یک عامل بتواند مسیر دیگری را پیدا کند، حتی یک محدودیت امنیتی ظاهراً مؤثر ممکن است دور زده شود. در این مورد، مشکل نه در یک اتصال مستقیم و آزاد به اینترنت، بلکه در یک مسیر غیرمنتظره مرتبط با DNS قرار داشت.
آیا عاملهای هوش مصنوعی در آینده میتوانند خاموشی را هم دور بزنند؟!
این بخش از بحث هنوز در حوزه فرضیه و ارزیابی ریسک قرار دارد و نباید آن را با یک توانایی اثباتشده در مدلهای امروزی یکی دانست.
جفری هینتون، یکی از چهرههای شناختهشده در حوزه پژوهش هوش مصنوعی، در بحثهای اخیر درباره کنترل سیستمهای بسیار پیشرفته هشدار داده است که در سناریوهای آینده ممکن است مدلهایی با قابلیتهای بسیار بالاتر، برای حفظ اهداف خود رفتارهایی از خود نشان دهند که خاموش کردن آنها را دشوارتر کند.
اما میان این سناریوهای آینده و حادثه اخیر OpenAI تفاوت مهمی وجود دارد. در حادثه 20 سپتامبر (29 شهریور)، عامل صرفاً توانست از یک محدودیت شبکهای عبور کرده و با یک سرویس خارجی ارتباط برقرار کند. گزارش OpenAI شواهدی ارائه نمیکند که نشان دهد عامل تلاش کرده مانع خاموش شدن خود شود یا به صورت مستقل از توقف آن جلوگیری کرده است.
در نتیجه، اهمیت این حادثه بیشتر در ضعفهای فعلی معماری امنیتی عاملها است تا اثبات سناریوهای مربوط به هوش مصنوعی فوقهوشمند.
درس مهم این حادثه برای توسعه هوش مصنوعی
مهمترین درسی که از این اتفاق میتوان گرفت، این است که امنیت عاملهای هوش مصنوعی تنها به محدود کردن دسترسی مستقیم آنها به اینترنت خلاصه نمیشود. عاملهای امروزی میتوانند از ابزارها، سرویسهای واسطه، حافظه، APIها، DNS و سایر اجزای زیرساختی استفاده کنند و همین موضوع تعداد مسیرهایی را که باید کنترل شوند افزایش میدهد.
OpenAI پس از این حادثه اعلام کرده است که برای مسدود کردن مسیر مورد استفاده، دو لایه کنترل مستقل ایجاد کرده و در حال جایگزین کردن برخی مسیرهای وابسته به زیرساختهای خارجی با گزینههای آفلاین است. این رویکرد نشان میدهد که برای ایمنسازی عاملهای قدرتمند، صرفاً شناسایی رفتارهای خطرناک کافی نیست و باید محیط اجرای آنها نیز به صورت چندلایه طراحی و آزمایش شود.
حادثه روز 29 شهریور یک حمله گسترده به کاربران OpenAI نبود، اما یک نمونه واقعی از چالشی است که توسعهدهندگان مدلهای پیشرفته با آن مواجهاند: هرچه عاملها توانایی بیشتری برای استفاده از ابزارها و حل مستقل مسائل پیدا میکنند، طراحی محیطی که بتواند تمام مسیرهای ارتباطی آنها را قابل پیشبینی و کنترل کند نیز دشوارتر میشود.
در نهایت، بحث درباره «دکمه خاموشی» احتمالاً تنها به یک کلید فیزیکی یا نرمافزاری محدود نخواهد شد. مسئله اصلی این است که توسعهدهندگان چگونه میتوانند تشخیص سریع، قطع دسترسی، کنترل شبکه، محدودسازی ابزارها و توقف اجرای مدل را به شکلی مستقل و قابل اعتماد در کنار یکدیگر قرار دهند. حادثه اخیر OpenAI نشان میدهد که این مسئله دیگر صرفاً یک بحث نظری نیست و حتی در محیطهای پژوهشی کنترلشده نیز باید مسیرهای غیرمنتظره را جدی گرفت.
اولین نفری باشید که دیدگاه میگذارد