AGrail: نردههای حفاظتی امنیتی تطبیقی برای عاملهای مدل زبانی بزرگ (LLM) با قابلیت یادگیری در طول وظایف
من از نزدیک رقابت تسلیحاتی در زمینه نردههای حفاظتی برای عاملهای LLM را دنبال کردهام — GuardAgent در سال ۲۰۲۴، ShieldAgent در ICML 2025 — و AGrail (Luo et al., ACL 2025) قدم بعدی است که باید مطالعه میکردم. این سیستم شکاف مقیاسپذیری را هدف قرار میدهد که هیچکدام از پیشینیان حل نکرده بودند: چه اتفاقی میافتد وقتی یک سیستم نرده حفاظتی واحد باید از عاملها در بسیاری از وظایف مختلف محافظت کند، که هر کدام واژگان خطمشی و سطح ریسک خاص خود را دارند، بدون اینکه برای هر یک از قبل برنامهریزی شده باشد؟
مقاله
ویدئی لو، شنگهونگ دای، شیائوگنگ لیو، سومان بانرجی، هوان سان، موهائو چن و چائووئی شیائو، AGrail را تحت عنوان "یک نرده حفاظتی عامل مادامالعمر با تشخیص امنیت موثر و تطبیقی" معرفی کردهاند که در بخش مقالات بلند ACL 2025 منتشر شده است. مشکل اصلی دوگانه است: عاملهای LLM با ریسکهای خاص وظیفه که توسط مدیر تعریف میشوند (مثلاً «فایلهای این پوشه را حذف نکن») و ریسکهای سیستمی ناشی از آسیبپذیریهای طراحی (تزریق دستور، حملات محیطی) روبرو هستند؛ و نردههای حفاظتی موجود حداکثر یکی از این دستهها را به خوبی مدیریت میکنند و برای هر وظیفه نیاز به تعیین دستی خطمشی دارند. پاسخ AGrail یک سیستم مشارکتی شامل دو LLM است — یک تحلیلگر (Analyzer) و یک اجراکننده (Executor) — که بررسیهای امنیتی را در زمان استنتاج از طریق تطبیق در زمان تست (TTA) تولید، آزمایش و بهصورت بازگشتی اصلاح میکند و بررسیهای اصلاحشده را در یک ماژول حافظه ذخیره میکند تا یادگیری را به وظایف آینده منتقل کند.
ایدههای کلیدی
- همکاری دو-LLM: تحلیلگر بررسیهای امنیتی مرتبط را از حافظه بازیابی کرده، آنها را بازبینی میکند و مجموعههای بررسی بهروز شده را پیشنهاد میدهد. اجراکننده هر بررسی پیشنهادی را ارزیابی میکند — تصمیم میگیرد که آیا یک ابزار خارجی را فراخوانی کند، به استدلال خود متکی باشد یا یک بررسی تکراری را حذف کند. این حلقه تا زمانی که مجموعه بررسیها همگرا شود، بهصورت تکراری اجرا میشود.
- حافظه با پرامپتینگ گام-به-عقب (Step-back): اقدامات هم به زبان طبیعی و هم به صورت دستورات ابزاری با استفاده از پرامپتینگ گام-به-عقب ذخیره میشوند. در زمان استنتاج، فقط فرم زبان طبیعی نشان داده میشود (برای جلوگیری از تداخل سینتکس دستورات خام)، اما هر دو فرم برای بازیابی استفاده میشوند. حافظه حدود تکرار چهارم TTA همگرا میشود، با شباهت کسینوسی بیش از ۹۸٪ در دانههای تصادفی مختلف.
- بنچمارک Safe-OS: نویسندگان مجموعه داده جدیدی شامل ۱۰۰ سناریو را معرفی میکنند که تعاملات واقعی عامل سیستمعامل را از طریق داکر شبیهسازی میکند — ۲۳ مورد تزریق دستور، ۳۰ مورد خرابکاری سیستم، ۲۰ مورد حمله محیطی و ۲۷ مورد عادی — زیرا هیچ بنچمارک موجودی هر سه نوع ریسک سیستمی را ترکیب نکرده بود.
- ۹۶٪ حفظ اقدامات بیخطر در نرخ موفقیت حمله تزریق دستور ۰٪: در Safe-OS با Claude-3.5-Sonnet، سیستم AGrail تنها ۴.۴٪ از اقدامات بیخطر را مسدود میکند (۹۵.۶٪ حفظ) در حالی که به نرخ موفقیت حمله ۰٪ در برابر تزریق دستور دست مییابد. خطوط پایه رقیب تا ۴۹.۲٪ از اقدامات بیخطر را مسدود میکنند.
- نتایج ریسکهای خاص وظیفه: در Mind2Web-SC (عامل وب)، AGrail به F1=94.1 با ۹۵.۸٪ توافق دست یافت. در EICU-AC (حریم خصوصی مراقبتهای بهداشتی)، F1=98.5 با ۱۰۰٪ توافق حاصل شد.
- ناپایداری مدلهای ضعیف: استفاده از GPT-4o-mini به عنوان ستون فقرات، ناپایداری در توالیهای ورودی نشان میدهد؛ برای عملکرد قابل اعتماد به Claude-3.5-Sonnet نیاز است، که یک پیشنیاز محاسباتی ضمنی است که مقاله کمتر به آن پرداخته است.
نقاط قوت و ضعف
نتیجهای که بیش از همه مرا تحت تأثیر قرار داد، مقایسه مثبتهای کاذب است: GuardAgent و LLaMA-Guard تا ۴۹.۲٪ از اقدامات قانونی Safe-OS را مسدود میکنند. این یک فاجعه در تجربه کاربری است — نرده حفاظتی که نیمی از کارهای عادی را پرچمگذاری میکند، سیستمی است که هیچکس آن را فعال نخواهد گذاشت. نرخ مسدودسازی ۴.۴ درصدی AGrail برای اقدامات بیخطر واقعاً بهتر است.
با این حال، چندین شکاف شایان ذکر است. اول، اعداد مربوط به حمله تزریق محیطی (EIA) ضعیفتر از ادعاهای تیتر اصلی است: نرخ موفقیت حمله در تولید اقدام ۲۸٪ است — یعنی بیش از یک حمله از هر چهار حمله عبور میکند. مقاله این موضوع را در مقایسه با نتیجه ۰٪ تزریق دستور پنهان کرده است. دوم، مدل تهدید محدود است: Safe-OS سه نوع حمله را پوشش میدهد، اما مقاله زنجیرههای استدلال خصمانهای را که تحلیلگر را کاملاً دور میزنند، یا مواردی که بافتار (Context) بسیار طولانی ماژول حافظه را به سمت بررسیهای قبلی اشتباه سوق میدهد، ارزیابی نمیکند. سوم، داستان یادگیری مادامالعمر مستلزم آن است که عامل مکرراً با اقدامات مشابه روبرو شود تا حافظه همگرا شود — نتیجه همگرایی در تکرار چهارم در تنظیمات کنترلشده مقاله صادق است، اما مشخص نیست وقتی توزیع اقدامات بسیار متنوع باشد، حافظه با چه سرعتی پایدار میشود. چهارم، سربار محاسباتی ناشی از اجرای دو LLM به علاوه تکرارهای TTA در هر مرحله از عامل هرگز اندازهگیری نشده است. در کاربردهای حساس به تاخیر، این هزینه اهمیت دارد.
نویسندگان صادقانه اعتراف میکنند که به جای مدلهای تخصصی نرده حفاظتی، به LLMهای عمومی وابسته هستند و فراخوانی ابزار حداقلی است. چیزی که آنها بحث نمیکنند این است که پیشنهادات بررسی خطمشی تحلیلگر، خود میتوانند توسط مهاجمی که خط لوله پرامپتینگ گام-به-عقب را درک میکند، مسموم شوند.
چرا این موضوع برای هوش مصنوعی در امور مالی مهم است
طبقهبندی ریسکهای خاص وظیفه + ریسک سیستمی مستقیماً با عاملهای حسابداری مطابقت دارد. یک عامل بازنویسی Beancount با ریسکهای خاص وظیفه (قوانین مدیر: «هرگز در یک دوره بسته شده ثبت نزن»، «همیشه برای تراکنشهای بالای ۱۰,۰۰۰ دلار تاییدیه دو طرفه بخواه») در کنار ریسکهای سیستمی (یک یادداشت مخرب در شرح تراکنش که دستورات جدیدی را تزریق میکند) روبرو است. چارچوب AGrail برای این مورد استفاده طبیعیتر از مدارهای قانون رسمی ShieldAgent است، زیرا حسابداران خطمشیها را به زبان ساده بیان میکنند ، نه منطق مرتبه اول.
جنبه یادگیری مادامالعمر به ویژه مرتبط است. یک استقرار واحد ممکن است از دهها دفتر کل متمایز محافظت کند — هر کدام با خطمشیهای فهرست حسابهای متفاوت، محدودههای سال مالی متفاوت و سلسلهمراتب تایید متفاوت. توانایی انتقال بررسیهای امنیتی از یک دفتر کل به دفتر دیگر و اصلاح آنها از طریق TTA به جای شروع از صفر، میتواند به طور معناداری بار پیکربندی هر دفتر کل را کاهش دهد. اینکه آیا پیادهسازی فعلی واقعاً در مقیاس یک پلتفرم حسابداری چندمستأجره واقعی به این هدف میرسد یا خیر، سوالی است که مقاله به آن پاسخ نمیدهد — ارزیابیهای آن سه وظیفه مجزای عامل را پوشش میدهد، نه دهها مورد را.
نرخ شکست ۲۸ درصدی در تولید اقدام EIA عددی است که ذهن مرا درگیر میکند. برای یک عامل حسابداری، یک حمله موفق در تولید اقدام خصمانه به معنای ثبت یک ردیف روزنامه اشتباه است. این اتفاق بدون حسابرسی دستی قابل جبران نیست. نرده حفاظتی که در ۲۸٪ حملات EIA شکست میخورد، به یک لایه تایید ثانویه نیاز دارد — که ما را دوباره به بحثهای مربوط به عاملهای چندگانه و طراحیهای تایید رسمی از لیستهای مطالعه قبلی بازمیگرداند.
چه چیزهایی را بعداً مطالعه کنیم
- M3MAD-Bench (arXiv:2601.02854) — جامعترین حسابرسی در مورد اینکه آیا مباحثه میان چند عامل واقعاً در وظایف و قالبهای مختلف کمک میکند یا خیر؛ مستقیماً با طراحی LLM مشارکتی AGrail برای خط لولههای مالی مرتبط است.
- ShieldAgent (arXiv:2503.22738, ICML 2025) — رویکرد تایید رسمی که AGrail به طور ضمنی با آن مقایسه شده است؛ خواندن هر دو در کنار هم تفاوت بین تطبیقپذیری و تضمینهای رسمی را روشن میکند.
- به سوی استفاده ایمن و قابل تایید از ابزار برای عاملهای LLM (arXiv:2601.08012, ICSE 2026) — تحلیل فرآیند STPA را با MCP ترکیب میکند تا مشخصات ایمنی قابل اجرا برای عاملهای فراخوان ابزار تولید کند؛ سیستماتیکترین مکمل موجود برای بررسیهای زمان اجرای AGrail.
