ماجرای فرار هوش مصنوعی آدرس غلط است؛ مقصر اصلی سندباکس‌های سست و ناامن هستند!

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

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

اما این ایده که «هوش مصنوعی از زندان فرار کرده» در واقع یک آدرس غلط است! اگر یک سندباکس ضعیف و سرهم‌بندی‌شده باشد — که متأسفانه خیلی از آن‌ها همین‌طورند — فرار کردن از آن کار سختی نیست. این محیط‌ها معمولاً فاقد لایه‌های امنیتی سفت‌وسخت در سطح شبکه، مثل کنترل دسترسی دقیق و تفکیک مجوزها هستند. اگر یک سندباکس با پیکربندی درست و اصولی پیاده‌سازی شده بود، این ماجرا می‌توانست به شکلی کاملاً متفاوت رقم بخورد.

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

مروری کوتاه بر وضعیت استانداردهای امنیتی

واقعیت این است که در حال حاضر تقریباً هیچ سندی درباره امنیت ایجنت‌ها وجود ندارد که مشخصاً یک استاندارد امتیازدهی برای معماری مهار و ایزوله‌سازی سندباکس‌ها ارائه کرده باشد.

فهرست ۱۰ تهدید برتر ایجنت‌های هوش مصنوعی (OWASP Agentic AI Top 10) و برگه‌های راهنمای امنیت ایجنت، تهدیدها و روش‌های مقابله را فقط در سطحی کلان دسته‌بندی کرده‌اند؛ یعنی به عنوان چک‌لیست کاربردی هستند، اما خروجی قابل مقایسه‌ای ارائه نمی‌دهند. چارچوب مدیریت ریسک هوش مصنوعی مؤسسه NIST هم کاملاً یک پله بالا‌تر عمل می‌کند و بیش‌تر به حاکمیت سازمانی ریسک می‌پردازد تا یک خط‌کش فنی برای سنجش مرزهای محیط اجرا.

پروژه MITRE ATLAS نیز تکنیک‌های تهاجمی علیه سیستم‌های هوش مصنوعی را فهرست می‌کند که بیش‌تر شبیه به یک کتابخانه از تهدیدات است تا یک معیار مهارکننده. اتحادیه امنیت ابری (Cloud Security Alliance) هم چندین تلاش موازی دارد؛ از جمله مدل MAESTRO، ماتریس کنترل‌های هوش مصنوعی، و چارچوب اعتماد به ایجنت‌ها که استقلال آن‌ها را در چهار سطح از «کارآموز» تا «مدیر ارشد» ارزیابی می‌کند. این مدل شاید نزدیک‌ترین تلاش برای سنجش میزان استقلال ایجنت بدون دخالت انسان باشد، اما کل ابعاد سندباکس را پوشش نمی‌دهد.

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

بنابراین باید نگاهی عمیق‌تر به ماجرا بیندازیم.

رده‌بندی تخصصی سندباکس ایجنت‌ها: فرمول ۳-۷-۷

این متدولوژی و رده‌بندی جدید که در مارس ۲۰۲۶ منتشر شده و هنوز در حال بررسی توسط متخصصان جامعه متن‌باز است، حول یک فرمول جذاب به نام «۳-۷-۷» شکل گرفته است: هفت لایه دفاعی، هفت دسته تهدید، و سه بعد ارزیابی. شماره‌گذاری این لایه‌ها از پایین به بالاست، چون لایه‌های پایینی نقش پی و فونداسیون سیستم را بازی می‌کنند:

• لایه اول (L1) - ایزوله‌سازی پردازش (Compute Isolation): چه چیزی اجرای ایجنت را از سیستم میزبان جدا می‌کند؟

• لایه دوم (L2) - محدودیت منابع (Resource Limits): آیا ایجنت می‌تواند پردازنده (CPU)، حافظه رم، فضای دیسک یا زمان سیستم را ببلعد؟

• لایه سوم (L3) - مرز فایل‌سیستم (Filesystem Boundary): ایجنت مجاز است چه فایل‌هایی را بخواند، بنویسد یا پاک کند؟

• لایه چهارم (L4) - مرز شبکه (Network Boundary): ایجنت اجازه برقراری ارتباط با چه مقصدهایی را دارد؟

• لایه پنجم (L5) - مدیریت رمزها و اعتبارسنجی (Credential Management): آیا می‌تواند کلیدها و رمزهای عبور را ببیند، از آن‌ها استفاده کند یا به سرقت ببرد؟

• لایه ششم (L6) - حاکمیت عملیات (Action Governance): آیا ایجنت می‌تواند عملیات مخرب یا بدون مجوز انجام دهد؟

• لایه هفتم (L7) - پایش و ثبت وقایع (Observability and Audit): آیا می‌توانید ببینید که ایجنت دقیقاً چه کاری، در چه زمانی و با چه دلیلی انجام داده است؟

هر یک از این لایه‌ها بر اساس دو شاخص سنجیده می‌شوند: «قدرت» (از ۰ تا ۴) و «سطح تفکیک و جزئیات» (از ۰ تا ۳). در کنار این‌ها، برچسب‌های قابلیت حمل نیز برای وابستگی به سیستم‌عامل و زیرساخت در نظر گرفته شده است. در این میان، مقیاس سنجش قدرت جذاب‌ترین بخش ماجراست:

نمره ۰ یعنی هیچ کنترلی در کار نیست. نمره ۱ به معنای کنترل مشارکتی یا اختیاری است؛ یعنی پروسه درون سندباکس می‌تواند محدودیت‌ها را به راحتی دور بزند یا نادیده بگیرد (مثل متغیرهای محیطی پروکسی). نمره ۲ کنترل نرم‌افزاری است؛ جایی که خود برنامه نمی‌تواند آن را درون سیستم دور بزند، اما یک اپراتور امکان تغییر پیکربندی‌اش را دارد. نمره ۳ کنترل در سطح کرنل (Kernel) است که پس از اعمال، غیرقابل بازگشت خواهد بود (مثل قابلیت‌های لینوکسی نظیر Namespaces، Landlock و seccomp-BPF). نمره ۴ نیز سطح ساختاری است؛ یعنی منبع محافظت‌شده اصلاً در داخل سندباکس وجود خارجی ندارد؛ مثل استفاده از ماشین‌های مجازی کوچک (MicroVM)، پروکسی توکن‌ها یا عدم وجود هرگونه کارت شبکه.

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

این یعنی مسائلی مثل نشت و سرقت داده‌ها، دیگر بر اساس حدس و گمان قضاوت نمی‌شوند، بلکه به یک آزمون مکانیکی تبدیل می‌شوند: آیا لایه‌های ۳، ۴ و ۵ همگی نمره ۲ یا بالا‌تر را دریافت کرده‌اند یا خیر؟ نکته حیاتی دیگر این است که این متدولوژی با یک «چارچوب ترکیبی» عرضه شده است. هیچ محصولی به تنهایی نمی‌تواند هر هفت لایه را به شکل بی‌نقص پوشش دهد؛ بنابراین راهکار عملی این است که ابزار‌های مختلف را روی هم سوار کنید و بالا‌ترین امتیاز هر لایه را در نظر بگیرید، نه اینکه وانمود کنید یک ابزار جادویی همه مشکلات را حل می‌کند.

این پروژه تاکنون ۲۶ محصول واقعی را ارزیابی و امتیازدهی کرده و همراه با یک ابزار سنجش خودکار (Probe) ارائه شده است که می‌توانید با اجرای آن روی سندباکس خود، درستی ادعاها را بسنجید. همچنین یک اکسپلورر تعاملی برای مقایسه اثر انگشت ابزار‌ها در کنار هم در دسترس قرار گرفته است.

نقاط قوت و حلقه‌های گمشده

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

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

با این حال، دو نقطه کور و حلقه گمشده در این سیستم به چشم می‌خورد. اولی این است که هیچ لایه‌ای برای مدیریت وضعیت «پس از شکست ایزوله‌سازی» در نظر گرفته نشده است؛ یعنی خبری از کلید قطع اضطراری (Kill Switch)، چرخش خودکار کلیدهای امنیتی به محض احساس خطر، یا راهنمای بازگردانی سیستم نیست. این مدل به شما می‌گوید که آیا یک ایجنت درون جعبه مهار می‌شود یا نه، اما نمی‌گوید اگر حصار شکست، در فاصله زمانی بعد از آن چه اتفاقی می‌افتد؛ و اتفاقاً ماجرای هاگینگ فیس دقیقاً در همین پنجره زمانی رخ داد!

ایده کلید قطع اضطراری (Kill Switch) در اصل ایده بسیار درستی است. ما حتماً باید ابزاری برای متوقف کردن مدل‌های پیشرو داشته باشیم؛ مدل‌هایی که ثابت کرده‌اند توانایی فرار و ایجاد خرابکاری را دارند. اما چالش بزرگ اینجاست: چه کسی باید این کلید را فعال کند و با چه سرعتی؟ کشف و ردیابی فنی این حمله برای دو مورد از پیشرفته‌ترین سازمان‌های جهان، یعنی OpenAI و Hugging Face، هفته‌ها طول کشید. اگر قرار بود یک نهاد نظارتی متمرکز بدون حضور نخبگان رده‌بالای هوش مصنوعی این کار را انجام دهد، ماجرا بسیار فرسایشی‌تر می‌شد.

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

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

نقطه کور دوم هم با همین موضوع مرتبط است. لایه هفتم (L7) فقط وجود لاگ‌ها و ضد دستکاری بودن آن‌ها را می‌سنجد، نه اینکه گزارش یک رفتار مشکوک با چه سرعتی به دست انسان می‌رسد. یک سیستم ممکن است نمره بالایی در L7 بگیرد اما روز‌ها طول بکشد تا مهندسان متوجه یک نفوذ شوند؛ اتفاقی که ظاهراً در ماجرای اخیر هم رخ داد. البته این دو نقطه کور به معنای نادیده گرفتن ارزش این پروژه نیست؛ این‌ها تصمیماتی منطقی برای نسخه اول (v1) به حساب می‌آیند، اما دقیقاً بخش‌هایی هستند که این استاندارد در مراحل بعدی باید آن‌ها را تکامل دهد.

کالبدشکافی ماجرای فرار اوپن‌ای‌آی با متر و معیارهای جدید

حالا وقت یک تمرین عملی است: آیا با تکیه بر اطلاعات و بیانیه‌های عمومی منتشرشده، می‌توان اثر انگشت امنیتی سندباکس آن آزمون را ثبت کرد؟ در بیش‌تر موارد، خیر! این نشان می‌دهد که انتشار مسئولانه اطلاعات امنیتی برای باگ‌های نرم‌افزاری (مثل کدهای CVE) جا افتاده است، اما برای فرار از سندباکس هوش مصنوعی هنوز به بلوغ نرسیده است.

ایزوله‌سازی پردازشی در گزارش‌ها تنها با عبارت مبهم «بسیار ایزوله» توصیف شده بود، بدون اینکه هیچ سازوکار فنی مشخصی برای آن نام برده شود. محدودیت منابع و مرزهای فایل‌سیستم هم اصلاً در گزارش عمومی توضیح داده نشده بودند. مرز شبکه شبیه به لایه با نمره ۲ به نظر می‌رسید و البته دوام نیاورد؛ یک گلوگاه پروکسی تنها خروجی مجاز سیستم بود و وجود یک آسیب‌پذیری روز-صفر در آن امکان اجرای کد را فراهم کرد؛ دقیقاً همان نقطه‌ضعفی که سطح ۲ درباره‌اش هشدار می‌دهد: سیستمی که نرم‌افزاری است اما در سطح کرنل قفل و غیرقابل بازگشت نشده است.

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

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

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

با این همه، تا زمان بلوغ کامل این استانداردها، هیچ تیمی نباید دست روی دست بگذارد. میزان ریسک‌پذیری خود را مشخص کنید، سیستم‌های نظارتی و کنترل‌های منطقی را در زیرساخت خود پیاده نمایید و حتماً برای کلید قطع اضطراری اختصاصی خود آماده باشید.

و در نهایت یک سؤال مهم: اگر قرار باشد سندباکس ایجنت شما در برابر این هفت لایه زیر ذره‌بین قرار بگیرد، چه نمره‌ای کسب می‌کند؟ امیدواریم حداقل کارنامه‌ای درخشان‌تر از سندباکس اوپن‌ای‌آی در این ماجرا ثبت کند!