پرش به محتوای اصلی

ShieldAgent: استدلال سیاست امنیتی قابل تایید برای عامل‌های LLM

· زمان مطالعه 7 دقیقه
Mike Thrift
Mike Thrift
Marketing Manager

پس از پوشش GuardAgent در هفته گذشته — که سیاست‌های امنیتی را به کد قابل اجرا ترجمه می‌کند — می‌خواستم مقاله‌ای را بخوانم که صراحتاً ادعا می‌کند آن را شکست می‌دهد: ShieldAgent (Chen, Kang, and Li, ICML 2025, arXiv:2503.22738). پیشرفتی که GuardAgent نسبت به گاردریل‌های مبتنی بر پرامپت نشان داد در حال حاضر قابل توجه بود؛ اما اینکه آیا مدارهای قانون احتمالی ShieldAgent واقعاً شکاف باقی‌مانده را پر می‌کنند یا صرفاً مرزها را جابجا می‌کنند، موضوعی بود که ارزش بررسی دقیق داشت پیش از آنکه در مورد معماری امنیت بازنویسی (write-back safety) برای عامل‌های Beancount تصمیم‌گیری شود.

مقاله

2026-05-28-shieldagent-verifiable-safety-policy-reasoning-llm-agents

سیستم ShieldAgent خود را به عنوان اولین عامل گاردریلی معرفی می‌کند که به طور خاص برای امنیت عامل (agent) طراحی شده است، نه امنیت LLM — که تمایزی معنادار است. گاردریل‌های LLM ورودی‌ها و خروجی‌ها را به صورت ایزوله غربال می‌کنند؛ اما گاردریل‌های عامل باید در محیط‌های پویا که یک گام به ظاهر خوش‌خیم می‌تواند بخشی از یک توالی مضر باشد، روی مسیرهای عملیاتی چندگانه استدلال کنند. استدلال مرکزی مقاله این است که رویکردهای موجود، از جمله GuardAgent، هنوز بیش از حد به استدلال خام LLM تکیه دارند که گران، ناهماهنگ و غیرقابل تایید است.

سهم فنی اصلی، مدار قانون احتمالی مبتنی بر عمل (action-based probabilistic rule circuit) است: اسناد سیاست به قوانین قابل تایید تجزیه می‌شوند، به هر قانون یک وزن نرم اختصاص می‌یابد (که به عنوان پتانسیل‌های شبکه منطق مارکوف پیاده‌سازی شده است) و قوانین با استفاده از خوشه‌بندی طیفی به مدارهای خاصِ عمل دسته‌بندی می‌شوند. در زمان استنتاج، ShieldAgent مدارهای مرتبط را برای هر عمل عامل فراخوانی کرده، چهار عملیات رسمی (جستجو، بررسی باینری، شناسایی و تایید رسمی با استفاده از مدل‌چکر Stormpy) را اجرا نموده و یک برچسب امنیتی احتمالی محاسبه می‌کند. تصمیم نهایی از یک شرط امنیت نسبی استفاده می‌کند — شکاف بین توده‌های احتمالی ایمن و ناایمن باید از آستانه ε فراتر رود — که باعث کاهش مثبت‌های کاذب در مقایسه با آستانه‌های احتمالی مطلق می‌شود.

ایده‌های کلیدی

  • مدارهای قانون احتمالی روی شبکه‌های منطق مارکوف: وزن‌های نرم قوانین، سیاست‌های متناقض یا ناقص را به شکلی منعطف مدیریت می‌کنند؛ کاری که رویکردهای صلب تولید کد مانند GuardAgent در زمان ابهام در سیاست‌ها نمی‌توانند انجام دهند.
  • تایید رسمی به عنوان یک عملیات درجه اول: بررسی مدل با Stormpy یکی از چهار عملیات حفاظتی است، نه یک افزونه پسینی. این دقیقاً همان معنای "قابل تایید" (verifiable) در عنوان مقاله است.
  • دقت ۹۰.۴٪ در حملات مبتنی بر عامل و ۹۱.۷٪ در حملات مبتنی بر محیط در بنچمارک ShieldAgent-Bench، با نرخ مثبت کاذب ۴.۸٪ — کمترین میزان در میان تمام مدل‌های پایه ارزیابی شده.
  • بهبود متوسط ۷.۴٪ نسبت به GuardAgent در سه بنچمارک موجود: ST-WebAgentBench (۹۱.۱٪ در مقابل ۸۴.۰٪)، VWA-Adv (۹۴.۱٪ در مقابل ۸۹.۹٪) و AgentHarm (۸۶.۹٪ در مقابل ۷۸.۴٪).
  • ۶۴.۷٪ پرس‌وجوی API کمتر و ۵۸.۲٪ استنتاج سریع‌تر نسبت به بهترین روش قبلی، زیرا مدارهای قانون به جای ارسال کل مسیر به یک LLM برای هر گام، امکان بازیابی هدفمند را فراهم می‌کنند.
  • افزایش قابل توجه رعایت انطباق آنلاین: هنگامی که به عنوان یک مانیتور بلادرنگ مستقر شد، رعایت انطباق در محیط Shopping از ۴۶.۸٪ به ۶۵.۳٪ و در GitLab از ۲۲.۸٪ به ۵۰.۷٪ جهش کرد.
  • ShieldAgent-Bench شامل ۳,۱۱۰ نمونه در ۶ محیط وب و ۷ دسته خطر، با ۱,۰۸۰ قانون امنیتی تایید شده است — یک دستاورد واقعاً مفید و مستقل از متدولوژی.

آنچه پابرجا می‌ماند — و آنچه پابرجا نمی‌ماند

ایده اصلی درست است: جایگزینی قضاوت خام LLM با مدارهای احتمالی ساختاریافته، گاردریل را ارزان‌تر، سریع‌تر و قابل حسابرسی‌تر می‌کند. دستاوردهای بهره‌وری (۶۴.۷٪ فراخوانی API کمتر) فقط یک ویژگی خوب نیستند — بلکه در محیط‌های عملیاتی که هر فراخوانی گاردریل به تأخیر عامل اصلی می‌افزاید، اهمیت حیاتی دارند.

طراحی بنچمارک نیز شایسته تقدیر است. ShieldAgent-Bench با استفاده از الگوریتم‌های واقعی حملات تخاصمی (AgentPoison, AdvWeb) در محیط‌های وب واقعی ساخته شده است که بسیار معتبرتر از مجموعه‌داده‌های امنیتی مصنوعی است.

اما چندین مورد باعث تردید من می‌شود. اول، سیستم برای استخراج سیاست، اصلاح قوانین و برنامه‌ریزی به GPT-4o وابسته است — به این معنی که هزینه‌ها و تأخیر GPT-4o را در مرحله ساخت سیاست به ارث می‌برد. نویسندگان اشاره می‌کنند که "بررسی کارشناس انسانی در طول ساخت اولیه مدل سیاست توصیه می‌شود"، که به طور ضمنی تأیید می‌کند استخراج خودکار به اندازه کافی برای استقرار بدون نظارت قابل اعتماد نیست. دوم، مقاله به عملکرد ضعیف‌تر در خطرات مربوط به توهم (hallucination) که نیاز به دانش واقعی فراتر از سند سیاست دارند، اعتراف می‌کند. برای عامل‌های حسابداری، جایی که یک ثبت ممکن است مطابق با سیاست به نظر برسد اما از نظر محاسباتی اشتباه باشد یا به یک حساب غیرموجود اشاره کند، این یک شکاف واقعی است. سوم، تمام بنچمارک‌ها محیط‌های عامل وب (خرید، GitLab، Reddit) هستند. هیچ ارزیابی روی وظایف مالی یا حسابداری انجام نشده است. این اعداد چشمگیر ممکن است به حوزه‌ای با الزامات صحت محاسباتی سخت‌گیرانه‌تر و تحمل کمتر برای منفی‌های کاذب، منتقل نشوند.

همچنین متوجه شدم که رقم "۱۱.۳٪ بهبود نسبت به روش‌های قبلی" (ذکر شده در چکیده) و رقم "۷.۴٪ بهبود" (ذکر شده در متن اصلی مقاله برای بنچمارک‌های موجود) متفاوت هستند. عدد بزرگتر احتمالاً شامل خودِ ShieldAgent-Bench است، جایی که نویسندگان هم بر بنچمارک و هم بر متدولوژی کنترل دارند — یک سوگیری رایج در ارزیابی‌ها.

چرا این برای هوش مصنوعی مالی اهمیت دارد

مسئله امنیت بازنویسی در Beancount از نظر ساختاری مشابه چیزی است که ShieldAgent به آن می‌پردازد: یک عامل اصلی تغییراتی را در دفتر کل پیشنهاد می‌دهد و یک محافظ باید آن تغییرات را پیش از ثبت نهایی با سیاست‌ها تطبیق دهد. ایده مدار قانون به خوبی قابل تطبیق است — قوانین سیاست Beancount (عدم تطابق بدهکار/بستانکار، لزوم وجود حساب، مثبت بودن مبالغ، تایید تراکنش توسط کاربر) دقیقاً همان نوع محدودیت‌های ساختاریافته و قابل تایید هستند که از بازنمایی رسمی به جای استدلال آزاد LLM بهره می‌برند.

دستاوردهای بهره‌وری در حسابداری بیش از عامل‌های وب اهمیت دارند. یک عامل بازنویسی دفتر کل ممکن است ده‌ها ثبت روزنامه را در یک جلسه پیشنهاد دهد؛ گاردریلی که فراخوانی‌های API را تا ۶۴.۷٪ کاهش می‌دهد، می‌تواند تایید بلادرنگ را امکان‌پذیر کند. با این حال، شکاف توهم، مسئله اصلیِ باز باقی‌مانده است: ShieldAgent نمی‌تواند ثبت‌هایی را که مطابق با سیاست هستند اما از نظر واقعیت اشتباه‌اند (مبالغ غلط، حساب‌های طبقه‌بندی‌نشده) شناسایی کند. برای Beancount، این حالت شکست مسلماً رایج‌ترین و هزینه‌برترین نوع است. یک گاردریل ترکیبی — ShieldAgent برای انطباق با سیاست و یک تاییدکننده محاسباتی مجزا برای صحت عددی — معماری مناسبی به نظر می‌رسد.

آنچه باید در ادامه بخوانید

  • AGrail: A Lifelong Agent Guardrail with Effective and Adaptive Safety Detection (Luo et al., ACL 2025, arXiv:2502.11448) — رویکردی مکمل را در پیش می‌گیرد: تولید چک امنیتی تطبیقی که در طول وظایف یاد می‌گیرد، به جای استخراج پیشینی یک مدل سیاست ثابت. آن را با ShieldAgent مقایسه کنید تا تفاوت بین سیاست ثابت و سیاست تطبیقی را درک کنید.
  • Towards Verifiably Safe Tool Use for LLM Agents (arXiv:2601.08012, ICSE 2026) — از تحلیل فرآیند تئوری سیستم‌ها (STPA) برای ایجاد تضمین‌های امنیتی رسمی برای عامل‌های فراخوان ابزار استفاده می‌کند و در صورت امکان از تایید احتمالی به سمت تایید قطعی حرکت می‌کند.
  • ST-WebAgentBench: A Benchmark for Evaluating Safety and Trustworthiness in Web Agents (arXiv:2410.06703) — دقیق‌ترین بنچمارک در میان سه بنچمارک موجود که برای ارزیابی ShieldAgent استفاده شده است؛ پیش از انطباق آن‌ها برای ارزیابی عامل‌های مالی، ارزش درک طراحی وظایف و تعاریف معیارهای آن را دارد.