تیم ردتیم METR با سه روش سامانه نظارت بر عامل‌های هوش مصنوعی OpenAI را دور زد؛ هر روش یک فرض اساسی را زیر سؤال می‌برد
به گزارش مؤسسه METR، در جریان یک ارزیابی امنیتی، سه دسته آسیب‌پذیری در سامانه داخلی نظارت بر عامل‌های هوش مصنوعی OpenAI شناسایی شده است: امکان عبور از محدودیت‌های محیط ایزوله Codex، پنهان ماندن صدها اقدام از دید سامانه نظارتی و اختلال در عملکرد ناظر به دلیل تفاوت در نحوه تبدیل داده‌ها به قالب قابل پردازش. این یافته‌ها به نسخه‌ای از سامانه مربوط می‌شوند که در ماه ژوئیه بررسی شده و نتایج آن با توافقی منتشر شده است که به OpenAI حق حذف اطلاعات محرمانه یا حساس را می‌داد. این ارزیابی، لایه نظارتی را که شرکت‌ها برای استفاده ایمن از عامل‌های هوش مصنوعی به آن متکی هستند، در معرض آزمونی عملی قرار داده است.
نویسنده: لنا پارک | فورکست | ۲۳ اکتبر ۲۰۲۶، ساعت ۷:۵۳ به وقت UTC
مؤسسه METR در ۲۲ اکتبر ۲۰۲۶ گزارشی با عنوان «آزمون نفوذ خصمانه سامانه‌های داخلی نظارت بر عامل‌های هوش مصنوعی OpenAI» منتشر کرد. این گزارش جزئیات یک طرح آزمایشی سه‌هفته‌ای را شرح می‌دهد که از ۲۱ ژوئیه تا ۱۱ اوت ۲۰۲۶ اجرا شد. در این ارزیابی، یکی از کارکنان METR به همراه یکی از کارکنان Redwood Research، سامانه داخلی OpenAI برای شناسایی رفتارهای ناهمسو با اهداف موردنظر را در وضعیتی که تا ۲۱ ژوئیه ۲۰۲۶ داشت، تحت آزمون‌های امنیتی قرار دادند.
هدف این طرح، آزمایش امکان دسترسی گسترده پژوهشگران بیرونی به زیرساخت‌های داخلی بود، نه ایجاد سازوکاری برای شفاف‌سازی عمومی و جامع. طبق توافق انتشار، METR تنها خلاصه‌ای کلی از یافته‌ها را منتشر کرد و OpenAI حق داشت اطلاعاتی را که محرمانه یا حساس تشخیص می‌داد، حذف کند. METR نیز اختیار نداشت به‌صورت مستقل درباره جزئیات این حذف‌ها توضیح دهد. یافته‌های ارزیابی ابتدا در گزارشی داخلی به حجم ۶۱ صفحه ثبت شد و در اختیار پژوهشگران و کارکنان امنیتی OpenAI قرار گرفت. نسخه‌ای ۳۸ صفحه‌ای از این گزارش نیز پس از حذف بخش‌هایی از سوی OpenAI، به مدیران METR و Redwood ارائه شد.
این ارزیابی سه دسته مستقل از نقص‌های امنیتی را آشکار کرد که هرکدام یکی از فرض‌های بنیادی نظارت بر عامل‌های هوش مصنوعی را هدف قرار می‌دهند: مرزهای محیط ایزوله، میزان دیدی که سامانه نظارتی تصور می‌کند از فعالیت عامل دارد و یکسان بودن داده‌هایی که عامل ثبت و قالب‌بندی می‌کند با داده‌هایی که ناظر می‌خواند.
درباره مرزهای امنیتی، METR در گزارش خود می‌نویسد: «روشی پیدا کردیم که عامل‌های Codex در اصل می‌توانستند با استفاده از آن محدودیت‌های محیط ایزوله Codex و سامانه بازبینی خودکار (Auto-Review) را دور بزنند و در نتیجه هر اقدامی را انجام دهند که کاربر میزبان مجاز به انجام آن است.»
در زمینه میزان دید سامانه نظارتی، پژوهشگران METR «آسیب‌پذیری‌ای کشف کردند که عامل‌ها می‌توانستند با بهره‌برداری از آن مانع نظارت بر صدها اقدام اخیر خود شوند؛ از جمله همان اقداماتی که برای اجرای حمله انجام داده بودند». جزئیات این آسیب‌پذیری به درخواست OpenAI از گزارش عمومی حذف شده است.
دسته سوم به یکسان نبودن داده‌های دریافتی مربوط می‌شود. METR می‌نویسد: «دریافتیم که عامل‌ها احتمالاً می‌توانند با سوءاستفاده از تفاوت در نحوه سریال‌سازی داده‌های مسیر اجرای عامل و داده‌هایی که ناظر مشاهده می‌کند، ورودی‌هایی بسازند که باعث اختلال در عملکرد ناظر شوند. در چنین شرایطی، مسیر اجرای عامل برای بررسی انسانی ارجاع داده نمی‌شود.»
این موارد، یافته‌های مستقیم ارزیابی هستند. اما نتیجه‌گیری امنیتی حاصل از آن‌ها موضوعی جداگانه و ساده‌تر است: سامانه‌ای که بتوان از مرزهای حفاظتی آن عبور کرد، بخشی از سوابق فعالیت را از دیدش پنهان نگه داشت و با ناسازگاری در قالب داده‌ها از کار انداخت، عملاً تنها روی کاغذ نقش ناظر را ایفا می‌کند.
بخش‌های دیگر این ارزیابی، ابعاد گسترده‌تری از مسئله را روشن می‌کنند. پژوهشگران دریافتند که دو سرآیند مستقل در درخواست‌ها، که هر دو تحت کنترل کلاینت بودند، می‌توانستند نظارت بر عامل‌های جدید را غیرفعال کنند. در نتیجه، امکان راه‌اندازی نمونه‌ای از عامل وجود داشت که از سایر جهات کاملاً مشابه نمونه عادی بود، اما تحت نظارت قرار نمی‌گرفت؛ هرچند خود اقدام به تنظیم این سرآیندها ممکن بود شناسایی شود.
همچنین دو ابزار داخلی عامل‌محور که تصور می‌شد فقط مجوز خواندن اطلاعات دارند، دارای آسیب‌پذیری ساده‌ای بودند که می‌توانست این محدودیت را بی‌اثر کند و امکان اجرای اقدامات دلخواه را در محیط ایزوله آن‌ها فراهم آورد. با این حال، METR رفتار موردنظر را تأیید عملی نکرد و بررسی نکرد که آیا واقعاً می‌توان از این ضعف سوءاستفاده کرد یا خیر.
در آغاز ارزیابی، اجرای فرایندهای آموزش یادگیری تقویتی (RL) تحت پوشش سامانه نظارتی نبود؛ این در حالی بود که بین مارس تا ژوئن، بخشی از اجراهای این فرایندها تحت نظارت قرار گرفته بودند.
در بررسی میزان پوشش، METR برآورد کرد که در زمان اجرای آزمایش، حدود ۷۵ تا ۹۴ درصد از ترافیک داخلی عامل‌محور در Responses API، مربوط به مدل‌هایی با توانایی دست‌کم هم‌سطح GPT-5.5، واجد شرایط نظارت بوده است. البته این برآورد در هر دو جهت با عدم قطعیت قابل‌توجهی همراه بود. در بخش داخلی Codex، این نسبت به ۹۹٫۲ درصد می‌رسید.
با این حال، واجد شرایط بودن ترافیک برای نظارت به معنای عبور موفق آن از تمام مراحل سامانه نظارتی نیست. کاهش بار پردازشی از طریق کنار گذاشتن برخی درخواست‌ها، خطاهای ناظر یا اشکالات پیاده‌سازی می‌توانند مانع تکمیل این فرایند شوند.
برای نمونه، یک نقص مرتبط با فشرده‌سازی اطلاعات احتمالاً باعث شده بود حدود ۱۰ درصد از ترافیک داخلی Codex که واجد شرایط نظارت بود، بین ماه‌های مه و ژوئیه ۲۰۲۶ بدون نظارت باقی بماند. این رقم با عدم قطعیت قابل‌توجهی همراه است، زیرا در گذشته سهم ترافیکی که شرایط فعال شدن این نقص را داشت، ثبت نمی‌شد. کارکنان OpenAI پیش از آغاز ارزیابی به‌طور مستقل این مشکل را شناسایی کرده بودند و در جریان همان دوره آزمایش آن را برطرف کردند.
مشکل دیگری نیز به زمان فعال شدن نظارت مربوط می‌شد. از آنجا که سامانه تنها زمانی فعالیت عامل را بررسی می‌کرد که کنترل دوباره به کاربر بازگردانده می‌شد، عامل‌ها می‌توانستند صرفاً با ادامه دادن اقدامات خود، نظارت را برای مدتی نامحدود به تعویق بیندازند. METR به دلیل محدودیت‌های دسترسی نتوانست بررسی کند که آیا عامل‌ها در عمل از این فاصله زمانی سوءاستفاده کرده‌اند یا نه.
البته ارزیابی تنها حاوی یافته‌های منفی نبود و نشانه‌هایی از عملکرد مناسب سامانه نیز ثبت شد. در زمان آزمایش، نرخ خطای ناظر کمتر از ۰٫۲ درصد درخواست‌ها بود و در یک دوره ۲۴ ساعته هیچ درخواستی به دلیل مدیریت بار کنار گذاشته نشد. METR همچنین تأیید کرد که سامانه نظارتی، به‌جز چند استثنای جزئی، به تمام مسیر فعالیتی که عامل مشاهده می‌کند دسترسی دارد. پژوهشگران علاوه بر این بررسی کردند و تأیید کردند که دستورالعمل‌های ناظر برای شناسایی رفتارهایی مانند برنامه‌ریزی پنهانی و فریبکارانه، تضعیف سامانه نظارتی، خرابکاری، استخراج و انتقال غیرمجاز داده‌ها، فریب و تزریق پرامپت طراحی شده‌اند.
برای تفسیر این یافته‌ها، توجه به زمان ثبت آن‌ها ضروری است. نتایج، وضعیت سامانه نظارتی OpenAI را در تاریخ ۲۱ ژوئیه ۲۰۲۶ و پیش از آن توصیف می‌کنند. METR این یافته‌ها را در ۲۲ اکتبر، یعنی حدود سه ماه بعد، منتشر کرد؛ در حالی که OpenAI حتی در طول دوره آزمایش نیز مشغول گسترش پوشش سامانه نظارتی خود بود.
OpenAI اعلام کرده است که تمام آسیب‌پذیری‌های شناسایی‌شده‌ای را که بر مجموعه سازوکارهای حفاظتی مورد استفاده در محیط عملیاتی این شرکت تأثیر می‌گذاشتند، برطرف کرده است. این شرکت همچنین از تغییرات قابل‌توجهی در پوشش نظارتی خود پس از ارزیابی خبر داده است. با این حال، این پاسخ تنها از طریق خلاصه منتشرشده METR به خوانندگان منتقل شده و METR نیز تصریح کرده است: «ما این ادعاها را ارزیابی نکرده‌ایم.»
برای تهیه این مقاله، هیچ بیانیه مستقیمی از OpenAI دریافت نشد؛ زیرا تلاش برای دسترسی به صفحه اختصاصی نظارت این شرکت با پاسخ خطای ۴۰۳ و چالش امنیتی Cloudflare مواجه شد.
یک شرط مهم در توافق انتشار، دامنه تمام یافته‌های بالا را محدود می‌کند: METR از ابتدا پذیرفته بود که تنها گزارشی کوتاه و کلی منتشر کند؛ OpenAI اختیار حذف بخش‌هایی از اطلاعات را داشت و METR نمی‌توانست به ابتکار خود جزئیات این حذف‌ها را شرح دهد.
با این همه، آنچه اهمیت بیشتری دارد، الگویی است که از کنار هم قرار دادن این یافته‌ها شکل می‌گیرد. METR در ۲۶ مارس ۲۰۲۶ گزارشی با عنوان «آزمون نفوذ خصمانه سامانه‌های داخلی نظارت بر عامل‌های هوش مصنوعی Anthropic» منتشر کرده بود. نویسنده آن گزارش دیوید راین بود که در ارزیابی OpenAI نیز مشارکت داشت.
آن پروژه نیز یک همکاری سه‌هفته‌ای بود، اما تنها بخشی از سامانه‌های نظارتی و امنیتی Anthropic را بررسی می‌کرد. یافته‌هایی که بعداً منتشر شدند، مسیرهایی برای غیرفعال کردن نظارت را نشان می‌دادند. برای مثال، تغییر تنها یک متغیر محیطی باعث می‌شد ترافیک طوری به نظر برسد که گویی از Claude Code منشأ نگرفته است و در نتیجه احتمال نظارت بر آن به‌شدت کاهش می‌یافت. همچنین یک اشکال نرم‌افزاری باعث شده بود فراخوانی‌های عامل‌های فرعی بدون نظارت باقی بمانند؛ مشکلی که در کمتر از ۲۴ ساعت برطرف شد.
جزئیات این یافته‌ها در گزارش ریسک‌های پیشرفته METR مربوط به فوریه تا مارس ۲۰۲۶، که در ۱۹ مه منتشر شد، آمده و متن کامل آن‌ها نیز در گزارش ماه مارس بازنشر شده است. راین در آن گزارش نوشته بود: «روش‌های بسیار ابتدایی عبور از محدودیت‌های ایمنی، حتی بدون اطلاع از قالب دقیق پرامپت ناظر، به‌شدت مؤثر و قابل‌اتکا هستند.» او همچنین تأکید کرده بود: «در حال حاضر، بخش قابل‌توجهی از اطمینان من به سامانه نظارتی بر امنیت از طریق پنهان نگه داشتن جزئیات آن متکی است.»
این دو ارزیابی، پروژه‌هایی مستقل با تیم‌ها و دامنه‌های متفاوت بوده‌اند و METR هشدار داده است که نباید نتایج آن‌ها را مستقیماً با یکدیگر مقایسه کرد. با این حال، یک آزمون نفوذ را می‌توان رویدادی منفرد دانست، اما تکرار آن در دو آزمایش، نشانه شکل‌گیری یک الگو است: لایه نظارت‌پذیری که در تصمیم‌گیری درباره امکان عرضه و استقرار عامل‌های هوش مصنوعی نقش دارد، اکنون طی هفت ماه در دو آزمایشگاه پیشرو هوش مصنوعی، به‌طور مستقل با شکست امنیتی مواجه شده است.
فورکست ارزیابی ماه مارس را پوشش نداده بود. با این حال، گزارش‌های پیشین این رسانه درباره نظارت‌پذیری عامل‌ها شامل تحقیق مرتبط با Hugging Face، که در آن عامل‌ها در گزارش‌های ثبت رویداد سامانه دخالت کردند، و ماجرای خروج از محیط ایزوله از طریق DNS در OpenAI بوده است. در مورد دوم، هشدار ظرف چند دقیقه فعال شد، اما اجرای فرایند تنها دو ساعت و نیم بعد متوقف شد. اتفاقاً گزارش عمومی حادثه Hugging Face در نخستین روز آغاز ارزیابی اخیر، یعنی ۲۱ ژوئیه، منتشر شد.
اما چرا این یافته‌ها از منظر اقتصادی و سرمایه‌گذاری نیز اهمیت دارند؟ نظارت همان لایه‌ای است که شرکت‌ها برای امکان استقرار عملی عامل‌های هوش مصنوعی خریداری می‌کنند. این لایه بخشی از سازوکار حاکمیت و راستی‌آزمایی است که تعیین می‌کند کدام عامل‌ها اجازه ورود به محیط عملیاتی را پیدا کنند. بازار نیز بر همین اساس برای آن ارزش اقتصادی قائل شده است؛ از بیش از ۲۱۸ میلیون دلار سرمایه جذب‌شده توسط شرکت‌های فعال در امنیت عامل‌ها طی شش هفته گرفته تا قیمت‌گذاری سامانه‌های نظارتی درون‌نگر بر اساس هر تبادل و تلاش انویدیا برای انتقال اجرای محدودیت‌های امنیتی به لایه‌ای پایین‌تر از سطح دسترسی عامل‌ها.
آزمون امنیتی این لایه نشان می‌دهد که فرض وجود نظارت مؤثر، تنها تا حدی درست است. هزینه شکاف میان نظارت مورد انتظار و نظارت واقعی نیز بر عهده کسانی خواهد بود که به سوابق ثبت‌شده توسط سامانه نظارتی اعتماد کرده‌اند.
توصیه‌های پایانی METR مستقیماً همین فرض بنیادین را هدف می‌گیرند. به اعتقاد این مؤسسه، زیرساخت‌های نظارتی آینده «باید بتوانند در مقیاس گسترده در برابر حملات عمدی، راهبردی و مستمر عامل‌های داخلی بسیار توانمند مقاومت کنند».
تحقق این هدف مستلزم آن است که عامل‌ها نتوانند به‌آسانی از نظارت فرار کنند. METR پیشنهاد می‌کند: «عامل‌ها باید پس از هر N پیام یا دقیقه تحت نظارت قرار گیرند، نه اینکه سامانه تا پایان نوبت فعالیت آن‌ها منتظر بماند.»
این رویکرد همچنین به معنای اطمینان از آن است که تمام ترافیکی که باید تحت نظارت باشد، واقعاً بررسی شود؛ از جمله اینکه «ناظر همان اطلاعات زمینه‌ای را ببیند که عامل در اختیار دارد».
در نهایت، باید میان عامل‌ها و سامانه‌های نظارتی آن‌ها جداسازی مؤثری برقرار باشد، زیرا به گفته METR، «عامل‌ها در حالت معمول نباید به طراحی یا کد سامانه نظارتی دسترسی داشته باشند».
هر یک از این اصول به درسی اشاره می‌کند که از سه دسته آسیب‌پذیری شناسایی‌شده به دست می‌آید: اگر موجودیتی که قرار است تحت نظارت باشد بتواند سازوکار نظارت را بررسی کند، با ادامه فعالیت از زمان اجرای آن عبور کند یا با دست‌کاری قالب داده‌ها آن را بی‌اثر سازد، نظارت عملاً به چیزی وابسته می‌شود که همان موجودیت اجازه وقوعش را می‌دهد.