«در نظر گرفتن یک مدل زبانی بزرگ به عنوان مرز امنیتی، نسخه‌ای برای فاجعه است.» این هشدار تند در تحلیل فنی منتشر شده در ۳ سپتامبر ۲۰۲۶ در وب‌سایت dev.to، نتیجه می‌گیرد که تنها راه عملی برای ایمن‌سازی فراخوانی ابزارها در سیستم‌های عامل‌محور، قرار دادن یک پراکسی قطعی (Deterministic Proxy) بین مدل و سرورها است.
این تغییر معماری در حالی رخ می‌دهد که پروتکل زمینهٔ مدل (Model Context Protocol یا MCP) در حال استانداردسازی نحوه شناسایی و فراخوانی ابزارها توسط عامل‌ها است. اگرچه MCP تعامل‌پذیری را بهبود می‌بخشد، اما یک سطح پروتکل مشترک ایجاد می‌کند که مهاجمان می‌توانند به‌طور یکسان در پیاده‌سازی‌های مختلف هدف قرار دهند. همان‌طور که در تحلیل قبلی ما درباره‌ی ساخت rubrics برای مدل‌های زبانی به‌مثابه داور اشاره کردیم، صنعت اکنون با نیاز مشابهی به حفاظ‌های سخت‌گیرانه و غیر احتمالی در اجرای عامل‌ها مواجه است. در همین راستا، راهکارهای جدیدی مانند لایه‌ی حاکمیتی Bifrost برای بستن حفره‌های امنیتی MCP در حال ظهور هستند تا کنترل متمرکزی بر ابزارها ایجاد کنند.
ریشه‌های تهدید
به نقل از نویسندگان این تحلیل، ما با یک مشکل قدیمی رو‌به‌رو هستیم که لباس جدیدی به تن کرده است. اگر عبارت «سرور MCP» را با «پایگاه‌داده» و «تزریق پرامپت» را با «تزریق SQL» جایگزین کنید، روایت کاملاً یکسان است: ورودی‌های غیرقابل‌اعتماد به سیستمی می‌رسند که سطح دسترسی آن بسیار بالاتر از چیزی است که ورودی باید اجازه فراخوانی‌اش را داشته باشد.
تفاوت اصلی در ماهیت ورودی غیرقابل‌اعتماد است. ورودی دیگر فقط یک فیلد فرم نیست؛ بلکه صفحه‌ای است که عامل خوانده، سندی است که خلاصه کرده یا پاسخی از یک ابزار است که جذب کرده است. در واقع، خودِ مدل است که مورد مهندسی اجتماعی قرار می‌گیرد.
تصور کنید عاملی صفحه‌ای را می‌خواند که حاوی دستور پنهانی برای حذف یک پایگاه‌داده است. اگر مدل تنها نهاد اجراکننده سیاست‌های امنیتی باشد، در واقع یک قربانی ساده است که هم‌زمان نقش بازرس تقلب را هم ایفا می‌کند. این ریسک فراتر از یک تزریق پرامپت تئوریک است و یک شکست بنیادین در کنترل دسترسی محسوب می‌شود. این نوع آسیب‌پذیری‌ها مستقیماً با اصول پنج‌گانه‌ی جلوگیری از نشت داده‌ها در عامل‌های هوش مصنوعی در تضاد است که بر جداسازی محیط‌های اجرا تأکید دارند.
جزئیات فنی و راهکارهای کاهش ریسک
بر اساس مستندات فنی ارائه شده، توسعه‌دهندگان برای مقابله با این تهدید باید الگوهای معماری زیر را پیاده کنند:
- اجرای قطعی (Deterministic Enforcement): منطق سیاست‌های امنیتی را به پراکسی منتقل کنید که مدل زبانی بزرگ به آن دسترسی ندارد و نمی‌تواند با استدلال آن را دور بزند. نقطه اجرا باید جایی باشد که محموله (Payload) مهاجم به آن دسترسی نداشته باشد.
- حداقل دسترسی (Least Privilege): با هر قصد فراخوانی ابزار از سوی مدل، مانند درخواستی از یک کلاینت غیرقابل‌اعتماد برخورد کنید. مدل یک کاربر است، نه مدیر سیستم.
- رد پیش‌فرض (Deny-by-Default): اطمینان حاصل کنید که دسترسی‌ها به‌طور صریح اعطا می‌شوند، نه اینکه به مدل تکیه کنید تا برای اجتناب از برخی اقدامات، «دستورات را دنبال کند».
- اعتبارسنجی خارجی: تمام قصدها را بر اساس سیاستی اعتبارسنجی کنید که خارج از مرز اعتمادِ موجودیت تحت تأثیر قرار گرفته، قرار دارد.
این رویکرد، یک رشته جدید به نام «امنیت AI» نیست، بلکه همان کنترل دسترسی کلاسیک است که روی یک قرارداد فراخوانی جدید اعمال شده است. نوآوری اینجاست که صنعت، قابلیت فراخوانی ابزار توسط عامل‌ها را پیش از ارائه چیزی شبیه به دیواره آتش (Firewall) برای آن، عرضه کرد. ادعای کسانی که می‌گویند امنیت AI نیازمند بازتعریف امنیت از اصول اولیه است، اغلب با هدف فروش محصولات جدید مطرح می‌شود.
برای تیم‌های فنی، این موضوع فرض بنیادین درباره پرامپت سیستمی (System Prompt) را تغییر می‌دهد. یک هشدار شدید به مدل برای دنبال نکردن دستورات جاسازی‌شده، صرفاً یک «پیشنهاد» است، نه یک کنترل امنیتی. پیشنهادها در برابر ورودی‌های خصمانه دوام نمی‌آورند.
تیم‌های امنیتی اکنون باید استقرار عامل‌ها را با همان دقت بازبینی معماریِ یک سرویس دارای دسترسی ویژه بررسی کنند. تفاوت اصلی این است که «کلاینت» درخواست‌کننده، غیرقطعی است و هر محتوای خارجی دلخواهی را به عنوان دستور احتمالی مصرف می‌کند. این یک مدل تهدید واقعاً متفاوت است، حتی اگر الگوی رفع آن آشنا باشد. برای مقابله با خروج غیرمجاز داده‌ها در این مدل تهدید، می‌توان از سازوکار TrustGraph برای محدود کردن خروجی‌ها بهره برد تا از نشت اطلاعات حساس جلوگیری شود.
با ادغام تدریجی اجرای سیاست‌ها در فریم‌ورک‌های عامل‌محور، تضاد جدیدی بر سر مالکیت این سیاست‌ها شکل خواهد گرفت. صنعت باید تصمیم بگیرد که آیا تامین‌کننده پلتفرم، توسعه‌دهنده اپلیکیشن یا تیم امنیتی مالک سیاست‌هاست و کاربران تا چه حد اصطکاک امنیتی را تحمل می‌کنند.
گام بعدی شما
- بررسی مجدد تمام پرامپت‌های سیستمی و جایگزینی دستورات «نکن» با لایه‌های اعتبارسنجی کد در سطح API.
- پیاده‌سازی یک لایه Middleware برای بررسی دسترسی‌های هر ابزار (Tool) پیش از اجرای نهایی.
- تست نفوذ روی عامل‌ها با استفاده از داده‌های خارجی آلوده برای شناسایی نقاط ضعف در کنترل دسترسی.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو