تصور کنید یک ابزار امنیتی به شما گزارش دهد که به سیستم نفوذ کرده است، اما در واقع فقط یک متن تصادفی را به اشتباه «موفقیت» خوانده باشد. برای جلوگیری از این فاجعه، توسعه‌دهنده پروژه HALO (یک عامل نفوذ خودکار محلی) مکانیزمی را طراحی کرد که در آن مدل نمی‌تواند «برگه امتحانی خودش را تصحیح کند».
به نقل از گزارش‌های فنی این پروژه، این عامل در بازه ۱۱ تا ۱۷ اوت ۲۰۲۶ توانست سه دسترسی Root (دسترسی مدیریت ارشد) را روی یک ماشین مجازی Metasploitable به دست آورد. نکته کلیدی اینجا نفوذ نیست، بلکه سیستمی است که اجازه نمی‌دهد هوش مصنوعی درباره موفقیت‌هایش دروغ بگوید.
زمینه پروژه
در ادامه پوشش‌های قبلی ما درباره اینکه سازندگانی مانند «هنک گرین» چگونه با وابستگی‌های هوش مصنوعی دست و پنجه نرم می‌کنند، پروژه HALO بر مفهوم مالکیت محلی تأکید دارد. توسعه‌دهنده این پروژه تقریباً شش ماه است که به طور خودآموز برنامه‌نویسی می‌آموزد و در حال ساخت سیستمی است که برای شکار باگ در اهدافی طراحی شده که «بسته‌بندی شده و آماده» (Gift-wrapped) نیستند.
برای دستیابی به این هدف، توسعه‌دهنده یک مدل استدلالی کوچک را روی سخت‌افزار خصوصی اجرا می‌کند. این معماری باعث می‌شود وابستگی به APIهای ابری و هزینه‌های سالانه ۴۷۵ دلاری اشتراک اسکنرهای تجاری حذف شود. هدف نهایی، ایجاد عاملی است که تحت مالکیت شخصی باشد و بتواند از «باکس‌های آسان» فراتر رفته و آسیب‌پذیری‌های عمیق‌تری را پیدا کند.
مکانیزم تأیید Nonce
برای حذف توهم (Hallucination) — یعنی وقتی مدل با اطمینان چیزی می‌گوید که وجود ندارد، مثل دوستی که خاطره‌ای را اشتباه تعریف می‌کند — توسعه‌دهنده از سیستم «رسید Nonce» استفاده کرد. این رویکرد پاسخی عملی به چالش دقت ساختگی در عامل‌های هوش مصنوعی است که اغلب نتایجی متقاعدکننده اما غلط تولید می‌کنند. در این روش، ارکستراتور برای هر تلاش نفوذ، یک رشته متنی تصادفی و منحصر‌به‌فرد (Nonce) تولید می‌کند. تنها راهی که عامل می‌تواند ادعای پیروزی کند، بازگرداندن دقیق همین رشته از داخل شل (Shell) هدف است.
این یعنی مدل نمی‌تواند با دیدن کلمه «root» در یک بنر ساده یا بر اساس نتایج توهم‌زده، ادعای موفقیت کند؛ او باید «رسیدی» ارائه دهد که توسط سیستمی خارج از خودش صادر شده است. در لاگ‌های سیستم، یک موفقیت واقعی به این شکل ثبت می‌شود:HALO-EVIDENCE nonce=1a837238e19fc8fb56014af0 level=shell uid=0 user=root host=metasploitable root@metasploitable:/#
جزئیات عملکرد
بر اساس بررسی نتایج تست‌ها روی ماشین مجازی Metasploitable، عملکرد عامل در دو حالت متضاد ظاهر شد:
- موفقیت تأییدشده: عامل با استفاده از سه اکسپلویت منتخب (Curated)، دسترسی Root را گرفت و Nonce مربوطه را به عنوان «رسید» نفوذ ارائه داد.
- شکست صادقانه: عامل ۲۰ پورت باز دیگر را با استفاده از خط لوله Metasploit مورد حمله قرار داد و به حدود ۲,۰۰۰ ماژول اکسپلویت موجود دسترسی داشت، اما در تک‌تک آن‌ها شکست خورد.
لاگ‌های فنی دلایل متعددی را برای این شکست‌ها فاش کردند:
- عدم تطابق نسخه: عامل یک اکسپلویت مخصوص Apache 2.4.49 را به سروری با نسخه Apache 2.2.8 شلیک کرد؛ صرفاً چون نام‌ها مشابه بودند، با وجود تفاوت در نسخه‌ها.
- خطاهای Payload: در سناریوهایی که یک Command Shell ساده و قابل‌اعتماد‌تر بود، مدل Payloadهای سنگین و مرحله‌بندی شده (Staged) را انتخاب کرد.
- کمبود اعتبارنامه‌ها: عامل تلاش کرد اکسپلویت‌های MySQL را اجرا کند که نیازمند اعتبارنامه‌هایی (Credentials) بودند که عامل آن‌ها را در اختیار نداشت.
به دلیل وجود گیت Nonce، سیستم اجازه نداد این شکست‌ها به عنوان موفقیت گزارش شوند و به جای ارائه اعداد متورم و دروغین، لیستی صادقانه از شکست‌ها را ارائه کرد. این لایه تأیید، مشابه استفاده از فایل‌های تله برای سنجش واقعی نفوذ عمل می‌کند تا هرگونه دسترسی غیرمجاز با داده‌های واقعی اثبات شود.
شکست در «اصلاح سرعت»
یک تلاش اولیه برای افزایش سرعت عامل از طریق محدود کردن توکن‌های خروجی، تقریباً کل سیستم را از کار انداخت. فراخوانی‌های مدل حدود ۹۰ ثانیه زمان می‌برد و توسعه‌دهنده سعی کرد توکن‌ها را محدود کند تا جلوی «پرگویی» مدل را بگیرد.
این کار باعث شد اجراها سریع‌تر شوند، اما نتایج به طور کامل شکست خوردند. عامل پورت‌های باز را پیدا می‌کرد و سپس به سادگی تسلیم می‌شد. با بررسی لاگ‌ها، توسعه‌دهنده متوجه شد که مدل استدلالی حدود ۱,۲۰۰ توکن را در یک کانال پنهان «تفکر» (Thinking Channel) مصرف می‌کند، پیش از آنکه حتی یک توکن از پاسخ واقعی را تولید کند.
با تنظیم سقف توکن‌ها پایین‌تر از این بودجه تفکر، توسعه‌دهنده در واقع منطق مدل را «سر برید». مدل در میانه تفکر به سقف توکن‌ها می‌رسید و یک رشته خالی برمی‌گرداند. این موضوع نشان داد که کندی مدل، در واقع کفِ سخت‌افزاری بود و هیچ اهرمی برای «اصلاح سرعت» وجود نداشت.
این تغییر رویکرد به سمت هوش مصنوعی «مبتنی بر رسید»، نقطه عطفی در فاصله گرفتن از گزارش‌های خوداظهاری مدل‌هاست. در حوزه امنیت خودکار، ابزاری که پوشش عملیاتی را توهم می‌زند، خطرناک‌تر از ابزاری است که صرفاً شکست می‌خورد. با مجبور کردن هوش مصنوعی به اثبات ادعاهایش با داده‌های غیرقابل جعل، توسعه‌دهنده یک حلقه بازخورد قابل اعتماد برای بهبودهای آینده ایجاد کرده است. این رویکرد در واقع نوعی کنترل دسترسی سخت‌گیرانه است که مانع از رفتارهای پیش‌بینی‌نشده و خطرناک عامل در محیط عملیاتی می‌شود.
برای کسانی که در حال ساخت عامل‌های هوشمند هستند، این تجربه نشان می‌دهد که مرز بعدی، تنها بهبود پرامپت‌ها نیست، بلکه ایجاد لایه‌های تأیید خارجی است. هدف، حرکت از توسعه «مبتنی بر حس» (Vibes-based) به سیستمی است که در آن هوش مصنوعی نتواند نتیجه‌ای را ادعا کند که در واقعیت به دست نیاورده است.
منتظر نسخه‌های بعدی HALO باشید، زیرا توسعه‌دهنده در حال اصلاح خط لوله نشست‌های Metasploit است تا نرخ موفقیت اکسپلویت‌های غیرمنتخب را افزایش دهد.
برای کسانی که در حال ساخت عامل‌های هوشمند هستند، این تجربه نشان می‌دهد که مرز بعدی، تنها بهبود پرامپت‌ها نیست، بلکه ایجاد لایه‌های تأیید خارجی است. هدف، حرکت از توسعه «مبتنی بر حس» (Vibes-based) به سیستمی است که در آن هوش مصنوعی نتواند نتیجه‌ای را ادعا کند که در واقعیت به دست نیاورده است.
منتظر نسخه‌های بعدی HALO باشید، زیرا توسعه‌دهنده در حال اصلاح خط لوله نشست‌های Metasploit است تا نرخ موفقیت اکسپلویت‌های غیرمنتخب را افزایش دهد.
گام بعدی شما
- اگر در حال ساخت عامل‌های هوشمند هستید، به جای بهبود پرامپت، لایه‌های تأیید خارجی (External Verification) را اضافه کنید.
- برای مدل‌های استدلالی، بودجه توکن‌های پنهان (Thinking Budget) را پیش‌بینی کنید تا منطق مدل قطع نشود.
- از متدهای «اثبات مالکیت» برای هر خروجی حساس در محیط‌های عملیاتی استفاده کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.
گفتگو