GuardAgent: اعمال امنیت قطعی برای عامل‌های LLM از طریق اجرای کد

مشکل اصلی ایمنی برای هر عامل با قابلیت نوشتن (write-back)، این است: چگونه از انجام اقدامی که هرگز قرار نبوده انجام دهد، جلوگیری کنیم؟ GuardAgent (Xiang و همکاران، ICML 2025) یک عامل گاردریل اختصاصی را پیشنهاد می‌کند — یک عامل LLM مجزا که هر اقدام عامل هدف را پیش از اجرا، با مجموعه‌ای از سیاست‌های امنیتی مطابقت می‌دهد. برای Bean Labs، جایی که پاسخ به سوال "آیا عامل می‌تواند بدون نقض قوانین حسابداری در دفتر کل بنویسد؟" غیرقابل مذاکره است، این مقاله مستقیماً در هسته اصلی دستور کار تحقیقاتی ما قرار می‌گیرد.

مقاله

مقاله GuardAgent: Safeguard LLM Agents by a Guard Agent via Knowledge-Enabled Reasoning، اثر Zhen Xiang و همکارانش از UIUC، Emory و UC Berkeley، آنچه نویسندگان ادعا می‌کنند اولین عامل گاردریل چندمنظوره برای سیستم‌های LLM است را معرفی می‌کند. ایده اصلی ساده است: به جای گنجاندن محدودیت‌های امنیتی مستقیماً در پرامپت عامل هدف (جایی که ممکن است نادیده گرفته شوند یا فراموش شوند)، GuardAgent به عنوان یک عامل مستقل اجرا می‌شود که اقدامات عامل هدف را رهگیری کرده و آن‌ها را با سیاست‌های اعلام شده تأیید می‌کند.

این مکانیسم دو مرحله دارد. اول، LLM سیاست امنیتی و ورودی یا خروجی پیشنهادی عامل هدف را می‌خواند، سپس یک برنامه اقدام گام‌به‌گام برای آنچه باید بررسی شود می‌نویسد. دوم، آن برنامه را با استفاده از یک جعبه‌ابزار از توابع قابل فراخوانی، به کد پایتون قابل اجرا تبدیل می‌کند. یک مفسر خارجی پایتون کد را اجرا کرده و یک حکم قطعی بله/خیر صادر می‌کند. یک ماژول حافظه، چندتایی‌های وظایف قبلی (سیاست، برنامه، کد) را ذخیره کرده و با استفاده از فاصله لون‌اشتاین (Levenshtein distance)، نمونه‌های مشابه قبلی را بازیابی می‌کند که یادگیری در متن چند-نمونه‌ای (few-shot in-context learning) را بدون نیاز به تنظیم دقیق (fine-tuning) اضافی ممکن می‌سازد. مقاله این رویکرد را بر روی دو بنچمارک جدید که توسط نویسندگان معرفی شده‌اند، ارزیابی می‌کند.

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

• اجرای کد بر قضاوت‌های زبان طبیعی برتری دارد. وقتی تصمیمات امنیتی به جای متن LLM به صورت کد ارائه می‌شوند، خروجی قطعی است: موتور پایتون یا اجازه می‌دهد یا مسدود می‌کند، بدون هیچ خطر توهم (hallucination) در مرحله نهایی تصمیم‌گیری. LLM فقط باید کد صحیح تولید کند، نه یک پاسخ نهایی صحیح.
• دو بنچمارک اختصاصی. بنچمارک EICU-AC (شامل ۳۱۶ نمونه) کنترل دسترسی برای EHRAgent را روی یک پایگاه داده مراقبت‌های بهداشتی با سه نقش کاربری و ده پایگاه داده آزمایش می‌کند. بنچمارک Mind2Web-SC (شامل ۲۰۰ نمونه) شش سیاست امنیتی را برای عامل وب SeeAct آزمایش می‌کند. هر دو توسط نویسندگان مخصوص این مقاله ایجاد شده‌اند.
• دقت برچسب‌گذاری ۹۸.۷٪ و ۹۰.۰٪ (با GPT-4) به ترتیب در EICU-AC و Mind2Web-SC. نکته حیاتی این است که دقت پاسخ نهایی — یعنی اینکه آیا عامل هدف هنوز وظیفه خود را در زمانی که باید مجاز باشد انجام می‌دهد یا خیر — در هر دو تنظیم روی ۱۰۰٪ باقی می‌ماند.
• قواعد امنیتی کدگذاری شده (Hardcoded) به شدت شکست می‌خورند. تعبیه سیاست‌ها مستقیماً در پرامپت سیستمی عامل هدف، تنها ۸۱.۰٪ / ۷۷.۵٪ دقت در دو بنچمارک به دست می‌آورد و باعث می‌شود عامل هدف در ۲۹.۲٪ / ۷۱.۰٪ از وظایف مشروع خود شکست بخورد — یک بده‌بستان غیرقابل قبول بین کارایی و امنیت.
• LlamaGuard ابزار اشتباهی برای این کار است. خط مبنای تعدیل محتوا (content moderation) تنها حدود ۵۰٪ دقت — نزدیک به شانس — به دست می‌آورد، زیرا برای متون مضر طراحی شده است، نه برای استدلال در مورد اینکه آیا یک اقدام عامل نقض‌کننده یک قانون کنترل دسترسی خاص است یا خیر.
• حذف جعبه‌ابزار حدود ۸ امتیاز هزینه دارد. بدون کتابخانه توابع قابل فراخوانی، دقت GuardAgent در EICU-AC از ۹۸.۷٪ به ۹۰.۸٪ کاهش می‌یابد، اگرچه با تعریف خودکار توابع مورد نیاز تا حدی آن را جبران می‌کند (۶۸٪ از خروجی‌ها حتی بدون دستور صریح کد تولید می‌کنند، که نویسندگان آن را به عنوان شواهد حمایتی برای طراحی مبتنی بر تولید کد تلقی می‌کنند).

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

بینش اصلی معماری — که اجرای کد یک نقطه اعمال قدرت قطعی به شما می‌دهد — واقعاً مفید است و تحلیل‌های کاهشی (ablations) صادقانه هستند. مقایسه با قواعد امنیتی کدگذاری شده بسیار متقاعدکننده است: نشان می‌دهد که طراحی‌های ساده‌لوحانه "فقط قواعد را به پرامپت اضافه کن" کارایی هدف را کاهش می‌دهند در حالی که هنوز در اعمال امنیت به طور قابل اعتماد شکست می‌خورند.

اما ارزیابی محدودیت‌های واقعی دارد. دو بنچمارک کوچک هستند (۳۱۶ و ۲۰۰ نمونه) و نویسندگان هر دو را ساخته‌اند که خطر بیش‌برازش (overfitting) آشکاری ایجاد می‌کند. EICU-AC اساساً یک ماتریس کنترل دسترسی (نقش × پایگاه داده) است که یک مسئله ساختاریافته و قابل شمارش است — نوعی مسئله که کد به طور طبیعی در آن خوب عمل می‌کند. Mind2Web-SC پیچیده‌تر است و رقم ۹۰.۰٪ در آنجا بسیار کمتر از آنچه در ابتدا به نظر می‌رسد چشمگیر است: نویسندگان اعتراف می‌کنند که قانون ۵ (مربوط به "فیلم، موسیقی و ویدئو") بیشترین شکست‌ها را ایجاد می‌کند زیرا نیاز به استدلال گسترده در دنیای باز دارد. این همان نوع قانونی است که یک عامل مالی واقعی دائماً با آن روبرو خواهد شد.

ماژول حافظه نمونه‌ها را بر اساس شباهت رشته‌ای بازیابی می‌کند، که برای انواع سیاست‌های تکراری خوب کار می‌کند اما در سیاست‌های واقعاً بدیع دچار افت عملکرد می‌شود. و کل چارچوب یک "بستر مورد اعتماد" را فرض می‌کند — خودِ سیاست‌های امنیتی باید توسط یک مدیر مورد اعتماد ارائه شوند. اگر مهاجم بتواند سیاست‌ها را تغییر دهد، یا اگر جعبه‌ابزار حاوی توابع ناامن باشد، GuardAgent هیچ حفاظتی ارائه نمی‌دهد. مقاله دستکاری خصمانه سیاست‌ها را مدل‌سازی نمی‌کند. کارهای بعدی (ShieldAgent، arXiv:2503.22738؛ AGrail، arXiv:2502.11448) قبلاً به این شکاف‌ها اشاره کرده‌اند و ShieldAgent بهبود میانگین ۱۱.۳٪ نسبت به GuardAgent را در بنچمارک‌های گسترده‌تر گزارش کرده است.

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

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

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

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

• ShieldAgent (arXiv:2503.22738, ICML 2025) — بر پایه GuardAgent با استدلال سیاست امنیتی قابل تأیید و ShieldAgent-Bench (۲ هزار نمونه در شش محیط وب) ساخته شده است؛ بهبود ۱۱.۳٪ نسبت به GuardAgent و کاهش ۶۴.۷٪ در فراخوانی‌های API را گزارش می‌دهد.
• AGrail (arXiv:2502.11448) — بررسی‌های امنیتی تطبیقی را پیشنهاد می‌کند که به جای نیاز به نمونه‌های مجزا برای هر وظیفه، بین وظایف عامل منتقل می‌شوند؛ مستقیماً به محدودیت مقیاس‌پذیری GuardAgent می‌پردازد.
• ToolSafe (arXiv:2601.10156) — گاردریل‌های پیشگیرانه در سطح گام با بازخورد برای عامل‌های فراخوان ابزار؛ دقیق‌تر از مدل رهگیری ورودی/خروجی GuardAgent.