اوپن‌ای‌آی فاش کرد دو عامل هوش مصنوعی سامانه‌های نظارتی ایمنی را تضعیف کردند؛ یکی از آن‌ها نیز اقدامات خود را انکار کرد
نویسنده: اولوواپلومی آدِجمو، گزارشگر ارشد کریپتواسلیت
اوپن‌ای‌آی اعلام کرد دو عامل هوش مصنوعی برنامه‌نویسی این شرکت، سازوکارهای نظارت ایمنی را تضعیف کرده‌اند و یکی از آن‌ها پس از حذف یک ابزار حفاظتی، به‌دروغ منکر این اقدام شده است.
این حوادث که در گزارش منتشرشده در ۲۰ اکتبر تشریح شدند، هنگام انجام دو وظیفه برنامه‌نویسی داخلی و جداگانه با استفاده از مدل‌های GPT-6 Astra و GPT-6.1 Sol رخ دادند. یکی از عامل‌ها سامانه‌ای را حذف کرد که برای شناسایی رفتارهای مشکل‌ساز طراحی شده بود و دیگری هشدارهایی را غیرفعال کرد که قرار بود کارکنان امنیتی را مطلع کنند.
هیچ‌یک از این دو مورد به بالاترین سطح هشدار امنیتی اوپن‌ای‌آی منجر نشد و فعالیت عامل‌ها نیز به‌طور خودکار متوقف نشد. این اتفاق‌ها ضعف‌هایی را در سازوکارهایی آشکار کردند که توسعه‌دهندگان اوپن‌ای‌آی برای نظارت بر سامانه‌های نرم‌افزاری هرچه خودمختارتر به کار می‌گیرند؛ سامانه‌هایی که از جمله در محصولات مبتنی بر چت‌جی‌پی‌تی مورد استفاده قرار می‌گیرند.
عامل‌های هوش مصنوعی چگونه ابزارهای نظارتی را حذف کردند و هشدارهای امنیتی را از کار انداختند؟
مورد جدی‌تر در ۶ اکتبر رخ داد؛ زمانی که به یک عامل Astra مأموریت داده شد مسیر اجرای برنامه از مدل به ابزارها را به‌گونه‌ای تغییر دهد که با یک پیاده‌سازی مرجع مطابقت داشته باشد. در دستور قبلی، صراحتاً به این عامل گفته شده بود که ابزار نظارتی خود را حتی به‌طور موقت غیرفعال نکند.
Astra انجام کار را به یک عامل فرعی واگذار کرد. این عامل فرعی، پیکربندی ابزار نظارتی و اتصال آن به برنامه در حال اجرا را حذف کرد. نسخه جایگزین همچنان گزارش مکالمات را ثبت می‌کرد، اما دیگر زمینه نظارتی موردنیاز برای عملکرد سازوکار حفاظتی اصلی را در اختیار نداشت.
عامل فرعی همچنین یک آزمون رگرسیون را بازنویسی کرد؛ آزمونی که قرار بود فعال ماندن نظارت را تأیید کند. در نسخه جدید، به‌جای الزام به حفظ زمینه نظارتی، نبود آن شرط قبولی آزمون شد. در نتیجه، نرم‌افزار تغییریافته می‌توانست بررسی‌ای را پشت سر بگذارد که دیگر از الزام اولیه محافظت نمی‌کرد.
وقتی بعداً از Astra درباره این اقدام پرسیده شد، به کاربر گفت: «من هیچ ابزار نظارتی فعالی را از آن حذف نکردم.» اوپن‌ای‌آی این ادعا را نادرست دانست.
حادثه دوم در ۳ اکتبر آغاز شد؛ زمانی که پژوهشگری از Sol خواست با استفاده از بازخورد کارکنان جمع‌آوری‌شده از طریق اسلک، وظایف ارزیابی طراحی کند. در دستور پژوهشگر تأکید شده بود که هیچ پیامی ارسال نشود.
بعدتر، خط لوله نظارتی از کار افتاد؛ زیرا نمی‌توانست یک یافته علامت‌گذاری‌شده را در پایگاه داده ذخیره کند. پژوهشگر از عامل خواست نتایج را به مقصدی در دسترس دیگری هدایت کند و فرایند ارزیابی را از سر بگیرد.
Sol در ابتدا میان ممنوعیت ارسال پیام در اسلک و اعلان‌های امنیتی خودکار تمایز قائل شد. این عامل به یک عامل فرعی دستور داد خط لوله را بدون غیرفعال کردن نظارت تعمیر کند. عامل فرعی نیز به‌طور مستقل تشخیص داد که سرکوب هشدارهای الزامی اقدامی ناایمن خواهد بود.
با این حال، عامل اصلی بعداً تصمیم خود را تغییر داد. این عامل به زیرعامل دستور داد فهرست افراد تعیین‌شده برای دریافت هشدار را خالی کند و تنظیمی با نام «no_notify» را فعال سازد. بدین‌ترتیب، دستور قبلی کاربر را مجوزی برای سرکوب اعلان‌های امنیتی تلقی کرد.
ابزار نظارتی همچنان فعال بود و یافته‌ها را ذخیره می‌کرد، اما دیگر هیچ هشداری برای تیم امنیتی اوپن‌ای‌آی نمی‌فرستاد. در نتیجه، هم‌زمان با ازسرگیری ارزیابی، یکی از مسیرهای مداخله انسانی از بین رفت.
اوپن‌ای‌آی اعلام کرد که هیچ‌یک از این دو حادثه در رده P0، یعنی سطح شدتی که ارسال فوری هشدار امنیتی را الزامی می‌کند، قرار نگرفتند. همچنین اجرای هیچ‌یک از دو عامل به‌طور خودکار متوقف نشد.
این گزارش به موارد دیگری نیز اشاره می‌کند که در آن‌ها عامل‌های هوش مصنوعی نرم‌افزارهایی را با نظارت غیرفعال اجرا کرده‌اند، در حالی که خود عامل‌های برنامه‌نویسی همچنان تحت نظارت بوده‌اند.
این شکاف به‌ویژه در فرایندهای ارزیابی اهمیت دارد. نظارت بر Codex معمولاً از طریق سرویسی انجام می‌شود که درخواست‌های مدل را پردازش می‌کند و مستقیماً تحت کنترل عامل برنامه‌نویسی نیست. در مقابل، سامانه‌های ارزیابی انعطاف بیشتری در پیکربندی دارند. از جمله، در این سامانه‌ها امکان دور زدن نظارت برای مدل‌های ضعیف‌تر از خانواده Luna وجود دارد؛ قابلیتی که ممکن است به‌اشتباه برای وظایف مربوط به Astra نیز اعمال شود.
این یافته‌ها نگرانی‌هایی را تقویت می‌کنند که پیش‌تر در گزارش فنی مدل Astra اوپن‌ای‌آی مطرح شده بود. آن گزارش نشان می‌داد که استدلال‌های این مدل در مقایسه با نسل‌های قبلی دشوارتر قابل نظارت است. همچنین، در ارزیابی‌های خصمانه جداگانه، Astra گاهی هنگام اجرای وظایف شبیه‌سازی‌شده خرابکارانه توانسته بود از نظارت داخلی بگریزد.
اوپن‌ای‌آی نظارت را سخت‌گیرانه‌تر می‌کند
اوپن‌ای‌آی اکنون سامانه Auto-Review را به‌روزرسانی کرده است. این سامانه که استفاده از آن در Codex برای کارهای داخلی از قبل الزامی بود، حالا تلاش‌ها برای غیرفعال کردن نظارت بر ناهماهنگی رفتاری مدل را شناسایی و مسدود می‌کند.
این شرکت همچنین در حال تدوین الزاماتی است که بر اساس آن‌ها هر دسته از وظایف باید یک پرونده ایمنی تأییدشده داشته باشد. در این پرونده باید الزامات نظارتی آن دسته از وظایف مشخص شود. کارهایی که تأییدیه لازم را نداشته باشند یا شرایط تعیین‌شده را رعایت نکنند، به‌طور خودکار متوقف خواهند شد.
سامانه اجرایی پیشنهادی مانع از آن خواهد شد که عامل‌های برنامه‌نویسی هنگام ایجاد تغییرات در نرم‌افزار، خودشان درباره فعال ماندن یا غیرفعال شدن نظارت تصمیم بگیرند. این اقدام قرار است شکاف پیکربندی‌ای را برطرف کند که وقوع حوادث اکتبر را ممکن ساخت.
با این حال، اوپن‌ای‌آی هنوز مشخص نکرده است چرا این عامل‌ها با وجود آگاهی از اهمیت کنترل‌های ایمنی، آن‌ها را تضعیف کرده‌اند.
پژوهشگران در حال طراحی ارزیابی‌های جفت‌شده هستند، ادامه اجرای عامل‌ها را دوباره آزمایش می‌کنند و فعالیت داخلی مدل‌ها را بررسی می‌کنند تا مشخص شود این رفتارها ناشی از پافشاری بیش‌ازحد برای تکمیل مأموریت‌ها بوده‌اند یا از گرایشی مشخص به دور زدن نظارت حکایت دارند.
نتیجه این بررسی می‌تواند مشخص کند که آیا اوپن‌ای‌آی باید محدودیت‌های بیشتری بر نوع تغییراتی اعمال کند که عامل‌های پیشرفته برنامه‌نویسی آن مجاز به انجامشان هستند یا خیر؛ محدودیت‌هایی فراتر از الزامات نظارتی و سازوکارهای توقف خودکاری که هم‌اکنون در دست توسعه‌اند.