پروتکل ارتباطی مدل (Model Context Protocol یا به اختصار MCP) که در اواخر سال ۲۰۲۴ توسط Anthropic معرفی شد، به سرعت توسعه یافت و اکنون به عنوان یک زیرساخت حیاتی میان عامل‌های هوش مصنوعی (AI agents) و ابزارها یا داده‌های آن‌ها عمل می‌کند. با این حال، ارزیابی‌های فنی نشان می‌دهند که چالش اصلی امنیت این پروتکل نه در خود زیرساخت، بلکه در لایه مجوزها و دسترسی‌های زیرین آن نهفته است. بسیاری از سازمان‌ها این پروتکل را با تنظیمات پیش‌فرض نصب کرده‌اند که این امر مسیر را برای سوءاستفاده‌های امنیتی هموار کرده است.
بر اساس نظرسنجی تهدیدات هویت SANS که از میان بیش از ۵۰۰ کارشناس امنیتی انجام شده است، ۷۶ درصد از کسب‌وکارها با افزایش هویت‌های غیرانسانی مواجه شده‌اند و ۷۴ درصد آن‌ها از سیستم‌های هوش مصنوعی استفاده می‌کنند که برای فعالیت مستقل به اعتبارنامه‌های دائمی متکی هستند. این در حالی است که کمتر از ۴۰ درصد این شرکت‌ها از اقدامات حفاظتی مانند فرآیندهای تأیید، محیط‌های ایزوله (Sandboxing) یا ثبت وقایع (Logging) استفاده می‌کنند.
نمونه‌های واقعی این آسیب‌پذیری‌ها پیش از این نیز مشاهده شده است. در مه ۲۰۲۵، یک مهاجم با استفاده از تزریق پرامپت (Prompt Injection) به سرور MCP پلتفرم GitHub توانست داده‌های مخازن خصوصی را استخراج کند؛ این اتفاق نه به دلیل باگ نرم‌افزاری، بلکه به خاطر تعریف بیش از حد گسترده دامنه دسترسی توکن شخصی رخ داد. همچنین نقص منطقی در ادغام MCP پلتفرم Asana به دلیل عدم اعمال مرزهای ایزوله‌سازی میان مشتریان، اجازه دسترسی بین‌مستأجری (Cross-tenant) را صادر کرد. پژوهشگران این تهدیدات را در قالب الگوهایی چون «مسموم‌سازی ابزار» (Tool Poisoning) و «مسئله نماینده سردرگم» (Confused Deputy Problem) دسته‌بندی می‌کنند.
راهکارهای پیشنهادی برای ایمن‌سازی MCP
برای حل این بحران، کارشناسان به جای اسکنرهای قوی‌تر، بر بخش‌بندی دسترسی‌ها تأکید دارند. وبلاگ مهندسی GitHub پیشنهاد می‌کند که هر نمونه باید کلیدهای اختصاصی خود را برای وظایف مشخص داشته باشد و توکن‌های ثابت و دائمی با اعتبارنامه‌های پویا و موقت جایگزین شوند.
سازمان‌ها هنگام ادغام هرگونه MCP باید موارد زیر را ارزیابی کنند:
- بررسی دامنه دسترسی: آیا اعتبارنامه فراتر از وظیفه تعریف‌شده خود دسترسی دارد؟
- سطح دسترسی جزئی: آیا مجوزها به صورت موردی (مانند هر مخزن یا محیط کاری) صادر می‌شوند یا به صورت کلی و همه‌جانبه؟
- ارث‌بری مجوزها: آیا عامل هوش مصنوعی مجوزهای کاربر را به ارث می‌برد یا اعتبارنامه‌های کاملاً جدیدی ایجاد می‌کند که محدودیت‌ها را دور می‌زند؟
- ثبت وقایع (Logging): آیا فعالیت‌های عامل هوش مصنوعی به اندازه یک کاربر انسانی قابل ردیابی و پاسخگویی است؟
- فرآیند بازبینی پیش از تولید: آیا تغییرات اعمال‌شده توسط عامل مستقیماً وارد فاز عملیاتی می‌شوند یا ابتدا از مراحل پیش‌نویس و تأیید عبور می‌کنند؟
بحران هویت عامل‌های هوش مصنوعی
بسیاری از کارشناسان معتقدند عامل‌های هوش مصنوعی در حال حاضر هویت مستقلی ندارند و صرفاً از توکن‌های OAuth کاربران انسانی استفاده می‌کنند. این مدل برای عامل‌های کوتاه‌مدت شاید کارآمد باشد، اما با ظهور عامل‌هایی که هفته‌ها یا ماه‌ها فعال می‌مانند، استفاده از هویت‌های عاریتی خطرناک است. پروتکل OAuth برای فرآیندهای بدون حضور انسان طراحی نشده است و مدل‌های رضایت‌سنجی آن در این سناریو کارایی ندارند. اگرچه پیش‌نویس‌هایی در IETF برای پیوند دادن طول عمر توکن به چرخه حیات وظایف و تخصیص هویت‌های پایدار به عامل‌ها در حال بررسی است، اما این طرح‌ها هنوز به استانداردهای نهایی و پیاده‌سازی‌شده تبدیل نشده‌اند.