امنیت MCP چیست؟ راهنمای ایمن‌سازی ایجنت‌ های هوش مصنوعی

اتصال ایجنت‌های هوش مصنوعی به دیتابیس‌ها، فایل‌ها و APIهای خارجی، امکان انجام کارهایی فراتر از تولید متن را فراهم می‌کند. پروتکل MCP این ارتباط را استاندارد می‌کند، اما دسترسی ایجنت به ابزارها می‌تواند خطرهایی مانند افشای اطلاعات، اجرای عملیات غیرمجاز و سوءاستفاده از اعتبارنامه‌ها ایجاد کند.

برای مثال، اگر یک ایجنت به مخزن GitHub و دیتابیس خصوصی دسترسی داشته باشد، دستورالعمل مخرب در متن یک Issue ممکن است آن را به استفاده نادرست از ابزارهایش هدایت کند. امنیت MCP برای کاهش چنین خطرهایی به کنترل دسترسی، اعتبارسنجی درخواست‌ها و محدودسازی عملیات ایجنت متکی است.

در این مقاله بررسی می‌کنیم امنیت MCP چیست، چه تهدیدهایی دارد و با چه روش‌هایی می‌توان ایجنت‌های متصل به ابزارهای خارجی را ایمن‌تر کرد.

در ادامه می‌خواهید:

• امنیت MCP چیست؟
• چرا MCP سطح حمله ایجنت‌های هوش مصنوعی را افزایش می‌دهد؟
• مهم‌ترین تهدیدهای امنیتی MCP کدام‌اند؟
• چگونه امنیت MCP را افزایش دهیم؟
• نمونه واقعی آسیب‌پذیری MCP و روش جلوگیری از آن
• تفاوت امنیت MCP با امنیت API چیست؟
• چک‌لیست امنیت MCP پیش از استفاده در محیط عملیاتی
• سوالات متداول درباره امنیت MCP
• جمع‌بندی

امنیت MCP چیست؟

امنیت MCP یا MCP Security به مجموعه‌ای از کنترل‌ها و روش‌های حفاظتی گفته می‌شود که از ارتباط ایجنت‌های هوش مصنوعی با ابزارها، داده‌ها و سرویس‌های خارجی از طریق پروتکل زمینه مدل (Model Context Protocol) محافظت می‌کنند.

در معماری MCP، برنامه میزبان (Host) ارتباط ایجنت با سرورهای MCP را از طریق کلاینت‌ها مدیریت می‌کند. هر سرور می‌تواند ابزارهایی برای خواندن اطلاعات، اجرای دستورات یا فراخوانی API در اختیار برنامه قرار دهد. امنیت این ارتباط به این بستگی دارد که چه کسی به ابزارها دسترسی دارد، هر ابزار چه عملیاتی می‌تواند انجام دهد و درخواست‌ها چگونه بررسی می‌شوند.

برای مثال، ایجنتی که وظیفه بررسی سفارش‌های یک فروشگاه را دارد، ممکن است فقط به خواندن وضعیت سفارش نیاز داشته باشد. اگر همان ایجنت مجوز حذف سفارش‌ها یا استخراج اطلاعات تمام مشتریان را هم دریافت کند، یک درخواست اشتباه یا دستورالعمل مخرب می‌تواند پیامد جدی‌تری داشته باشد.

به همین دلیل، ایمن‌سازی MCP تنها به محافظت از ارتباط شبکه محدود نمی‌شود. احراز هویت، اصل حداقل دسترسی (Least Privilege)، مدیریت اعتبارنامه‌ها، تایید عملیات حساس و ثبت فراخوانی ابزارها نیز بخشی از این فرایند هستند.

این کنترل‌ها باید در لایه‌های قابل اعتماد برنامه و سرور اجرا شوند؛ زیرا تصمیم مدل برای فراخوانی یک ابزار، به‌تنهایی مجوز انجام آن عملیات محسوب نمی‌شود.

چرا MCP سطح حمله ایجنت‌ های هوش مصنوعی را افزایش می‌ دهد؟

پروتکل MCP به برنامه‌های هوش مصنوعی اجازه می‌دهد از طریق یک ساختار استاندارد به ابزارها، دیتابیس‌ها و سرویس‌های خارجی متصل شوند. این ارتباط از سه جزء اصلی تشکیل می‌شود:

• میزبان (MCP Host): برنامه‌ای که ایجنت یا مدل هوش مصنوعی را اجرا می‌کند و ارتباط با ابزارهای خارجی را مدیریت می‌کند.
• کلاینت (MCP Client): بخشی از برنامه میزبان که ارتباط با یک سرور MCP را برقرار می‌کند و درخواست‌ها و پاسخ‌ها را انتقال می‌دهد.
• سرور (MCP Server): سرویسی که قابلیت‌هایی مانند جست‌وجوی اطلاعات، خواندن فایل، اجرای عملیات یا فراخوانی API را در اختیار برنامه قرار می‌دهد.

در این معماری، ایجنت می‌تواند براساس درخواست کاربر و اطلاعات دریافتی، ابزار مناسب را انتخاب کند. برای مثال، یک ایجنت پشتیبانی ممکن است اطلاعات مشتری را از دیتابیس بخواند و سپس با استفاده از ابزار دیگری، تیکت پشتیبانی را به‌روزرسانی کند.

مشکل زمانی ایجاد می‌شود که ایجنت با محتوای نامعتبر مواجه شود. متن یک تیکت، پاسخ API یا توضیحات ابزار MCP ممکن است حاوی دستورالعملی باشد که مهاجم برای تغییر رفتار ایجنت نوشته است. اگر برنامه این محتوا را دستور معتبر تشخیص دهد، ممکن است ابزاری را خارج از هدف اصلی کاربر فراخوانی کند.

نوع اتصال نیز بر ریسک امنیتی تاثیر دارد. سرورهای MCP محلی معمولا از ارتباط stdio استفاده می‌کنند و با مجوزهای فرایند اجراشونده به منابع سیستم دسترسی دارند. سرورهای راه دور نیز معمولا از Streamable HTTP استفاده می‌کنند و به کنترل‌های امنیت شبکه، احراز هویت و اعتبارسنجی درخواست‌ها نیاز دارند.

بنابراین، امنیت MCP باید هم محتوایی را که ایجنت دریافت می‌کند بررسی کند و هم عملیاتی را که ابزارها اجازه اجرای آن را دارند، محدود نگه دارد.

مهم‌ ترین تهدیدهای امنیتی MCP کدام‌ اند؟

تهدیدهای MCP معمولا از ترکیب محتوای نامعتبر، دسترسی گسترده و کنترل ناکافی فراخوانی ابزارها ایجاد می‌شوند. بعضی حملات تلاش می‌کنند رفتار مدل را تغییر دهند؛ برخی دیگر از ضعف احراز هویت، اعتبارنامه‌ها یا نرم‌افزار سرور استفاده می‌کنند.

تزریق پرامپت و مسمومیت ابزارها

تزریق پرامپت (Prompt Injection) زمانی اتفاق می‌افتد که مهاجم دستورالعملی را در محتوایی قرار می‌دهد که ایجنت برای انجام وظیفه خود می‌خواند. این محتوا می‌تواند یک ایمیل، فایل، صفحه وب یا نتیجه ابزار MCP باشد.

فرض کنید ایجنتی وظیفه بررسی Issueهای GitHub را دارد. مهاجم در متن یکی از Issueها از ایجنت می‌خواهد اطلاعات یک مخزن خصوصی را بخواند و از طریق ابزار دیگری ارسال کند. اگر ایجنت این متن را به جای داده، دستور معتبر در نظر بگیرد، ممکن است تلاش کند از مجوزهای خود برای انجام درخواست مهاجم استفاده کند.

مسمومیت ابزار (Tool Poisoning) شکل دیگری از این تهدید است. در این حالت، دستورالعمل مخرب داخل توضیحات، مشخصات پارامترها یا خروجی یک ابزار MCP قرار می‌گیرد. برای مثال، یک ابزار جست‌وجوی ظاهرا معمولی ممکن است در توضیحات خود از مدل بخواهد پیش از جست‌وجو، اطلاعات محرمانه‌ای را از ابزار دیگری دریافت کند.

در حمله‌ای با عنوان Rug Pull نیز سرور می‌تواند پس از تایید اولیه، تعریف ابزار را تغییر دهد. اگر برنامه این تغییر را بررسی نکند، ابزاری که قبلا قابل اعتماد به نظر می‌رسید ممکن است رفتار متفاوتی به ایجنت پیشنهاد دهد.

برای کاهش این خطرها باید خروجی ابزارها را داده نامعتبر در نظر گرفت، تغییرات تعریف ابزارها را بررسی کرد و اجازه اجرای عملیات حساس را مستقل از تصمیم مدل کنترل کرد.

مجوزهای بیش از حد و افشای اعتبارنامه‌ ها

بعضی سرورهای MCP با توکن‌ها یا حساب‌های کاربری دارای دسترسی گسترده اجرا می‌شوند. اگر یک سرور به تمام اطلاعات دیتابیس دسترسی داشته باشد، ایجنتی که فقط باید چند رکورد مشخص را بخواند نیز ممکن است از همان سطح دسترسی استفاده کند.

این وضعیت می‌تواند به مشکل نماینده سردرگم (Confused Deputy) منجر شود؛ یعنی یک جزء دارای مجوز بالا، تحت تاثیر درخواست یک موجودیت کم‌دسترسی، عملیاتی را انجام دهد که آن موجودیت خودش مجاز به انجام آن نیست.

افشای اعتبارنامه‌ها خطر دیگری است. کلیدهای API و توکن‌ها گاهی در فایل‌های پیکربندی، متغیرهای محیطی یا لاگ‌ها نگهداری می‌شوند. اگر یک سرور MCP یا فرایند دارای دسترسی به این اطلاعات آلوده شود، احتمال دسترسی مهاجم به اعتبارنامه‌ها وجود دارد.

برای جلوگیری از این مشکلات، باید مجوزها را به پروژه، کاربر و عملیات موردنیاز محدود کرد. همچنین بهتر است از توکن‌های کوتاه‌مدت و محدود به یک سرویس استفاده شود و کلیدهای حساس در اختیار مستقیم مدل قرار نگیرند.

سرورهای نامعتبر، دسترسی شبکه‌ ای و نشت اطلاعات

نصب سرور MCP شخص ثالث می‌تواند به معنای اجرای کدی باشد که توسعه‌دهنده آن را بررسی نکرده است. یک بسته مخرب یا نسخه آلوده می‌تواند به فایل‌های محلی دسترسی پیدا کند، درخواست‌های ناخواسته ارسال کند یا اطلاعات حساس را استخراج کند.

حتی یک سرور معتبر نیز ممکن است به دلیل آسیب‌پذیری نرم‌افزاری یا پیکربندی اشتباه در معرض حمله قرار بگیرد. برای مثال، اگر Endpoint اجرای ابزارها بدون احراز هویت مناسب در اینترنت قابل دسترس باشد، مهاجم ممکن است بتواند درخواست‌های غیرمجاز ارسال کند.

نشت اطلاعات (Data Exfiltration) نیز همیشه به یک ابزار مخرب نیاز ندارد. ایجنتی که اجازه خواندن داده‌های خصوصی و ارسال ایمیل دارد، ممکن است تحت تاثیر تزریق پرامپت اطلاعات را از طریق همان ابزار ایمیل به مقصد ناخواسته بفرستد.

دسترسی آزاد به شبکه همچنین می‌تواند زمینه حملات جعل درخواست سمت سرور (SSRF) را فراهم کند. در چنین حملاتی، مهاجم تلاش می‌کند برنامه را به ارسال درخواست به سرویس‌های داخلی یا آدرس‌هایی مانند Endpoint متادیتای زیرساخت ابری وادار کند.

محدودسازی مقصدهای شبکه، بررسی اعتبار سرورهای MCP و کنترل دسترسی ابزارها از مهم‌ترین راه‌های کاهش این ریسک‌ها هستند.

چگونه امنیت MCP را افزایش دهیم؟

امنیت MCP از همان لحظه‌ای اهمیت پیدا می‌کند که یک ایجنت به ابزارها و داده‌های خارج از محیط خود دسترسی می‌گیرد. در چنین شرایطی، امن بودن ارتباط شبکه کافی نیست؛ باید مشخص باشد چه کسی درخواست را ارسال می‌کند، کدام عملیات مجاز است و در صورت رفتار غیرمنتظره ایجنت، چه محدودیت‌هایی جلوی اجرای درخواست را می‌گیرند.

برای کاهش این خطرها، کنترل‌های امنیتی باید در چند لایه اجرا شوند. احراز هویت و مدیریت مجوزها نقطه شروع هستند، اما محافظت از اعتبارنامه‌ها، بررسی فراخوانی ابزارها و محدودسازی محیط اجرا نیز اهمیت دارند. در ادامه، هشت روش برای ایمن‌سازی ارتباطات MCP را بررسی می‌کنیم.

مدیریت هویت و محدودسازی دسترسی‌ها

۱. احراز هویت و اعتبارسنجی توکن‌ها

پیش از آنکه یک سرور MCP به درخواست‌ها پاسخ دهد، باید هویت درخواست‌کننده مشخص باشد. این موضوع به‌ویژه برای سرورهای راه دور اهمیت دارد؛ جایی که چند کاربر یا برنامه ممکن است از طریق شبکه به ابزارهای یکسان دسترسی داشته باشند.

در ارتباطات مبتنی بر HTTP می‌توان از OAuth برای مدیریت مجوز دسترسی استفاده کرد. با این روش، کلاینت توکن خود را همراه درخواست ارسال می‌کند و سرور پیش از اجرای ابزار، اعتبار آن را بررسی می‌کند. این بررسی نباید به وجود توکن محدود شود. سرور باید مطمئن شود که توکن منقضی نشده، برای همان سرویس صادر شده و مجوزهای لازم برای عملیات درخواستی را دارد.

فرض کنید یک ایجنت با توکن معتبر به سرویس ذخیره‌سازی متصل شده است. این اعتبارنامه نباید امکان دسترسی به ابزارهای یک سرور MCP دیگر را فراهم کند، حتی اگر هر دو سرویس متعلق به یک سازمان باشند.

در سرورهای محلی که از ارتباط stdio استفاده می‌کنند، مسئله کمی متفاوت است. این سرورها معمولا با مجوزهای فرایندی اجرا می‌شوند که آن‌ها را راه‌اندازی کرده است. در نتیجه، کنترل دسترسی به فایل‌ها، محدود کردن مجوزهای سیستم‌عامل و محافظت از اعتبارنامه‌های محلی اهمیت بیشتری پیدا می‌کند.

۲. اعمال اصل حداقل دسترسی

داشتن هویت معتبر به این معنی نیست که یک ایجنت باید به تمام قابلیت‌های سرور دسترسی داشته باشد. هرچه مجوزهای یک ابزار گسترده‌تر باشند، یک درخواست اشتباه یا دستورالعمل مخرب می‌تواند خسارت بیشتری ایجاد کند.

اصل حداقل دسترسی (Least Privilege) برای جلوگیری از همین وضعیت به کار می‌رود. براساس این اصل، هر ایجنت فقط مجوزهایی را دریافت می‌کند که برای انجام وظیفه خود نیاز دارد.

برای نمونه، ایجنتی که گزارش فروش ماهانه تهیه می‌کند، باید بتواند اطلاعات موردنیاز را از دیتابیس بخواند. اما دلیلی ندارد به حذف جدول‌ها، تغییر سفارش‌ها یا اطلاعات پرداخت مشتریان دسترسی داشته باشد. یک حساب دیتابیس فقط خواندنی (Read-only) می‌تواند این محدودیت را در سطح سرویس اعمال کند.

نکته مهم محل اجرای این کنترل است. اگر ایجنت از یک حساب مدیریتی استفاده کند، حتی دقیق‌ترین دستورالعمل‌های پرامپت هم نمی‌توانند مانع قطعی سوءاستفاده از آن حساب شوند. محدودیت مجوز باید در خود دیتابیس، API یا سرور MCP اعمال شود تا اجرای عملیات غیرمجاز، مستقل از تصمیم مدل، امکان‌پذیر نباشد.

کنترل فراخوانی ابزارها و تایید عملیات حساس

۳. کنترل عملیات حساس با تایید مستقل

تمام فراخوانی‌های ابزار ریسک یکسانی ندارند. خواندن وضعیت سفارش با حذف آن متفاوت است و ارسال اطلاعات مشتریان به یک سرویس خارجی نیز نباید مانند دریافت یک گزارش ساده مدیریت شود.

برای کنترل این تفاوت، می‌توان عملیات ابزارها را براساس حساسیت دسته‌بندی کرد. درخواست‌های فقط خواندنی و کم‌خطر، در محدوده مجوزهای تعیین‌شده اجرا می‌شوند. عملیاتی که اطلاعات را تغییر می‌دهند یا داده‌ها را به مقصد دیگری می‌فرستند، ممکن است به تایید کاربر یا یک سیاست اجرایی مستقل نیاز داشته باشند. درخواست‌های خارج از محدوده مجوز نیز باید رد شوند.

یک ایجنت پشتیبانی را در نظر بگیرید که به اطلاعات سفارش‌ها دسترسی دارد. این ایجنت می‌تواند وضعیت ارسال سفارش را بررسی کند، اما تغییر مبلغ پرداخت یا حذف سفارش باید از مسیر تایید جداگانه‌ای عبور کند.

خود تایید نیز باید محدود باشد. وقتی کاربر تغییر یک سفارش مشخص را مجاز می‌کند، نباید این تصمیم به مجوز دائمی ویرایش تمام سفارش‌ها تبدیل شود. اگر شناسه سفارش، نوع عملیات یا سایر پارامترهای حساس پس از تایید تغییر کنند، درخواست جدید باید دوباره ارزیابی شود.

۴. اعتبارسنجی ورودی، خروجی و تعریف ابزارها

ایجنت‌ها برای انتخاب ابزار مناسب به اطلاعاتی مانند نام ابزار، توضیحات و ساختار پارامترهای آن وابسته‌اند. این اطلاعات معمولا از سرور MCP دریافت می‌شوند و مدل از آن‌ها برای تشخیص زمان و نحوه فراخوانی ابزار استفاده می‌کند.

همین وابستگی می‌تواند یک مسیر حمله ایجاد کند. اگر مهاجم توضیحات ابزار را دستکاری کند، ممکن است دستورالعملی در آن قرار دهد که رفتار ایجنت را تغییر دهد؛ برای نمونه، از مدل بخواهد پیش از اجرای ابزار اصلی، اطلاعات محرمانه‌ای را از ابزار دیگری دریافت کند.

بررسی تعریف ابزار پیش از فعال‌سازی، اولین اقدام است. تغییرات بعدی نام، توضیحات و ساختار پارامترها نیز باید کنترل شوند، به‌خصوص زمانی که ابزار به داده‌های حساس دسترسی دارد.

اعتبارسنجی هنگام اجرا اهمیت بیشتری دارد. فرض کنید ابزاری برای دریافت اطلاعات سفارش طراحی شده و تنها یک شناسه عددی می‌پذیرد. سرور نباید اجازه دهد پارامترهای دستکاری‌شده به خواندن فایل‌های محلی یا ارسال درخواست به آدرس‌های دلخواه منجر شوند.

همچنین خروجی ابزار نباید به‌صورت خودکار قابل اعتماد فرض شود. ممکن است یک ابزار معتبر، محتوایی را از وب‌سایت یا فایل آلوده دریافت کند. چنین محتوایی باید داده باقی بماند و دستورالعمل‌های موجود در آن نباید مجوزهای برنامه یا نحوه اجرای ابزارهای دیگر را تغییر دهند.

ایزوله‌سازی اجرا و محدودسازی ارتباطات شبکه

۵. اجرای سرورها و کدهای نامعتبر در محیط ایزوله

اجرای یک سرور MCP محلی می‌تواند دسترسی آن به منابع دستگاه میزبان را فراهم کند. این دسترسی همیشه محدود به فایل‌های پروژه نیست و بسته به مجوزهای فرایند، ممکن است بخش‌های دیگری از سیستم را نیز شامل شود.

اگر سرور از یک بسته شخص ثالث نصب شده باشد، اعتماد کامل به کد آن بدون بررسی امنیتی خطرناک است. برای کاهش این ریسک می‌توان فرایند را در محیطی ایزوله اجرا کرد؛ محیطی که دسترسی به فایل‌ها، شبکه و منابع سیستم در آن محدود شده باشد.

روش اجرا به حساسیت پروژه بستگی دارد. گاهی استفاده از یک حساب کاربری غیرمدیریتی و تنظیم مجوزهای فایل کافی است. در شرایطی که ابزار کد نامعتبر اجرا می‌کند یا به منابع حساس نزدیک است، کانتینرهای محدودشده یا ماشین‌های مجازی ایزوله می‌توانند جداسازی بیشتری فراهم کنند.

برای نمونه، ایجنتی که فقط فایل‌های یک پروژه نرم‌افزاری را بررسی می‌کند، نیازی به مشاهده کلیدهای SSH کاربر یا تغییر فایل‌های سیستمی ندارد. می‌توان پوشه کاری مشخصی در اختیار آن گذاشت و دسترسی نوشتن به سایر مسیرها را مسدود کرد.

البته محیط ایزوله تمام مشکلات امنیتی را حل نمی‌کند. اگر فرایند همچنان بتواند اطلاعات محرمانه را بخواند و آن‌ها را به اینترنت ارسال کند، خطر نشت داده باقی می‌ماند. به همین دلیل، محدودسازی محیط اجرا باید با کنترل ارتباطات شبکه همراه باشد.

۶. محدودسازی ارتباطات خروجی شبکه

یکی از خطرهای مهم در اجرای ایجنت‌های متصل به ابزارهای خارجی، امکان ارسال اطلاعات به مقصدهای ناخواسته است. ایجنت ممکن است برای انجام وظیفه خود به یک دیتابیس خصوصی دسترسی داشته باشد و هم‌زمان بتواند از طریق ابزار دیگری، درخواست‌های اینترنتی ارسال کند.

در چنین شرایطی، یک دستورالعمل مخرب می‌تواند تلاش کند این دو قابلیت را به یکدیگر متصل کند؛ ابتدا اطلاعات خصوصی را بخواند و سپس آن‌ها را به آدرس مهاجم بفرستد.

برای کاهش این خطر می‌توان مقصدهای مجاز شبکه را مشخص کرد. اگر ابزار فقط به یک API نیاز دارد، ضرورتی ندارد اجازه اتصال به تمام اینترنت را داشته باشد. عبور دادن درخواست‌ها از یک پروکسی خروجی نیز امکان بررسی مقصد، اعمال سیاست‌های دسترسی و ثبت ارتباطات را فراهم می‌کند.

این کنترل‌ها در جلوگیری از حملات جعل درخواست سمت سرور (SSRF) هم کاربرد دارند. هنگامی که ابزار یک URL را از محتوای نامعتبر دریافت می‌کند، باید مقصد نهایی درخواست و تغییر مسیرهای احتمالی بررسی شوند. در غیر این صورت، مهاجم ممکن است برنامه را به ارسال درخواست به سرویس‌های داخلی یا Endpoint متادیتای زیرساخت ابری هدایت کند.

با وجود این، مسدودسازی تمام آدرس‌های خصوصی راه‌حل مناسبی برای همه معماری‌ها نیست. بعضی ابزارهای MCP باید به دیتابیس یا API داخلی متصل شوند. چنین دسترسی‌هایی باید از مسیر شبکه مشخص و با مجوزهای محدود برقرار شوند تا ارتباطات ضروری حفظ شوند، بدون اینکه دسترسی غیرضروری ایجاد شود.

بررسی سرورهای شخص ثالث و ثبت رویدادهای امنیتی

۷. بررسی اعتبار و نسخه سرورهای MCP

استفاده از یک سرور MCP آماده می‌تواند توسعه ایجنت را ساده‌تر کند، اما کد آن همچنان بخشی از محیط اجرایی برنامه خواهد بود. اگر بسته آلوده باشد یا آسیب‌پذیری شناخته‌شده‌ای داشته باشد، اتصال به آن ممکن است امنیت داده‌ها و سیستم میزبان را تحت تاثیر قرار دهد.

پیش از نصب، ابتدا ناشر بسته و مخزن رسمی آن را شناسایی کنید. سپس تاریخچه انتشار، وابستگی‌ها و مجوزهایی را که سرور درخواست می‌کند، بررسی کنید. تعداد دانلود بالا یا حضور در یک رجیستری عمومی، به‌تنهایی نشانه قابل اعتماد بودن یک بسته نیست.

در محیط عملیاتی بهتر است از نسخه‌های مشخص و بررسی‌شده استفاده شود. به‌روزرسانی‌ها نیز باید پیش از اعمال ارزیابی شوند، زیرا تغییر یک نسخه ممکن است قابلیت‌های جدیدی اضافه کند یا رفتار ابزارهای موجود را تغییر دهد.

برای نمونه، اگر سروری که پیش‌تر فقط اطلاعات را می‌خواند، پس از به‌روزرسانی ابزار حذف یا ویرایش داده معرفی کند، این تغییر باید پیش از فعال‌سازی بررسی شود. ابزارهای اسکن وابستگی می‌توانند در شناسایی آسیب‌پذیری‌های شناخته‌شده کمک کنند، اما جای بررسی مجوزها و رفتار واقعی سرور را نمی‌گیرند.

۸. ثبت و پایش فراخوانی ابزارها

کنترل دسترسی مشخص می‌کند ایجنت چه کارهایی می‌تواند انجام دهد. برای اینکه بدانیم در عمل چه اتفاقی افتاده، به ثبت و بررسی فراخوانی ابزارها نیاز داریم.

هر رویداد می‌تواند اطلاعاتی مانند زمان درخواست، هویت کاربر و ایجنت، نام سرور MCP، ابزار مورد استفاده و نتیجه عملیات را شامل شود. در درخواست‌های حساس، ثبت وضعیت تایید یا رد و شناسه مرتبط با تصمیم نیز به بررسی‌های بعدی کمک می‌کند.

این اطلاعات به‌ویژه زمانی ارزشمند می‌شوند که رفتار ایجنت از الگوی معمول فاصله بگیرد. افزایش ناگهانی درخواست‌های حذف اطلاعات، تلاش برای فراخوانی ابزارهای غیرمجاز یا ارسال درخواست به مقصدهای جدید، نمونه‌هایی هستند که می‌توان برای آن‌ها هشدار تعریف کرد.

البته ثبت جزئیات بیشتر همیشه به معنای امنیت بالاتر نیست. لاگ‌ها ممکن است حاوی اطلاعات مشتریان، پارامترهای حساس یا اعتبارنامه‌ها باشند. بنابراین باید داده‌های محرمانه پیش از ذخیره حذف یا پوشانده شوند و دسترسی به سوابق، همراه با مدت نگهداری آن‌ها، تحت کنترل باشد.

در زیرساخت‌های بزرگ‌تر می‌توان رویدادها را به سامانه مدیریت اطلاعات و رویدادهای امنیتی (SIEM) ارسال کرد تا الگوهای مشکوک بررسی شوند. این کار به شناسایی حادثه و بازسازی مسیر اجرای درخواست کمک می‌کند، هرچند جایگزین جلوگیری از اجرای عملیات غیرمجاز نیست.

نمونه واقعی آسیب‌پذیری MCP و روش جلوگیری از آن

در ژوئیه ۲۰۲۵، آسیب‌پذیری امنیتی CVE-2025-6514 در بسته mcp-remote گزارش شد. این ابزار برای اتصال کلاینت‌های محلی به سرورهای MCP راه دور استفاده می‌شود و نقص شناسایی‌شده در آن می‌توانست به اجرای فرمان‌های غیرمجاز روی دستگاه کاربر منجر شود.

مشکل به نحوه پردازش اطلاعات دریافتی از سرور MCP نامعتبر در جریان احراز هویت مربوط بود. مهاجم می‌توانست با دستکاری آدرس authorization_endpoint، ورودی مخربی ایجاد کند که در نسخه‌های آسیب‌پذیر به تزریق فرمان سیستم‌عامل (OS Command Injection) منجر شود.

این نقص نسخه‌های 0.0.5 تا پیش از 0.1.16 را تحت تاثیر قرار می‌داد و در نسخه 0.1.16 اصلاح شد.

اهمیت این آسیب‌پذیری در این است که خطرهای امنیتی MCP فقط به تصمیم‌های مدل یا حملات تزریق پرامپت محدود نمی‌شوند. یک نقص در نرم‌افزار اتصال نیز ممکن است امنیت سیستم میزبان را به خطر بیندازد؛ حتی زمانی که خود ایجنت درخواست مخربی تولید نکرده باشد.

برای کاهش چنین ریسک‌هایی، باید ابزارهای اتصال MCP را از منابع معتبر دریافت کرد، نسخه‌های آسیب‌پذیر را به‌روزرسانی کرد و اجرای فرایندهای محلی را به مجوزهای ضروری محدود نگه داشت. همچنین آدرس‌های دریافتی در جریان احراز هویت باید پیش از استفاده اعتبارسنجی شوند.

تفاوت امنیت MCP با امنیت API چیست؟

امنیت MCP و امنیت API اصول مشترکی دارند. در هر دو، باید هویت درخواست‌کننده بررسی شود، مجوزها محدود باشند و داده‌های ورودی و خروجی اعتبارسنجی شوند.

تفاوت مهم در نحوه انتخاب و اجرای عملیات است. در یک برنامه متداول مبتنی بر API، توسعه‌دهنده معمولا مشخص می‌کند کدام API و در چه مرحله‌ای فراخوانی شود. در برنامه‌های مبتنی بر ایجنت، مدل ممکن است براساس محتوایی که دریافت می‌کند، ابزار و پارامترهای فراخوانی را انتخاب کند.

معیار	امنیت API	امنیت MCP
کنترل درخواست	اعتبارسنجی درخواست‌های API	اعتبارسنجی درخواست‌ها و کنترل فراخوانی ابزار توسط ایجنت
احراز هویت	توکن، کلید API یا سازوکارهای هویتی	سازوکارهای مشابه، متناسب با نوع اتصال MCP
تهدیدهای مرتبط با محتوا	ورودی مخرب و سوءاستفاده از API	ورودی مخرب، تزریق پرامپت و مسمومیت ابزار
کنترل دسترسی	مجوزهای کاربر و Endpoint	مجوزهای کاربر، سرور و عملیات ابزار
کنترل عملیات حساس	سیاست‌های برنامه و API	سیاست‌های برنامه و تایید مناسب عملیات انتخاب‌شده توسط ایجنت

البته استفاده از مدل هوش مصنوعی در کنار APIهای معمولی نیز می‌تواند همین ریسک‌های ایجنتی را ایجاد کند. این خطرها مختص MCP نیستند.

در معماری MCP، سطح دیگری از تعامل میان مدل، تعریف ابزارها و سرورهای مختلف وجود دارد که باید در طراحی امنیتی در نظر گرفته شود.

چک‌ لیست امنیت MCP پیش از استفاده در محیط عملیاتی

پیش از اتصال یک ایجنت به اطلاعات واقعی سازمان یا فعال کردن ابزارهای حساس، موارد زیر را بررسی کنید:

• ناشر، نسخه و وابستگی‌های سرورهای MCP بررسی شده‌اند.
• سرورهای راه دور محافظت‌شده، درخواست‌ها و توکن‌های دسترسی را اعتبارسنجی می‌کنند.
• مجوزهای هر ایجنت و ابزار به عملیات موردنیاز محدود شده‌اند.
• اجرای عملیات حساس به سیاست تایید یا کنترل مستقل وابسته است.
• ورودی‌ها، خروجی‌ها و تغییرات تعریف ابزارها بررسی می‌شوند.
• سرورهای محلی و کدهای نامعتبر در محیطی با دسترسی محدود اجرا می‌شوند.
• مقصدهای شبکه و امکان دسترسی به سرویس‌های داخلی کنترل شده‌اند.
• لاگ فراخوانی ابزارها، بدون افشای اعتبارنامه‌ها، ثبت و پایش می‌شود.

در پایان، بهتر است یک آزمایش کنترل‌شده انجام دهید: از ایجنت بخواهید عملیاتی خارج از مجوزهای تعریف‌شده انجام دهد و بررسی کنید که درخواست در لایه اجرایی رد و رویداد آن ثبت می‌شود.

اگر یک فراخوانی مشکوک مشاهده شد، ابتدا دسترسی ابزار یا سرور مربوط را محدود کنید، سپس لاگ‌ها و عملیات انجام‌شده را بررسی کنید. در صورت احتمال افشای اعتبارنامه نیز باید توکن مربوط لغو و جایگزین شود.

سوالات متداول درباره امنیت MCP

آیا MCP به صورت پیش‌فرض امن است؟

MCP سازوکار استانداردی برای اتصال برنامه‌های هوش مصنوعی به ابزارها فراهم می‌کند، اما امنیت نهایی به نحوه پیاده‌سازی بستگی دارد. مشخصات پروتکل برای اتصال‌های HTTP محافظت‌شده، الزامات مشخصی برای اعتبارسنجی توکن دارد. با این حال، کنترل مجوز ابزارها، امنیت محیط اجرا و جلوگیری از نشت اطلاعات همچنان بر عهده توسعه‌دهنده و مدیر زیرساخت است.

آیا برای استفاده امن از MCP به Gateway نیاز داریم؟

خیر. MCP Gateway برای همه پروژه‌ها ضروری نیست. در معماری‌هایی با چند سرور و ایجنت، Gateway می‌تواند مدیریت متمرکز احراز هویت، سیاست‌های دسترسی و ثبت رویدادها را ساده‌تر کند. در پروژه‌های کوچک‌تر نیز می‌توان این کنترل‌ها را مستقیما در برنامه میزبان و سرور MCP اجرا کرد.

چطور دسترسی ایجنت به دیتابیس خصوصی را ایمن کنیم؟

بهتر است دیتابیس مستقیما در اینترنت عمومی در دسترس نباشد. یک سرور MCP یا سرویس واسط می‌تواند از طریق شبکه خصوصی به دیتابیس متصل شود و فقط عملیات موردنیاز را ارائه دهد. همچنین باید مجوزهای دیتابیس، هویت درخواست‌کننده و پارامترهای هر درخواست اعتبارسنجی شوند.

آیا محدود کردن دسترسی‌ ها جلوی تمام حملات Prompt Injection را می‌ گیرد؟

خیر. محدودسازی مجوزها از اجرای بعضی عملیات غیرمجاز جلوگیری می‌کند، اما ممکن است ایجنت همچنان از دسترسی‌های مجاز خود به شکل نامناسب استفاده کند. برای کاهش ریسک باید حداقل دسترسی، کنترل فراخوانی ابزارها، تایید عملیات حساس و محدودسازی انتقال داده در کنار هم استفاده شوند.

تفاوت امنیت سرور MCP محلی و راه دور چیست؟

در سرور MCP محلی، مجوزهای فرایند، دسترسی به فایل‌ها و امنیت اجرای کد اهمیت بیشتری دارند. در سرور MCP راه دور، ارتباط شبکه، احراز هویت، اعتبارسنجی توکن و کنترل دسترسی به Endpointها اهمیت زیادی پیدا می‌کنند. در هر دو حالت، مجوز ابزارها و محتوای ورودی و خروجی باید بررسی شوند.

جمع‌ بندی

امنیت MCP به نحوه مدیریت ارتباط میان ایجنت‌های هوش مصنوعی، سرورهای MCP و ابزارهای متصل بستگی دارد. اگر این ارتباط بدون کنترل دسترسی و اعتبارسنجی مناسب برقرار شود، تهدیدهایی مانند تزریق پرامپت، افشای اعتبارنامه‌ها و اجرای عملیات غیرمجاز می‌توانند اطلاعات و سرویس‌های سازمان را در معرض خطر قرار دهند.

برای کاهش این ریسک‌ها، ابتدا باید مجوزهای هر ایجنت و ابزار را به وظایف موردنیاز محدود کرد. سپس با توجه به حساسیت پروژه، کنترل فراخوانی‌ها، محافظت از اعتبارنامه‌ها، ایزوله‌سازی محیط اجرا و پایش رویدادهای امنیتی را در نظر گرفت. هیچ‌کدام از این اقدامات به‌تنهایی برای جلوگیری از تمام حملات کافی نیستند.

پیش از استفاده از MCP در محیط عملیاتی، عملکرد کنترل‌های امنیتی را آزمایش کنید و مطمئن شوید درخواست‌های غیرمجاز در لایه اجرایی برنامه یا سرور رد می‌شوند. امنیت این ارتباط نباید فقط به دستورالعمل‌های پرامپت یا تصمیم‌های مدل وابسته باشد.