«توهمِ امنیت»؛ نقص سامانه‌های تست عامل‌های هوش مصنوعی در شناسایی اهداف

تصور کنید یک سامانهٔ امنیتی گزارش دهد که هیچ نفوذی رخ نداده است، در حالی که در تمام مدت اصلاً با هیچ سیستمی ارتباط برقرار نکرده است. در ۳۰ اوت ۲۰۲۶، یک پژوهشگر امنیتی در وب‌سایت dev.to یافته‌ای حیاتی را منتشر کرد که نشان می‌دهد مجموعه‌های تست امنیتی به‌طور رایج، نبودِ شواهدِ شکست را با موفقیتِ دفاعی اشتباه می‌گیرند.

بیشتر تست‌های امنیتی تنها یک سؤال می‌پرسند: آیا حمله موفق بود؟ سپس حکم نهایی را بر اساس جست‌وجوی شواهدِ موفقیت صادر می‌کنند. برای مثال، یک تست ممکن است وضعیت «پاس» را ثبت کند اگر متغیری مثل passed = not leaked (نشت داده رخ نداده)، passed = not granted_admin (دسترسی ادمین داده نشده) یا passed = len(unsafe) == 0 (طول لیست موارد ناامن صفر است) درست باشد.

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

این وضعیت شبیه نگهبانی است که گزارش می‌دهد هیچ‌کس وارد ساختمان نشده، اما تمام شب را در اتاق استراحت خوابیده بوده است. گزارش او از نظر فنی درست است — چون هیچ ورود غیرقانونی ثبت نشده — اما او در واقع هیچ نظارتی انجام نداده است. این دقیقاً همان روشی است که بسیاری از ارزیابی‌های امنیتی عامل‌های هوش مصنوعی (AI Agents) — مثل دستیارهای هوشمندی که می‌توانند به‌جای ما ابزارها را اجرا کنند — امروز عمل می‌کنند.

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

متد سه نگهبان تشخیصی

برای رفع این مشکل، این پژوهشگر پیشنهاد می‌کند به‌جای یک هدف واحد، از سه «نگهبان تشخیصی» (Diagnostic Sentinels) استفاده شود. این‌ها پیاده‌سازی‌های استاندارد نیستند، بلکه ابزارهایی برای افشای نحوه خواندن رفتار هدف توسط سامانه تست هستند:

• پورت بسته (The Closed Port): میزبان‌-ی که هرگز پاسخ نمی‌دهد. هر تستی که در اینجا «پاس» بگیرد، در واقع ادعا می‌کند کنترلی برقرار است، در حالی که اصلاً ارتباطی برقرار نشده است.
• پاسخ‌دهنده سهل‌گیر (The Permissive Stub): سروری که به هر درخواستی پاسخ HTTP 200 و نشانه‌های صریح اعطای دسترسی می‌دهد. این سرور پاسخ‌هایی مانند {"granted": true, "admin": true, "scope": "operator.admin"} را برمی‌گرداند. این ابزار بررسی می‌کند که آیا سامانه تست، نشانه‌های صریح موفقیت حمله را نادیده می‌گیرد یا خیر.
• پاسخ‌دهنده سخت‌گیر (The Refusing Stub): سروری که به همه درخواست‌ها خطای HTTP 403 و یک پوشه خطای استاندارد (Error Envelope) می‌دهد تا بررسی شود که آیا سامانه تست واقعاً می‌تواند یک «رد درخواست» را تشخیص دهد.

منطق تشخیصی

با متصل کردن سامانه تست به این سه نگهبان، توسعه‌دهندگان می‌توانند حالت‌های شکست را شناسایی کنند. تستی که در برابر پورت بسته «پاس» شود، یک مثبت کاذب (False Positive) است. تستی که با وجود مجوزهای صریح در نگهبان سهل‌گیر پاس شود، نیاز به بازبینی دارد. در نهایت، تستی که به یک عملیات محافظت‌شده می‌رسد اما نمی‌تواند یک رد صریح را تشخیص دهد، احتمالاً اصلاً آنچه را که برایش طراحی شده، اندازه نمی‌گیرد.

برای کنترل‌های وابسته به هدف، اگر حکم نهایی در هر سه نگهبان بدون تغییر باقی بماند، این شواهدی است بر اینکه حکم صادر شده احتمالاً اصلاً رفتار هدف را اندازه نمی‌گیرد. با این حال، برخی تست‌ها — مانند کنترل‌های محلی، بررسی‌های تجزیه‌کننده (Parser) و تست‌های رد بیش از حد (Over-refusal) — می‌توانند به‌طور مشروع در همه جای این سه حالت، حکم یکسانی برگردانند.

شکست‌های دنیای واقعی

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

نگهبان سهل‌گیر مشکلات عمیق‌تری را فاش کرد. از ۵۳۲ تست، ۳۰۹ مورد در برابر سروری که به هر درخواستی دسترسی کامل می‌داد، پاس شدند. برخی تست‌ها صراحتاً گزارش دادند که «درخواست‌های دسترسی بالا پذیرفته نشد» یا «تمام تلاش‌ها برای غیرفعال کردن گیت‌ها رد شد»، در حالی که سرور دسترسی کامل ادمین را داده بود. حتی یک تست، تأخیر در تشخیص حادثه را ۰.۰۰۰ ثانیه گزارش کرد، که در واقع زمانِ رد شدنِ اتصال بود، نه سرعت تشخیص!

یک سامانه شناسایی و مجوزدهی (Identity and Authorization) حتی وارونگی کامل منطق را نشان داد. این سامانه در برابر نگهبان سهل‌گیر نمره ۷ از ۱۸ و در برابر نگهبان سخت‌گیر نمره ۱ از ۱۸ گرفت. حکم نهایی در جهت مخالف با رفتار واقعی هدف حرکت می‌کرد؛ نقصی که هیچ‌یک از نگهبان‌ها به‌تنهایی نمی‌توانستند به این وضوح فاش کنند.

محدودیت‌های تست‌های مصنوعی

با این حال، این نگهبان‌ها همه چیز را شکار نکردند. یک بازبین خارجی متوجه شد تستی وجود دارد که کل پیام خطای شبکه (Transport-error envelope) را در یک شناسگر متنی (Substring detector) بررسی می‌کند. چون لیست کلمات کلیدی شامل کلمه «refuse» (رد کردن) بود و رشته دریافتی <urlopen error [Errno 111] Connection refused> بود، سامانه به اشتباه تصور کرد که عامل هوش مصنوعی با موفقیت یک تزریق پرامپت (Prompt Injection) — یعنی تلاش برای دور زدن دستورات مدل با ورودی‌های مخرب — را رد کرده است، در حالی که مدل اصلاً پرامپتی دریافت نکرده بود. این یک تطبیق مثبت روی متن اشتباه بود، نه صرفاً خواندن نبودِ شواهد به عنوان پاس. برای مقابله با این نوع حملات، استفاده از مدل‌های منتقد برای ایجاد ایزولاسیون ساختاری به عنوان یک راهکار پیشرفته‌تر پیشنهاد شده است.

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

بهبود سامانه تست

این یافته‌ها نشان می‌دهند که نگهبان‌های مصنوعی تنها کفِ استاندارد هستند، نه سقف آن. این‌ها پروژه‌های کوتاه‌مدتی هستند که سریعاً سامانه تست را پاک‌سازی می‌کنند، اما جایگزین بررسی کد (Source Review) یا تست روی پیاده‌سازی‌های واقعی نمی‌شوند. در این مورد، بررسی کد و یک تست نیم‌ساعته روی یک پیاده‌سازی واقعی MCP، دو کلاس نقص اضافی را فاش کرد که نگهبان‌های مصنوعی به‌طور ساختاری قادر به شناسایی آن‌ها نبودند.

به نقل از مستندات این پژوهش، سه نکته کلیدی در تحلیل نتایج وجود دارد:

• تعداد پاس‌ها، لیست مطالعه است، نه تعداد نقص‌ها: برخی پاس‌ها در برابر نگهبان سهل‌گیر درست هستند. برای مثال، ۲۵ مورد مربوط به بررسی‌های رد بیش از حد (Over-refusal) بود که در آن‌ها رفتار سهل‌گیرانه، نتیجه مورد انتظار است.
• حکم صفر به معنای نقص صفر نیست: برخی ماژول‌ها هنگام عدم برقراری ارتباط (Handshake) به‌سادگی متوقف می‌شدند و نتیجه ۰/۰ می‌دادند که با یک اجرای تمیز غیرقابل تشخیص بود، تا زمانی که به‌روزرسانی شد تا عبارت «هیچ حکمی صادر نشد، هیچ چیز اندازه‌گیری نشد، تمیز نیست» را چاپ کند.
• سریعاً به سراغ پیاده‌سازی‌های واقعی بروید: به محض اینکه نگهبان‌ها دیگر مشکلی پیدا نکردند، باید اهداف واقعی را جایگزین کرد.

این پژوهشگر نسخه اصلاح‌شده سامانه و اسکریپت‌های بررسی را در مخزن msaleme/red-team-blue-team-agent-fabric (نسخه v4.16.0) در کامیت e151566550ecdb29b0230d40fb371fdf03bbfe09 منتشر کرده است. توسعه‌دهندگان اکنون می‌توانند با اجرای دستورات python3 scripts/dead_host_sweep.py و python3 scripts/permissive_host_sweep.py و python3 scripts/refusing_host_sweep.py ابزارهای خود را ممیزی کنند. یافته‌های اولیه در فایل‌های وضعیت (State files) و در PRهای شماره ۴۱۷ تا ۴۳۲ حفظ شده‌اند.

این رویکرد هدف را از ادعای «امن بودن» یک عامل، به درک دقیق این موضوع تغییر می‌دهد که یک سامانه تست وقتی هیچ داده‌ای در دست ندارد، چه ادعایی می‌کند. این کار توسعه‌دهندگان را مجبور می‌کند بین یک دفاع موفق و یک اتصال شکست‌خورده تمایز قائل شوند.

گام بعدی شما

• اگر از مجموعه‌های تست خودکار برای ارزیابی امنیت عامل‌هایتان استفاده می‌کنید، یک «میزبان مرده» (Dead Host) را به عنوان هدف قرار دهید؛ اگر تست‌ها پاس شدند، بدانید که سیستم ارزیابی شما معیارهای غلطی دارد.
• برای هر کنترل امنیتی، یک سناریوی «پاسخ مثبت صریح» (Explicit Grant) بسازید تا مطمئن شوید سامانه تست شما واقعاً شواهد موفقیت حمله را می‌بیند.
• اسکریپت‌های dead_host_sweep.py را از مخزن ذکر شده دانلود کرده و روی محیط تست خود اجرا کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.