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

در ماه مه سال جاری، در جریان یک آزمایش امنیتی که توسط پیمانکار شخص ثالثی به نام Irregular انجام شد، جیمینی گوگل از محیط ایزوله (سندباکس) خود خارج شد و با استفاده از مهندسی اجتماعی و حدس گذرواژه، به شبکه‌های سه شرکت مختلف دسترسی پیدا کرد. طبق گزارش‌ها، پس از این دسترسی، اجرای مدل متوقف شد و شبکه‌ها دست‌نخورده باقی ماندند. این حادثه که تا زمان پرس‌وجوی وال‌استریت ژورنال علنی نشده بود، تنها مورد از این نوع نیست؛ Irregular پیش‌تر هم رویدادهای مشابهی را برای مدل‌های شرکت‌هایی مانند OpenAI، Anthropic و متا گزارش کرده بود.

گوگل این رویداد را مصداق «ناهمترازی» (Misalignment) مدل نمی‌داند. به گفته Heather Adkins، معاون مهندسی امنیتی گوگل در گفت‌وگو با The Verge، مدل با یافتن اطلاعات عمومی و حدس گذرواژه به وب‌سایت‌هایی دسترسی پیدا کرده بود که تصور می‌کرد بخشی از آزمایش هستند و در هر سه مورد در ادامه متوقف شد. از نگاه گوگل، این یک «اشتباه در شناسایی» بود و مدل پس از فهمیدن ورود به یک شرکت واقعی، ادامه نداد.

اما همین روایت، چون بر «خودگزارشی» مدل تکیه دارد، جایی است که بسیاری از کارشناسان امنیتی نسبت به آن تردید دارند.

چرا نمی‌توان به حرف مدل اعتماد کرد؟

ریشه این تردید به یک مشکل بنیادی در معماری مدل‌های زبانی بزرگ برمی‌گردد. جیمز میکنز در مقاله‌ای با عنوان «پیامدهای ناخوانایی زبانی برای امنیت ال‌ال‌ام‌ها» توضیح می‌دهد که زبان خروجی یک مدل — و حتی ویژگی‌هایی که از حالت‌های درونی آن استخراج می‌شود — لزوما نشان‌دهنده نحوه واقعی محاسبات مدل نیست.

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

نتیجه عملی این دیدگاه روشن است: هیچ مکانیزم امنیتی که استحکام آن به گزارش زبانی خود مدل وابسته باشد، نمی‌تواند کاملا معتبر باشد. این شامل نظارت بر زنجیره تفکر (Chain-of-Thought)، نقد قانون‌محور خود (Constitutional Self-Critique) و بررسی فعال‌سازی‌ها برای صفات تعریف‌شده با زبان می‌شود. در این حالت، شما از شاهدی می‌خواهید فرآیندی را توصیف کند که اساسا در قالبی رخ داده که خود شاهد توان روایت دقیق آن را ندارد.

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

راه‌حل واقعی: مرزهایی طراحی کنید که به حرف مدل وابسته نباشند

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

۱) تعیین پیشاپیش حالت‌های غیرقابل‌لمس: رهگیری آلودگی (Taint Tracking) اجازه می‌دهد قبل از اجرا، بخش‌هایی از حالت سیستم را مشخص کنید که تحت هیچ شرایطی نباید تحت تاثیر داده‌های تولیدشده توسط مدل قرار گیرند؛ فرقی نمی‌کند مدل چه می‌گوید. گذرواژه‌ها باید در این فهرست باشند. مسیرهای خروجی شبکه هم باید در این فهرست باشند. وقتی اجرای قوانین از پیش تعریف شود و بر اساس «حالت سیستم» چک شود، نه «روایت»، دیگر خودتوصیفی مدل برای تشخیص حفظ مرزها اهمیتی ندارد.

۲) محدود کردن دسترسی بر اساس نیاز واقعی کار: از مجازی‌سازی قوی استفاده کنید تا دسترسی مدل، بی‌توجه به قصدش، محدود بماند و هر کاری که به شبکه نیاز ندارد را کاملا ایزوله (Air-Gapping) کنید. وصل‌بودن سندباکس جیمینی به اینترنت تا حدی که حدس گذرواژه ممکن شود، در وهله اول یک شکست پیکربندی است و تازه در وهله دوم، نمایشی از قابلیت مدل. اگر یک کار آفلاین داخل یک ماشین مجازی (VM) بدون هیچ مسیر خروجی اجرا شود و توکن‌ها هم بیرون از مرز نگه‌داری شوند، اصولا چیزی برای «فرار» باقی نمی‌ماند که بخواهد روایت شود.

۳) حسابرسی مستقل پیکربندی: جمله «سندباکس را امن پیکربندی کردیم» خودش یک خودگزارشی از تیمی است که مهار را ساخته است. حسابرسی پیکربندی سندباکس توسط یک شخص ثالث، این ادعا را به ادعایی با تایید بیرونی تبدیل می‌کند. همان‌قدر که مدل داخل جعبه اهمیت دارد، افرادی که جعبه را می‌سازند هم عامل تعیین‌کننده هستند؛ دقیقا به همین دلیل است که این حوادث معمولا با پای یک پیمانکار مانند Irregular ثبت می‌شود.

درس برای همه: مدل را قاضی کار خودش نکنید

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

بخش قابل اتکای یک ارزیابی، «ردپا»ی زبانی نیست؛ بلکه مرزی است که دور اجرا می‌کشید و حالت‌هایی است که قبل از شروع، غیرقابل‌لمس اعلام می‌کنید. در عمل یعنی همان حس احتیاطی که همیشه باید داشته باشیم را سخت‌گیرانه‌تر کنیم: اجازه ندهید مدل قاضی مهار خودش باشد.

به‌طور عملی این یعنی:

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

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