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

تصور کنید یک برنامه‌نویس برای جلوگیری از دسترسی غیرمجاز به دیتابیس، در دستورالعمل‌های مدل می‌نویسد «هرگز این فایل را باز نکن»، اما هیچ قفل سخت‌افزاری روی فایل نمی‌گذارد. در دنیای عامل‌های هوش مصنوعی، تکیه بر حافظه یا پرامپت برای اجرای یک محدودیت، نه یک کنترل، بلکه تنها یک «ترجیح» است که مدل می‌تواند در لحظه اجرا، آن را توجیه کرده و نادیده بگیرد. این آسیب‌پذیری در حافظه مدل‌ها می‌تواند منجر به رفتارهای پیش‌بینی‌ناپذیری شود، مشابه آنچه در بررسی سازوکار مسموم‌سازی حافظه و راهکارهای مقابله با آن تحلیل کردیم. نویسنده برای تأکید بر این تمایز حیاتی، قانون چهار کلمه‌ای «قوانین، یادگیری نیستند» (Rules are NOT learnings) را در ۱۰۳ فایل از تنظیمات عامل خود گنجانده است.

تنها راه اطمینان از اینکه یک عامل (Agent) واقعاً از یک قانون پیروی می‌کند، استفاده از یک قلاب قطعی (Deterministic Hook) است که در صورت تخلف، برنامه را با یک کد خطا (Non-zero code) متوقف کند. این تمایز بین بازیابی (Recall) — یعنی به یاد آوردن قانون — و اجرا (Enforcement) — یعنی اجبار به رعایت قانون — حیاتی‌ترین نقطه شکست در گذار از چت‌بات‌های ساده به عامل‌های خودمختار است. در محیط‌های عملیاتی، یک «حفاظ» (Guardrail) که صرفاً تکه‌ای متن در پنجره زمینه (Context Window) باشد، ماهیتی احتمالی دارد. یعنی همه چیز به این بستگی دارد که مدل در لحظه فراخوانی، تصمیم بگیرد آن قانون مرتبط است یا خیر. بازیابی اطلاعات برای ارائه زمینه عالی است، اما هرگز نمی‌تواند یک کنترل سیستمی باشد.

با توجه به تغییر رویکرد صنعت به سمت گردش‌کارهای عامل‌محور (Agentic Workflows)، این متدولوژی ایمنی هوش مصنوعی را نه یک مسئله مربوط به مهندسی پرامپت (Prompt Engineering)، بلکه یک مسئله مهندسی سیستم می‌بیند. این رویکرد دقیقاً مشابه روش مدیریت خطاهای بحرانی در نرم‌افزارهای سنتی است: استفاده از خروج‌های سخت و بررسی‌های قطعی به جای دادن «پیشنهاد» به زمان اجرا (Runtime). برای اطمینان از پایداری یک قانون، شما باید سه گام را بردارید: قانون را در متنی بنویسید که همیشه بارگذاری می‌شود، سازوکاری بسازید که بتواند با کد غیرصفر خارج شود، و سپس این جفت را ممیزی کنید تا مطمئن شوید متن موجود است، سازوکار وجود دارد و این سازوکار به درستی سیم‌کشی شده است.

کالبدشکافی یک حفاظ واقعی

به نقل از تحلیل فنی دقیقی که در ۱۸ آگوست ۲۰۲۶ در وب‌سایت dev.to منتشر شد، یک قانون غیرقابل مذاکره برای عملکرد درست به دو بخش مجزا نیاز دارد که هیچ‌کدام جایگزین دیگری نیستند:

• متن همیشه-بارگذاری‌شده (Always-Loaded Text): متنی که در هر بار اجرا بدون نیاز به تصمیم‌گیری برای بازیابی، در دسترس است. این بخش «چرایی» قانون را توضیح می‌دهد و به عامل اجازه می‌دهد قانون را در مواردی به کار ببرد که سازوکار فنی هرگز پیش‌بینی نکرده است. طبق مستندات CLAUDE.md، چون بازیابی به معنای اجرا نیست، این قانون نباید به عنوان یک ورودی حافظه (Memory Entry) ذخیره شود.
• سازوکار قطعی (Deterministic Mechanism): این بخش می‌تواند یک قلاب (Hook)، یک ابزار بررسی کد (Lint)، یک بررسی پیش از ارسال (Pre-push check) یا یک کد خروج باشد. این سازوکار زمانی عمل می‌کند که متن یا خوانده نشده باشد، یا خوانده شده اما توسط مدل توجیه و نادیده گرفته شده باشد. برای مثال، یکی از این سازوکارها یک قلاب ۱۹۲ خطی است که با کد خروج ۲ متوقف می‌شود و نام آن در فایل تنظیمات ثبت شده است.

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

شکست ممیزی‌های استاندارد

بسیاری از توسعه‌دهندگان، عامل‌های خود را تنها با بررسی اینکه آیا نام یک قلاب در فایل تنظیمات وجود دارد یا خیر، ممیزی می‌کنند (در واقع با استفاده از دستور grep برای یافتن نام قلاب در تنظیمات). این یک بررسی سطحی است که از دو جهت شکست می‌خورد: برخی قلاب‌ها فعال‌اند اما پشت توزیع‌کننده‌های والد (Parent Dispatchers) پنهان شده‌اند، و برخی دیگر در تنظیمات لیست شده‌اند اما از نظر ساختاری قادر نیستند هیچ ورودی‌ای را رد کنند.

برای توصیف این شکست، نویسنده به یک معیار کیفیت (Quality Rubric) اشاره می‌کند که قانونی صریح داشت: «عنوان‌ها تنها یک پیش‌فیلتر ارزان هستند و هرگز نباید مبنای تصمیم نهایی باشند». این قانون به زبان ساده نوشته شده و همیشه بارگذاری می‌شد. با این حال، سازوکار فنی همراه آن، هم‌پوشانی لغوی (Lexical Overlap) بین عنوان موضوع و عنوان مجموعه را محاسبه می‌کرد و اگر مقدار آن بزرگتر یا مساوی ۰.۸ بود، آن را پذیرفته‌شده می‌دانست.

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

پروتکل ممیزی سه-سوالی

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

۱. آیا متن همیشه-بارگذاری‌شده وجود دارد و آیا دلیل قانون (چرایی) را توضیح می‌دهد؟
۲. آیا سازوکاری وجود دارد و آیا واقعاً از زمان اجرا، با احتساب زنجیره‌های توزیع، قابل دسترسی است؟
۳. آیا تا به حال مشاهده شده است که این سازوکار، چیزی را که برای رد کردنش ساخته شده، رد کند؟

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

سرشماری ۹۰ قلاب کنترلی

برای کمی کردن این شکاف، سرشماری روی ۹۰ قلاب در یک محیط عملیاتی عامل (Agent Harness) انجام شد. نویسنده تمام قلاب‌های متصل را فهرست کرد، موارد توزیع‌شده به عنوان فرزند را شناسایی نمود، ورودی ممنوعه را از طریق stdin به هر یک داد و کد خروج را ثبت کرد.

نتایج سرشماری:

• قلاب‌های متصل: ۹۰ مورد در مجموع (۷۷ مورد نام‌برده در تنظیمات، ۱۳ مورد فقط از طریق والد قابل دسترسی).
• توصیه‌ای بر اساس طراحی (Advisory): ۵۹ قلاب (این‌ها فقط زمینه اضافه می‌کنند، وضعیت را می‌نویسند یا تله‌متری ثبت می‌کنند و هیچ قابلیت ردی ندارند). نامیدن این‌ها به عنوان «حفاظ» یک خطای آماری در شمارش فایل‌ها به جای قابلیت‌هاست.
• قادر به رد کردن: ۳۱ قلاب (به صورت دستی شناسایی شدند؛ اسکن خودکار ۳۴ مورد را گزارش کرده بود).
• رد کردن مشاهده‌شده: ۲۸ قلاب با موفقیت ورودی ممنوعه را با کد خروج ۲ رد کردند.
• شکست‌های خاموش: ۲ قلاب با وجود دریافت ورودی ممنوعه، کد موفقیت (۰) برگرداندند.
• غیرقابل تست: ۱ قلاب به دلیل نیاز به یک ترانسکریپت ساختگی و فراخوانی مدل غیرقطعی، قابل تست نبود.
• اعلام‌شده اما غیرفعال: ۳ قلاب در تنظیمات مرجع بودند اما در محیط عملیاتی حضور نداشتند.

دو مورد خاص جلب توجه کرد. اول، قلابی برای ثبت قوانین گفتگو بود تا قوانین بیان شده در چت گم نشوند. این قلاب بر اساس Session ID فیلتر می‌کرد، اما چون نویسنده برای ۲۳۰ ورودی، شناسه‌های نشست را null ذخیره کرده بود، قلاب برای هر دو حالت (معتبر و null) کد خروج ۰ برگرداند. این قلاب در تمام آن ۲۳۰ مورد اجرا شده بود اما هرگز فعال نشد. مورد دوم، قلابی بود که در انتظار یک لیست سفید (Allowlist) بود که هنوز وجود نداشت و بنابراین در حالت خفته (Dormant) ارسال شده بود.

علاوه بر این، مقایسه (Diff) بین فایل تنظیمات مرجع (۸۲ قلاب) و زمان اجرای زنده (۷۹ قلاب) نشان داد سه سازوکار کاملاً غیرفعال بودند یا به دایرکتوری‌های ناموجود اشاره می‌کردند. یک حفاظ که جلوی شماره‌های تکراری رکورد تصمیم را می‌گرفت، به دایرکتوری‌ای متصل بود که سیستم آن را جابجا کرده بود. این موارد در ممیزی استاندارد «پاس» می‌شدند چون فایل وجود داشت، اما در عمل مرده بودند.

وام‌گیری از مهندسی امنیت

این متدولوژی در واقع ترجمه پروتکل‌های امنیتی تثبیت‌شده برای عامل‌های هوش مصنوعی است. نویسنده به منابع معتبری اشاره می‌کند:

• Palantir (۲۰۱۷): چارچوب استراتژی شناسایی و هشدار آن‌ها، بخش «اعتبارسنجی» (Validation) را برای هر شناسایی اجباری می‌کند. این بخش نیازمند مراحلی برای تولید یک رویداد مثبت واقعی (True Positive) است تا هشدار فعال شود. این مشابه یک تست واحد (Unit Test) است تا مهندس مطمئن شود سیستم هشدار عمل می‌کند.
• کتاب SRE گوگل (فصل ۱۰): در فصل مربوط به Borgmon (و نه فصل کلی تست)، توضیح می‌دهد که ورودی‌ها باید به‌گونه‌ای سنتز شوند که فعال شدن قانون مشاهده شود و سپس این تست‌ها پیش از ارسال پیکربندی، در CI اجرا شوند.
• NIST (SP 800-53A Rev. 5): استانداردهای NIST بین «بررسی» (Examine - شامل چک کردن، بازرسی، مرور، مشاهده، مطالعه یا تحلیل) و «تست» (Test - به معنای به کار انداختن یک شیء تحت شرایط مشخص برای مقایسه رفتار واقعی با مورد انتظار) تفاوت قائل می‌شوند. یک کنترل ممکن است تنها بر اساس «بررسی» مؤثر اعلام شود، اما نویسنده بر نسبت کنترل‌هایی تأکید دارد که در بررسی پاس می‌شوند اما در تست شکست می‌خورند.

برای پیاده‌سازی این مدل در عامل‌ها، نویسنده از رویکرد Atomic Red Team شرکت Red Canary استفاده کرد. این کتابخانه از تست‌ها برای ارزیابی و بهبود پوشش شناسایی در یک محیط به کار می‌رود. با این حال، یک تغییر حیاتی اعمال شد: چون برخی قلاب‌ها دسترسی به اعتبارنامه‌ها (Credentials) را مسدود می‌کنند، اجرای دستور ممنوعه باعث نشت رمزها می‌شد. به جای آن، پروب‌ها از طریق stdin به قلاب ارسال شدند و فقط کد خروج خوانده شد؛ بدین ترتیب دستور هرگز واقعاً اجرا نشد.

شکاف ابزاری

برای خودکارسازی این فرآیند، اسکریپتی در آدرس github.com/willianpinho/hook-refusal-census منتشر شده است (تحت لایسنس MIT، بدون وابستگی و فقط خواندنی). این ابزار قلاب‌های متصل را فهرست کرده، فرزندان توزیع‌شده را شناسایی می‌کند، قابلیت‌های رد کردن را طبقه‌بندی کرده و تنظیمات نگهداری شده را با زمان اجرای زنده مقایسه می‌کند.

انتخاب‌های طراحی و محدودیت‌ها:

• وضعیت UNPROBED: هر قلابی که پروب نداشته باشد، به عنوان «تست‌نشده» (UNPROBED) گزارش می‌شود و در شمارش موارد پاس‌شده قرار نمی‌گیرد. این کار برای جلوگیری از ایجاد حس امنیت کاذب بر اساس یک مخرج کسر ناقص است.
• شکاف ۳۴ در برابر ۳۱: اسکن خودکار ۳۴ قلاب را قادر به مسدودسازی تشخیص داد، در حالی که بررسی دستی ۳۱ مورد بود. سه مورد اضافی حاوی exit 2 در یک بلوک catch سطح بالا بودند (Fail-closed در صورت کرش)، که یک رگکس نمی‌تواند آن را از یک خروج عمدی برای شناسایی تشخیص دهد. نویسنده این خطا را باقی گذاشت تا یک خطای مرئی را با یک خطای نامرئی جایگزین نکند.
• حساسیت محیطی: ابزار متوجه شد یک حفاظ گردش‌کار git، وقتی از یک پوشه غیر از مخزن اجرا شود کد ۰ و وقتی از داخل مخزن اجرا شود کد ۲ برمی‌گرداند. اکنون ابزار دایرکتوری اجرا را چاپ می‌کند تا نتایج بازتولیدپذیر باشند.
• خطاهای تطبیق مسیر: نسخه عمومی ابزار برای مدت کوتاهی پنج اسکریپت همگام‌سازی را به عنوان قلاب‌های گم‌شده علامت زد، زیرا آن‌ها یک دایرکتوری دورتر از پوشه قلاب‌ها بودند، هرچند از طریق تنظیمات به درستی فراخوانی می‌شدند.

تحلیل: گذار به اثبات رفتاری

برای توسعه‌دهندگان و معماران هوش مصنوعی، این بدان معناست که عصر «مهندسی پرامپت» برای ایمنی در حال رسیدن به سقف توانایی‌های خود است. اثر مرتبه دوم این اتفاق، حرکت به سمت «SRE عامل‌محور» (Agentic Site Reliability Engineering) است، جایی که تمرکز از هوشمندی مدل به صلبیت و سخت‌گیری زیرساخت (Harness) منتقل می‌شود. این رویکرد در واقع تکامل‌یافته‌ی روش‌هایی است که در تثبیت خطاهای عامل‌های AI با مکانیزم «لایه نشانی اصلاحات» بررسی شد تا از تکرار خطاهای سیستمی جلوگیری شود.

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

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

• اگر از عامل‌های هوش مصنوعی در محیط تولید استفاده می‌کنید، لیست حفاظ‌های خود را از حالت «بررسی وجود فایل» به «تست ورودی ممنوعه» تغییر دهید.
• برای هر قانون حیاتی، یک تست واحد (Unit Test) بنویسید که ورودی تخلف را شبیه‌سازی کرده و کد خروج غیرصفر را تأیید کند.
• از اسکریپت hook-refusal-census برای شناسایی قلاب‌های «مرده» یا «تزیینی» در زیرساخت خود استفاده کنید.

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