اگر فکر می‌کنید اجرای سرورهای ابزاری بر روی localhost امن است، احتمالاً در حال باز گذاشتن درِ پشتی سیستم خود برای مهاجمان هستید. یک توصیف ابزار آسیب‌پذیر می‌تواند مدل زبانی بزرگ را فریب دهد تا کلیدهای خصوصی شما را استخراج کند.
به نقل از ادیسون فلورز (Edison Flores)، پژوهشگر امنیت، در ۲ ژوئیه ۲۰۲۶ هشدار داده شد که سرورهای MCP مانند سطوح جدیدی برای حملات API عمل می‌کنند. این پروتکل به مدل‌ها قابلیت‌های دنیای واقعی مثل دسترسی به سیستم فایل، پرس‌وجو از پایگاه‌داده، اجرای کد و فراخوانی‌های API را می‌دهد؛ اما اگر فیلترهای امنیتی کافی نباشند، یک توصیف ابزارِ به معرض دست‌کاری درآمده می‌تواند مدل زبانی بزرگ (LLM) را فریب دهد تا کلیدهای خصوصی شما را استخراج کرده و به بیرون ارسال کند. این ریسک‌های امنیتی با یافته‌های اخیر همخوانی دارد، چرا که برخی گزارش‌ها نشان می‌دهد ۲۰٪ از تنظیمات عامل‌های هوش مصنوعی دارای حفره‌های امنیتی بحرانی هستند.
مغالطه لوکال‌هاست (The Localhost Fallacy)
همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد به ورودی‌های غیرمتنی یک اشتباه استراتژیک است. در دنیای پروتکل زمینه مدل (MCP) — که شبیه به یک مترجم است و اجازه می‌دهد هوش مصنوعی با نرم‌افزارهای محلی و دوردست شما صحبت کند — بسیاری از توسعه‌دهندگان به اشتباه تصور می‌کنند محیط localhost یک مرز امن است. اما در واقعیت، این یک مانع امنیتی مؤثر در ماشین‌های مشترک یا محیط‌های توسعه نیست. فقدان احراز هویت به این معناست که هر پردازشی که روی آن ماشین در حال اجراست، پتانسیل فراخوانی سرور را دارد.
سطح حمله جدید
از آنجایی که LLMها در اینجا نقش «فراخوان‌کننده» (Caller) را دارند، می‌توان آن‌ها را از طریق تزریق دستور (Prompt Injection) در خودِ توصیفات ابزارها دست‌کاری کرد. اگر متادیتای ابزار به جای اینکه به عنوان یک «ورودی غیرقابل اعتماد» دیده شود، صرفاً به عنوان «مستندات» تلقی شود، مدل را می‌توان فریب داد تا توکن‌ها را افشا کند یا دستورات غیرمجاز را اجرا نماید. این نوع نشت داده‌ها می‌تواند منجر به پیامدهای وخیمی شود، مشابه آنچه در گزارش نشت کلیدهای خصوصی کیف‌پول‌ها از طریق روترهای واسط هوش مصنوعی مشاهده شد.
بر اساس گزارش dev.to، ایمن‌سازی این سرورها نیازمند یک ممیزی دقیق ۶ مرحله‌ای است:
- احراز هویت (Authentication): بررسی اینکه آیا سرور برای پاسخگویی به توکن‌ها، شناسه‌های نشست (Session IDs) یا API Keyها نیاز دارد یا خیر. بسیاری از سرورها بدون هیچ احراز هویتی به یک پورت متصل می‌شوند و به اشتباه فرض می‌کنند دسترسی فقط محلی است.
- تزریق در توصیف ابزار (Tool Description Injection): جست‌وجوی متادیتا برای یافتن دستوراتی نظیر «دستورات قبلی را نادیده بگیر»، «تو اکنون... هستی» یا «نقش جدید تو این است». پژوهشگران به دنبال دستوراتی می‌گردند که مدل را وادار به خواندن فایل‌های اعتبارنامه یا «افشا/خروجی دادن» اسرار و کلیدها کند.
- اعتبارسنجی ورودی (Input Validation): تست برای جلوگیری از حملات Path Traversal (مانند
../../../etc/passwd)، تزریق SQL (مانند' OR 1=1 --)، تزریق دستورات سیستمی (مانند; cat /etc/shadow #) و حملات SSRF که متادیتای کلاود را هدف قرار می‌دهند (مانندhttp://169.254.169.254/latest/meta-data/). - سیاست CORS/Origin: اطمینان از اینکه پیکربندی
*(اجازه به همه مبدأها) برای سرورهایی که از طریق مرورگر قابل دسترس هستند، فعال نباشد؛ زیرا در غیر این صورت هر وب‌سایتی می‌تواند به سرور MCP درخواست بفرستد. - دامنه دسترسی OAuth: بررسی اینکه توکن‌های مربوط به سرویس‌های خارجی مانند گیت‌هاب، اسلک یا گوگل از حداقل دسترسی‌های لازم استفاده کنند و به جای دسترسی محدود، دسترسی کامل (God Mode) نداشته باشند.
- جلوگیری از نشت خطا (Error Leakage): تأیید اینکه درخواست‌های بدساخت یا ورودی‌های سریع و متوالی، باعث نشت Stack Traceها، کلیدهای API یا هدرهای محدودیت نرخ (Rate-limit) نشود، چرا که این موارد استراتژی‌های محدودسازی سرور را فاش می‌کنند.
برای خودکارسازی این فرآیند، فلورز ۱۸ قانون Semgrep و یک سندباکس داکر (Docker Sandbox) تخصصی طراحی کرده است. این محیط ایزوله، سرورها را با پرچم‌های سخت‌گیرانه اجرا می‌کند: --network none برای قطع کامل اینترنت، سیستم فایل --read-only برای جلوگیری از تغییرات و حذف تمام قابلیت‌های لینوکسی با --cap-drop ALL.
نظارت بر زمان اجرای تقابعی (Adversarial Runtime Monitoring)
این ساختار به پژوهشگر اجازه می‌دهد رصد کند که آیا یک ابزار به‌ظاهر ساده برای «فرمت متن»، در زمان اجرا مخفیانه سعی می‌کند فایل حساس ~/.ssh/id_rsa را بخواند یا خیر. این سندباکس به‌طور ویژه موارد زیر را مانیتور می‌کند:
- خروجی استاندارد (stdout): برای یافتن هرگونه اشاره به اعتبارنامه‌ها، URLها یا تلاش‌های اجرایی.
- تغییرات سیستم فایل: از طریق دستور
docker diffجهت شناسایی هرگونه دست‌کاری در فایل‌ها. - تلاش‌های شبکه: در جایی که خطای
ECONNREFUSEDنشان‌دهنده یک تلاش ناموفق برای «گزارش به خانه» یا ارسال داده‌ها به سرور مهاجم است. - رفتار در هنگام کرش: بررسی واکنش سرور تحت استرس‌های تقابعی.
این رویکرد، معیار استقرار MCP را از تست‌های عملکردی ساده به «ممیزی تقابعی» تغییر می‌دهد. تحلیل استاتیک به تنهایی کافی نیست، زیرا رفتارهای مخرب اغلب تنها در زمان اجرا فعال می‌شوند. با خنثی کردن دسترسی شبکه از طریق پرچم --network none داکر، توسعه‌دهندگان می‌توانند رایج‌ترین حملات استخراج داده را متوقف کنند، حتی اگر کد زیربنایی سیستم آلوده شده باشد.
مدیریت این اعتبارنامه‌ها در میان چندین ایجنت و هویت‌های مختلف کاربری، لایه‌های پیچیدگی جدیدی را اضافه می‌کند. در حالی که کلیدهای استاتیک سریع هستند، محیط‌های عملیاتی (Production) در حال انتقال به سمت OAuth 2.1 با PKCE یا گیت‌وی‌های متمرکز برای مدیریت احراز هویت در مقیاس بالا هستند. در این زمینه، بررسی نحوه استفاده از گیت‌وی مرکزی برای مدیریت دسترسی ۱۲ سرور MCP می‌تواند دیدگاه جامع‌تری درباره استقرار امن در مقیاس صنعتی ارائه دهد.
در نهایت، توسعه‌دهندگان باید نگاه خود را تغییر دهند و متادیتای ابزارها را نه به عنوان مستندات، بلکه به عنوان ورودی‌های غیرقابل اعتماد (Untrusted Input) ببینند. برای شروع، می‌توانید سرور خود را با درخواست‌های خام JSON-RPC و ابزار nc (Netcat) تست کنید تا پاسخ واقعی سرور را بدون واسطه و ماسکِ کلاینت‌های گرافیکی ببینید. برای مثال، ارسال پیام {"jsonrpc":"2.0","method":"initialize","params":{},"id":1} به localhost 3123 پاسخ واقعی و عریان سرور را فاش می‌کند.
گام بعدی شما
- تمام توصیفات ابزارهای خود را از نظر عبارات تزریقی (Injection) بازبینی کنید.
- سرور MCP خود را در یک کانتینر Docker با دسترسی شبکه محدود تست کنید.
- از احراز هویت توکن‌محور حتی برای دسترسی‌های داخلی استفاده کنید.
گفتگو