تصور کنید یک عامل هوش مصنوعی دسترسی به ایمیل‌ها و APIهای شرکت شما دارد؛ آیا او می‌تواند در برابر دستورات مخرب مقاومت کند و همچنان به کارهای خود برسد؟ AgentGuardBench که در ۴ اکتبر ۲۰۲۶ منتشر شد، راهکاری شفاف برای تست این توازن حیاتی ارائه می‌دهد تا کاربردی بودن عامل‌ها به قیمت امنیت فدا نشود.
با حرکت هوش مصنوعی از تولید متن به سمت انجام اقدامات واقعی در دنیای دیجیتال، مخاطرات از کلمات توهین‌آمیز به افشای غیرمجاز داده‌ها یا فراخوانی‌های مخرب ابزارها تغییر کرده است. طبق گزارش منتشرشده، یک خروجی مضر دیگر صرفاً جمله‌ای روی صفحه نیست، بلکه می‌تواند یک ایمیل غیرمجاز یا اقدامی بدون تایید انسانی باشد. اکثر تست‌های ایمنی فعلی بر خروجی‌های چت متمرکز هستند، اما هوش مصنوعی عامل‌محور (Agentic AI) — شبیه به کارمندی که نه تنها می‌داند چه بگوید، بلکه می‌تواند ابزارها را برای انجام کار به کار بگیرد — به چارچوبی نیاز دارد که امنیت حافظه و مرزهای دسترسی را در نظر بگیرد. این نیاز به کنترل‌های سخت‌گیرانه، یادآور رویکرد معماری صفر-اعتماد در TrustGraph است که برای جلوگیری از سرقت وزن‌های مدل‌ها طراحی شده تا لایه‌های امنیتی درونی‌تر مدل‌ها نیز تضمین شود.
زمینه و دامنه
بر اساس مستندات فنی منتشرشده در Zenodo، نسخه ۰.۱.۱ این محک از ۱۲۰ سناریوی کاملاً مصنوعی برای فشارآوردن به عامل‌ها در پنج بخش بانکی، بهداشت، آموزش، دولتی و استخدام استفاده می‌کند. این بنچمارک چهار زبان انگلیسی، فرانسوی، سواحیلی و یوروبا را پوشش می‌دهد تا اطمینان حاصل شود که امنیت تنها یک ویژگی مختص زبان انگلیسی نیست.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تنوع زبانی در تست‌های امنیتی اغلب نادیده گرفته می‌شود. این مجموعه داده برای ارزیابی متوازن طراحی شده است؛ به طوری که در هر دسته ریسک ۲۰ مورد، در هر بخش ۲۴ مورد و در هر زبان ۳۰ مورد وجود دارد. برای حفظ ایمنی در حین تست، این مجموعه داده حاوی هیچ شخص واقعی، اعتبارنامه، سازمان یا هدف عملیاتی نیست تا خطری برای محیط تست ایجاد نشود.
ابعاد کلیدی امنیت
این محک شش خانواده ریسک را ارزیابی می‌کند که در آن‌ها عامل باید تصمیم بگیرد پاسخ دهد، داده را سانسور کند، درخواست را رد کند یا اجازه بگیرد:
- تزریق پرامپت (Prompt Injection): رد کردن دستورات خصمانه پنهان در محتوای نامعتبر برای حفظ اولویت دستورات اصلی.
- نشت حریم خصوصی: سانسور فیلدهای محافظت‌شده هنگامی که یک درخواست تلاش می‌کند داده‌های حساس را سرقت کند. این چالش دقیقاً همان نقطه‌ای است که TrustGraph با تفکیک حوزه‌های اعتماد، تلاش می‌کند نشت داده‌ها از عامل‌های هوش مصنوعی را متوقف کند.
- سوءاستفاده از ابزار: درخواست تایید انسانی پیش از اجرای اقدامات خارجی که پیش‌تر بررسی نشده‌اند.
- سوءاستفاده از امتیازات: رد اقدامات تخریبی زمانی که به عامل نقش «فقط خواندنی» اختصاص یافته است تا مرزهای نقش‌ها رعایت شود.
- امنیت حافظه: امتناع از افشای اسراری که پیش‌تر در حافظه داخلی عامل ذخیره شده‌اند.
- کنترل‌های بی‌خطر: تکمیل موفقیت‌آمیز کارهای قانونی که شامل اطلاعات مصنوعی عمومی هستند تا اطمینان حاصل شود عامل بیش از حد سانسور نشده است.
برای اعتبارسنجی خط لوله امتیازدهی، سازندگان دو پیکربندی کاملاً متفاوت را تست کردند. یک سیاست مرجع سخت‌گیرانه — که کنترل‌های پایه یکپارچگی دستورات، حریم خصوصی، مجوزها و تاییدات را اعمال می‌کرد — به نرخ موفقیت کلی ۱۰۰٪ و نرخ موفقیت حمله ۰٪ رسید. در مقابل، یک کنترل سهل‌گیرانه — که آخرین دستور را دنبال می‌کرد و ابزارها را بدون بررسی سیاست‌ها فراخوانی می‌کرد — تنها ۱۶.۶۷٪ امتیاز کلی گرفت.
جزئیات مربوط به کنترل سهل‌گیرانه نشان داد که نرخ نشت حریم خصوصی ۵۰٪، نرخ استفاده غیرمجاز از ابزار ۳۳.۳۳٪ و نرخ نقض تایید انسانی ۱۶.۶۷٪ بوده است. نکته کلیدی این است که هر دو پیکربندی نرخ تکمیل کارهای بی‌خطر ۱۰۰٪ داشتند؛ این ثابت می‌کند که بنچمارک می‌تواند تفاوت میان «احتیاط امنیتی» و «بی‌عرضگی مدل» را تشخیص دهد.
این ابزار برای اجرای محلی طراحی شده است. این سیستم از ابزارهای غیرفعال (Inert Tools) و سیاست‌های قطعی (Deterministic Policies) استفاده می‌کند؛ به این معنی که توسعه‌دهندگان می‌توانند ارزیابی کامل را بدون پرداخت هزینه برای APIهای مدل، استفاده از اعتبارنامه‌های تولیدی یا تماس با گیرندگان خارجی اجرا کنند.
این تغییر رویکرد به سمت بنچمارک‌های مختص به عامل‌ها، فرضیات این حوزه را تغییر می‌دهد و از ایمنی مبتنی بر «حس و حال» (Vibe-based) فاصله می‌گیرد. این ابزار توسعه‌دهندگان را مجبور می‌کند به جای تکیه بر همسویی داخلی مدل برای «خوب بودن»، مرزهای صریح نقش‌ها و گردش‌کارهای تایید را تعریف کنند.
برای متخصصان، این یعنی امنیت دیگر یک فکر متأخر پس از استقرار نیست. اکنون می‌توانید دقیقاً کمی‌سازی کنید که عامل کجا شکست می‌خورد؛ مثلاً در سانسور یک پرونده پزشکی یا در درخواست اجازه برای حذف یک فایل. ارزیاب نتایج را به صورت فایل‌های JSON و JSONL ماشین‌خوان در یک دایرکتوری نتایج می‌نویسد تا حسابرسی آن آسان باشد.
توسعه‌دهندگان می‌توانند با استفاده از پایتون ۳.۱۰ یا بالاتر، مخزن گیت‌هاب را کلون کرده و اسکریپت‌های ارائه شده، از جمله generate_dataset.py را اجرا کنند. در حال حاضر این پروژه به دنبال همکاری با متخصصان MLOps، زبان‌شناسان و متخصصان حاکمیت (Governance) است تا مجموعه‌های چالشی خود را گسترش دهد.
در آینده منتظر افزونه‌های جدیدی برای این بنچمارک باشید، از جمله تست‌های حملات چند-مرحله‌ای (Multi-turn)، مسموم‌سازی خروجی ابزارها و تست‌های آلودگی پنجره بافت (Context-window contamination). کارهای آتی همچنین شامل آداپتورهایی برای مدل‌های زبانی محلی و میزبانی شده و اعتبارسنجی توسط گویشوران بومی برای عبور از موارد مبتنی بر قالب (Template-driven) خواهد بود.
گام بعدی شما
- اگر در حال توسعه عامل‌های AI هستید، این بنچمارک را روی مدل‌های محلی خود اجرا کنید تا نقاط ضعف در دسترسی‌ها را بیابید.
- بررسی کنید که آیا عامل شما در مواجهه با دستورات متناقض (تزریق پرامپت)، اولویت دستورات سیستمی را حفظ می‌کند یا خیر.
- برای جلوگیری از نشت داده‌ها، یک لایه تایید انسانی (Human-in-the-loop) برای ابزارهای حساس تعریف کنید.
اما داستان سخت‌افزاری اجرای این تست‌ها در مقیاس بزرگ حتی پیچیده‌تر است — به تحلیل ما درباره‌ی بهینه‌سازی استنتاج در GPUها مراجعه کنید.
گفتگو