استفاده تاییدپذیر و امن از ابزارها برای عامل‌های مدل زبانی بزرگ: تلاقی STPA و MCP

مدتی است که ادبیات مربوط به گاردریل‌ها (Guardrail) را دنبال می‌کنم — GuardAgent، ShieldAgent، AGrail — و همه آن‌ها نرخ تشخیص را بهبود می‌بخشند در حالی که در سکوت اعتراف می‌کنند که در واقع نمی‌توانند هیچ چیزی را تضمین کنند. این مقاله ICSE NIER 2026 از دوشی و همکاران در CMU و NC State زاویه متفاوتی را انتخاب می‌کند: به جای اینکه بپرسند چگونه رفتار بد عامل را با اطمینان بیشتری شناسایی کنیم، می‌پرسند چگونه رفتار ناامن را از نظر رسمی غیرممکن کنیم. این یک مقاله موضع‌گیری (Position Paper) است، نه یک مطالعه تجربی، اما چارچوب‌بندی آن به قدری دقیق هست که ارزش خواندن دقیق را داشته باشد.

مقاله

مقاله "به سوی استفاده تاییدپذیر و امن از ابزارها برای عامل‌های مدل زبانی بزرگ" (arXiv:2601.08012) توسط آریا دوشی، اینینگ هونگ، کونگ‌ینگ شو، اونسوک کانگ، الکساندروس کاپراولوس و کریستین کستنر، متدولوژی جدیدی را برای استخراج و اجرای مشخصات ایمنی بر استفاده عامل‌های LLM از ابزارها پیشنهاد می‌دهد. مشاهده اصلی این است که ریسک‌ها در سیستم‌های عاملی عمدتاً از ترکیب ابزارها ناشی می‌شوند — نه از شکست ابزارهای منفرد — بنابراین اقدامات حفاظتی در سطح مؤلفه نمی‌توانند آن‌ها را شناسایی کنند. عاملی که یک تداخل در تقویم را حل می‌کند، ممکن است به درستی یک پرونده سلامت خصوصی را جستجو کند و به درستی یک ایمیل ارسال کند، اما در عین حال کاری فاجعه‌بار انجام دهد: افشای محتوای آن پرونده برای همکاران بیمار.

راهکار پیشنهادی دارای دو بخش است. اول، نویسندگان از آنالیز فرآیند تئوری سیستم (STPA)، یک روش مهندسی ایمنی از سیستم‌های هوانوردی و هسته‌ای، برای شناسایی خطرات در سطح عامل، استخراج الزامات ایمنی و رسمی‌سازی آن‌ها به عنوان مشخصاتی برای جریان‌های داده و توالی ابزارها استفاده می‌کنند. دوم، آن‌ها یک چارچوب پروتکل کانتکست مدل (MCP) ارتقا یافته با قابلیت‌ها را معرفی می‌کنند که در آن هر ابزار باید متادیتای ساختاریافته‌ای را اعلام کند: سطح قابلیت (فقط خواندنی، فقط نوشتنی، خواندنی-نوشتنی، اجرا)، طبقه‌بندی محرمانگی و سطح اعتماد. سپس اجرا در چهار سطح ساختاردهی می‌شود: لیست مسدود (blocklist) خودکار برای جریان‌های اثباتاً ناامن، لیست الزامی (mustlist) برای توالی‌های مورد نیاز، لیست مجاز (allowlist) برای عملیات‌های از پیش تایید شده و ارجاع برای تایید (confirmation) در موارد مبهم.

مرحله تایید رسمی از Alloy، یک ابزار منطق رابطه‌ای مرتبه اول، برای مدل‌سازی فضای اجرا و بررسی جامع استفاده می‌کند تا اطمینان حاصل شود که تحت سیاست‌های اعلام شده، نقض ایمنی رخ نمی‌دهد در حالی که مسیرهای امن همچنان قابل دسترس باقی می‌مانند. این "نتیجه" اصلی مقاله است — هیچ عدد دقت بنچمارکی وجود ندارد، که برای یک مقاله کوتاه NIER انتظار می‌رود.

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

• STPA ایمنی عامل را به عنوان یک مسئله مهندسی سیستم بازتعریف می‌کند: شناسایی خسارات، ردیابی به عقب از طریق تعاملات خطرناک، استخراج الزامات — پیش از نوشتن هرگونه کد اجرایی.
• مشخصات به دو نوع تقسیم می‌شوند: محدودیت‌های جریان اطلاعات ("ایمیل‌های رویداد نباید شامل داده‌های خصوصی باشد که متعلق به گیرنده نیست") و محدودیت‌های منطق زمانی ("هر update_event باید با یک send_email به هر شرکت‌کننده دنبال شود").
• اجرای چهار سطحی (blocklist / mustlist / allowlist / confirmation) برای کاهش خستگی امنیتی طراحی شده است — بیشتر جریان‌های امن از پیش تایید شده‌اند، بنابراین عامل مدام اجازه نمی‌گیرد.
• آنالیز جامع مسیرها توسط Alloy، عدم وجود جریان‌های ناامن را در مطالعه موردی تقویم تایید کرد و در عین حال عملکرد وظایف را حفظ نمود.
• کل رویکرد صراحتاً برای عامل‌های مخصوص وظیفه (task-specific) در نظر گرفته شده است، نه دستیارهای عمومی — نویسندگان اذعان دارند که تامین امنیت عامل‌های محدود امکان‌پذیرتر است.

چه چیزی منطقی است — و چه چیزی نیست

حرکت فکری درست است: قرض گرفتن STPA از مهندسی ایمنیِ حساس، غریزه درستی است. برخلاف گاردریل‌های احتمالی، این رویکرد الزامات را به گزاره‌هایی روی مسیرهای سیستم تبدیل می‌کند که به جای تخمین زدن، قابل تایید هستند. سلسله مراتب اجرای چهار سطحی متفکرانه طراحی شده است — تمایز بین لیست مسدود و تایید به ویژه اهمیت دارد، زیرا درخواست‌های تایید دائمی باعث فرسایش اعتماد کاربر شده و نادیده گرفته می‌شوند.

با این حال، محدودیت‌های مقاله قابل توجه هستند و عمدتاً بی‌پاسخ مانده‌اند. مشکل "اعتماد به متادیتا" شناسایی شده اما حل نشده است: کل چارچوب به این بستگی دارد که توسعه‌دهندگان ابزار، ابزارهای خود را به درستی برچسب‌گذاری کنند. در یک بازار باز MCP که ابزارهای شخص ثالث رایج هستند، هیچ مکانیزم اجرایی برای صحت برچسب‌ها وجود ندارد. تایید رسمی نیز روی یک مدل اسباب‌بازی Alloy دست‌ساز انجام شده است — این نشان‌دهنده امکان‌پذیری رویکرد است، نه اینکه این رویکرد بتواند در مقیاس وسیع روی سیستم‌های واقعی اعمال شود.

همچنین من استدلال متقاعدکننده‌ای نمی‌بینم که چرا STPA روش تحلیل خطر مناسبی در مقابل، مثلاً، مدل‌سازی تهدید یا HAZOP است. مطالعه موردی تقویم آموزنده است اما به طرز ساده‌ای کوچک است. و هیچ بحثی در مورد ارائه‌دهندگان ابزار متخاصم که عمداً قابلیت‌ها را اشتباه برچسب‌گذاری می‌کنند وجود ندارد — که یک سطح حمله واقعی است که ادبیات امنیتی مرتبط با MCP (arXiv:2601.17549) به تفصیل بررسی می‌کند.

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

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

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

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

قطعه گمشده در حال حاضر این است که هیچ‌کدام از این‌ها ساخته و آزمایش نشده است. اما به عنوان یک واژگان طراحی برای فکر کردن به ایمنی عامل‌های دفتر کل، ترکیب STPA + IFC اصولی‌ترین چارچوبی است که تاکنون در این ادبیات دیده‌ام.

چه چیزی را بعداً بخوانیم

• "تامین امنیت عامل‌های هوش مصنوعی با کنترل جریان اطلاعات" — arXiv:2505.23643، Microsoft Research؛ یک سیستم IFC بتنی (Fides) را با ردیابی آلودگی پیاده‌سازی می‌کند که روی AgentDojo ارزیابی شده است؛ مکمل تجربی این مقاله.
• "شکستن پروتکل: تحلیل امنیتی مشخصات پروتکل کانتکست مدل و آسیب‌پذیری‌های تزریق پرامپت در عامل‌های LLM یکپارچه با ابزار" — arXiv:2601.17549؛ مستقیماً سطح حمله MCP را تحلیل می‌کند که چارچوب این مقاله قصد دفاع از آن را دارد.
• "تحلیل سیستماتیک خطر برای هوش مصنوعی پیشرو با استفاده از STPA" — arXiv:2506.01782؛ کاربرد جدیدتری از متدولوژی STPA در سیستم‌های هوش مصنوعی به طور کلی، مفید برای درک چگونگی مقیاس‌پذیری این تکنیک.