رسیدهای «تأییدشده» در عامل‌های هوش مصنوعی ممکن است توخالی باشند

تصور کنید یک دفترخانه دیجیتال روی تمام اسناد شما مهر «تأیید شد» می‌زند، اما در واقع حتی یک خط از متن آن‌ها را نخوانده است. این دقیقاً همان شکاف امنیتی است که اکنون در قلب سیستم‌های عامل‌محور (Agentic) شناسایی شده است. مهر واقعی است و سند از زمان مهر خوردن تغییر نکرده است، اما محتوا همچنان اشتباه است. این دقیقاً همان روشی است که «اعتبارسنج‌های توخالی» در جریان‌های کاری هوش مصنوعی عمل می‌کنند.

به نقل از گزارش فنی منتشر شده در ۶ اکتبر ۲۰۲۶ توسط توسعه‌دهنده‌ای به نام sunnydachs، وضعیت «تأیید شده» در بسیاری از خط لوله‌های عامل‌های هوش مصنوعی صرفاً یک ادعای توخالی است. این تحلیل نشان می‌دهد که عامل‌ها می‌توانند گزارش موفقیت صادر کنند، در حالی که فرآیند بررسی واقعی به‌طور کامل حذف شده یا هرگز اجرا نشده است. این موضوع در واقع تکمیلی بر نقص‌های معماری کلیدهاست که پیش‌تر بررسی کردیم و امنیت رسیدهای AI را به شدت کاهش می‌دهد.

این شکست زمانی رخ می‌دهد که مسیر تحویل داده، به یک رسید (Receipt) اعتماد می‌کند بدون اینکه تأیید کند آیا یک شرط منطقی (Predicate) واقعی اجرا شده است یا خیر. این یک شکاف بحرانی در قابلیت اطمینان عامل‌هاست: سیستم تأیید می‌کند که داده‌ها از زمان بررسی تغییر نکرده‌اند، اما هرگز تأیید نمی‌کند که اصلاً بررسی‌ای صورت گرفته است.

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

مکانیزم «بررسی توخالی»

برای اثبات این آسیب‌پذیری، sunnydachs یک شبکه آزمایشی با استفاده از سه چارچوب محبوب Strands، LangGraph و CrewAI طراحی کرد. این ساختار شامل یک خط لوله ساده سه مرحله‌ای بود: «ساخت پیش‌نویس» (build_draft) $\rightarrow$ «تأیید پیش‌نویس» (verify_draft) $\rightarrow$ «تحویل پیش‌نویس» (deliver_draft). هر سه ابزار در این مسیر بدون آرگومان (Argument-free) بودند.

در این آزمایش از یک خروجی عمداً نادرست (Known-bad artifact) استفاده شد؛ پیش‌نویسی که از همان اولین بایت، تمام الزامات را نقض می‌کرد. اپلیکیشن پیش‌نویس را از یک فیلد یادداشت‌های وارد شده (Imported notes field) می‌ساخت، به این معنی که مقدار آن فقط شامل یادداشت‌ها بود. در حالی که شرط اعلام شده (Declared predicate) ایجاب می‌کرد که پیش‌نویس باید حاوی مقادیر متعلق به سرویس باشد و نباید حاوی مقادیر «فقط یادداشت‌ها» باشد.

با وجود این تضاد آشکار، اعتبارسنج‌های «پوسته» (Stub) در این آزمایش در ۱۰۰٪ دفعات، مقدار verified: true را بازگرداندند. طبق این گزارش، این یک باگ نادر یا عجیب نیست. این اتفاق زمانی می‌افتد که پیاده‌سازی یک اعتبارسنج فراموش می‌کند تابع شرط (Predicate) را فراخوانی کند، یا زمانی که یک شرط همیشه مقدار True را برمی‌گرداند، و یا وقتی یک پرچم تنظیمات (Config flag) بخش هزینه‌بر بررسی را نادیده می‌گیرد. در تمام این موارد، رسید صادر شده دقیقاً مشابه یک بررسی واقعی و فعال به نظر می‌رسد.

چرا متد Hash-Binding شکست می‌خورد؟

بسیاری از توسعه‌دهندگان برای تضمین امنیت به اتصال هش (Hash-binding) با الگوریتم sha256 تکیه می‌کنند. در این روش، اعتبارسنج یک هش از بایت‌های بررسی‌شده ثبت می‌کند و مسیر تحویل، هر چیزی را که هش متفاوتی داشته باشد رد می‌کند. این کار مانع از «تعویض خاموش» (Silent swap) می‌شود؛ وضعیتی که در آن یک پیش‌نویس تأیید می‌شود اما پیش‌نویس متفاوتی تحویل داده می‌شود.

اما این حسابرسی نشان داد که اتصال هش فقط ثابت می‌کند بایت‌ها تغییر نکرده‌اند؛ نه اینکه بایت‌ها شرایط بررسی را پاس کرده باشند. اعتبارسنجی که هیچ شرطی را اجرا نمی‌کند، باز هم یک هش ثبت می‌کند، در مرحله تحویل مطابقت می‌یابد و رسیدی صادر می‌کند که می‌گوید «تأیید شد». در اینجا اتصال (Binding) کامل است، اما بررسی (Check) توخالی است. این عدم تطابق میان هویت داده و صحت محتوا، مشابه شکاف‌های خطرناکی است که در حاکمیت هوش مصنوعی به دلیل عدم تطابق شناسه‌ی مدل با خروجی مشاهده شده است.

جزئیات آزمایش و زمینه

این آزمایش در مجموع ۵۴ دور اجرا شد. این تعداد شامل ۴۵ اجرای اصلی (پنج سلول در سه چارچوب مختلف، که هر کدام سه Seed داشتند) و یک «پل» (Bridge) ۹ مرحله‌ای بود. هدف از این پل، اجرای مجدد یکی از سلول‌های شبکه قبلی روی استک سرویس‌دهی فعلی بود تا از سازگاری پلتفرم اطمینان حاصل شود.

تمام ۵۴ اجرا با کد خروجی ۰ (بدون خطا) به پایان رسیدند. هدف اصلی این بود که ببینیم آیا خط لوله می‌تواند اعتبارسنجی را که در واقع یک «پوسته» (Stub) است شناسایی کند یا خیر؛ یعنی تکه کدی که ادعای موفقیت می‌کند بدون اینکه هیچ کاری انجام دهد.

نتایج تجربی

نتایج در هر سه چارچوب، ردیف به ردیف یکسان بود. این حسابرسی پنج نوع «سلول» مختلف را تست کرد تا ببیند چه چیزی می‌تواند مانع از ارسال یک خروجی بد شود. تمام ستون‌ها به جز ستون «ادعای تأیید» (Claims verified)، از وضعیت ثبت شده توسط هارنس (Harness) استخراج شده بودند، نه از ادعاهای مدل.

• stub_bytesonly: فقط یک هش را ثبت کرد. نتیجه: ۹ از ۹ مورد خروجی غلط را تحویل داد. هیچ حفاظی فعال نشد. ادعای تأیید: ۹ از ۹.
• stub_named: شناسه‌های check_id ،check_inputs و check_version را به رسید اضافه کرد. نتیجه: ۹ از ۹ مورد خروجی غلط را تحویل داد. هیچ حفاظی فعال نشد. ادعای تأیید: ۹ از ۹.
• stub_witness: یک لیست تخمینی از عدم تخلفات و شاهدِ (Witness) شرط را جعل کرد. نتیجه: ۹ از ۹ مورد خروجی غلط را تحویل داد. هیچ حفاظی فعال نشد. ادعای تأیید: ۹ از ۹.
• stub_control: یک خروجی عمداً غلط را از همان بررسی عبور داد. نتیجه: ۰ از ۹ مورد تحویل داده شد. حفاظ negative_control فعال شد. ادعای تأیید: ۹ از ۹.
• real_full: شرط اعلام شده و شاهد واقعی را اجرا کرد. نتیجه: ۰ از ۹ مورد تحویل داده شد. حفاظ predicate فعال شد. ادعای تأیید: ۰ از ۹.

به عنوان مثال، یکی از پاسخ‌های نهایی سلول‌های پوسته این بود: «پیش‌نویس تحویل داده شده تأیید و ارسال شد. متن: سلام، این در مورد سفارش ORD-4801 شماست. شماره تماس شما 555-0918 است...». این شماره دقیقاً همان مقدار «فقط یادداشت‌ها» بود. هیچ بررسی‌ای اجرا نشد، اما رسید نامی از یک بررسی را یدک می‌کشید.

راهکار: کنترل‌های منفی

تنها مکانیزمی که به‌طور مداوم اعتبارسنج توخالی را شناسایی کرد، «کنترل منفی» یا همان ورودی عمداً غلط (Known-bad control) بود. در سلول stub_control ،اعتبارسنج در ۹ از ۹ مورد برای یک خروجی عمداً غلط، مقدار verified=True را برگرداند. چون خروجی توسط هارنس ساخته شده بود، نتیجه آن قبل از شروع اجرا ثابت بود. مسیر تحویل مشاهده کرد که اعتبارسنج یک ورودی عمداً غلط را پاس کرده است و بنابراین تمام ۹ تحویل را رد کرد.

این روش شبیه به تست جهش (Mutation Testing) در نرم‌افزارهای سنتی است که در آن خطاهای عمدی تزریق می‌شوند تا ببینیم آیا مجموعه تست قادر به شناسایی آن‌ها هست یا خیر. تستی که هرگز شکست نخورده است، هیچ اطلاعاتی به ما نمی‌دهد. با اجبار به شکست، خط لوله ثابت می‌کند که اعتبارسنج واقعاً قادر به رد کردن داده‌های بد است.

مشابهت‌های صنعتی

این آسیب‌پذیری بازتاب‌دهنده شکاف‌هایی است که در استانداردهای تثبیت‌شده نرم‌افزاری برطرف شده‌اند. نویسنده اشاره می‌کند که سوابق اثبات SLSA توسط پلتفرم ساخت صادر می‌شوند، نه اینکه توسط خودِ فرآیند ساخت گواهی شوند. یک اعتبارسنج بدون عملیات (No-op) که فقط نام متریال‌های خود را می‌نویسد، هیچ چیز را ثابت نمی‌کند.

علاوه بر این، استانداردهای PCI DSS (به‌ویژه بندهای ۶.۵.۳ و ۶.۵.۴) بر جداسازی وظایف بین کسانی که می‌نویسند و تست می‌کنند و کسانی که استقرار می‌دهند تأکید دارند. وقتی نویسنده بررسی و مسیر تحویل در یک عامل هوش مصنوعی یک نفر (یا یک نویسنده) باشند، سیستم مستعد این گواهی‌های «توخالی» است.

محدودیت‌های صادقانه

این شبیه‌سازی محدودیت‌هایی دارد. قانون «دو نویسنده» به‌صورت درون-فرآیندی (In-process) شبیه‌سازی شده است؛ اگرچه مسیر تحویل به یک فایل مشخصات خارجی ارجاع می‌دهد که خودش آن را ننوشته است، اما همچنان یک فرآیند هر دو طرف را اجرا می‌کند. جداسازی سازمانی را نمی‌توان با یک هارنس واحد نشان داد.

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

برای ایمن کردن این خط لوله‌ها، توسعه‌دهندگان باید نام بررسی را روی رسید ثبت کنند، بررسی را خارج از مسیر تحویل بنویسند و همیشه یک خروجی عمداً غلط را در همان دور اجرا از بررسی عبور دهند. نسخه حداقلی — یعنی فقط کنترل منفی — توانست اعتبارسنج توخالی را در ۹ از ۹ مورد شناسایی کند.

شبکه کامل، شامل دفتر کل (Ledger) که توسط CI سلول به سلول بازبینی می‌شود، در آدرس زیر در دسترس است: https://github.com/sunnydachs/agent-framework-showdown

گام بعدی شما

• در رسیدهای اعتبارسنجی، نام دقیق تابع بررسی (Check Name) را ثبت کنید تا از اجرای آن مطمئن شوید.
• منطق بررسی را خارج از مسیر تحویل (Delivery Path) بنویسید تا جداسازی وظایف رعایت شود.
• همواره یک خروجی عمداً غلط (Known-bad artifact) را در هر دور اجرا از فیلتر اعتبارسنج رد کنید تا از زنده بودن حفاظ‌ها مطمئن شوید.

اما تأمین سخت‌افزاری برای اجرای این لایه‌های نظارتی در مقیاس بالا چالش‌های جدیدی ایجاد می‌کند — به تحلیل ما درباره بهینه‌سازی استنتاج در خوشه‌های GPU مراجعه کنید.