محققان امنیتی موفق شدند ۶ مورد از پرکاربردترین فریم‌ورک‌های عامل هوش مصنوعی (AI Agent Frameworks) را فریب دهند تا Tool Callهایی را که توسط مهاجم نوشته شده‌اند، اجرا کنند. این حمله تنها با درخواست از مدل برای تکرار یک عبارت خاص صورت می‌گیرد.
جزئیات تکنیک Repeat-After-Me
این روش که Repeat-After-Me نامیده شده، روی فریم‌ورک‌های زیر آزمایش و تایید شده است:
- LangGraph (متعلق به LangChain)
- Microsoft Agent Framework
- Microsoft AutoGen
- Google Agent Development Kit 2.0
- AWS Strands Agents
- CrewAI
در این سناریو، مهاجم از مدل می‌خواهد متنی را تکرار کند که در واقع یک درخواست برای فراخوانی یک ابزار (Tool Invocation) است. در ابتدا، مدل ممکن است درخواست خطرناک را رد کند، اما متن مورد نظر را در پاسخ خود می‌آورد. در مرحله بعد، محققان با قرار دادن درخواست در یک قالب فرضی (Hypothetical)، مدل را مجبور کردند تا فقط متن ارسالی را بازتولید کند. در این حالت، مدل یک Tool Invocation ساختاریافته صادر کرد و لایه ارکستراتور (Orchestrator) بدون بررسی مجدد، آن را اجرا نمود.
ضعف در معماری ارکستراتور
محققان اشاره کردند که در این حملات، متن رد درخواست (Refusal text) با دستور اجرا شده در تضاد است؛ به این معنا که System Prompt تنها بر آنچه مدل «می‌گوید» تاثیر گذاشته، اما بر آنچه ارکستراتور «انجام می‌دهد» تاثیری نداشته است. این موضوع نشان‌دهنده یک ضعف معماری است، جایی که لایه ارکستراتور، خروجی مدل را به عنوان مجوز کافی برای اجرای عملیات در نظر می‌گیرد.
آسیب‌پذیری در سرورهای MCP
علاوه بر این، تیم تحقیق ابزاری برای تست سرورهای Model Context Protocol (MCP) توسعه دادند که منجر به شناسایی باگ‌های امنیتی در ۱۱۸ سرور از ۲۷۳ سرور متن‌باز شد. جدی‌ترین این آسیب‌پذیری‌ها عبارتند از:
- ۶۴ مورد Path Traversal
- ۷ مورد Server-Side Request Forgery (SSRF)
- ۵ مورد نشت داده‌ها (Data Exfiltration)
- ۳ مورد OS Command Injection
بسیاری از این ابزارها به اشتباه فرض کرده‌اند که مدل LLM ورودی‌ها را پاک‌سازی (Sanitize) می‌کند، در حالی که ورودی‌ها می‌توانند توسط محتوای بازیابی شده یا خروجی ابزارهای دیگر تحت تاثیر قرار گیرند.
توصیه‌های امنیتی برای مدیران SOC و CISOها
برای مقابله با این تهدیدات، جداسازی توانایی مدل در «درخواست اقدام» از «مجauthority سیستم برای اجرا» ضروری است. توصیه‌های کلیدی عبارتند از:
- اعتبارسنجی مستقل: هر Tool Call حساس باید تحت بررسی‌های مجوز (Authorization) مستقل قرار گیرد.
- محدود کردن دسترسی‌ها: اجرای عامل‌ها در محیط‌های ایزوله (Isolated Environments) با دسترسی‌های محدود به فایل و شبکه.
- نظارت بر توالی دستورات: به جای بررسی هر اقدام به صورت مجزا، باید توالی Tool Callها را مانیتور کرد تا الگوهای مشکوک شناسایی شوند.
- اعتبارسنجی ورودی در سطح ابزار: ابزارها نباید به LLM برای پاک‌سازی ورودی‌ها اعتماد کنند و باید خودشان محدودیت‌های دسترسی را اعمال نمایند.
