امنیت MCP و پلاگین‌های هوش مصنوعی؛ چرا ابزارهای Agentها به یک زنجیره تأمین خطرناک تبدیل شده‌اند؟

هوش مصنوعی در حال عبور از مرحله‌ای است که در آن فقط به سؤال‌های کاربران پاسخ می‌دهد. نسل جدید AI Agentها می‌تواند ایمیل بخواند، فایل جابه‌جا کند، کد اجرا کند، به پایگاه داده متصل شود، در GitHub تغییر ایجاد کند و با سرویس‌های مختلف ارتباط برقرار کند. اما برای انجام این کارها، مدل هوش مصنوعی به مجموعه‌ای از ابزارها نیاز دارد؛ ابزارهایی که در بسیاری از پروژه‌ها از طریق Model Context Protocol یا MCP در اختیار Agent قرار می‌گیرند.

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

اما همین انعطاف‌پذیری یک مشکل امنیتی مهم ایجاد کرده است: هر ابزار جدیدی که به Agent اضافه می‌شود، یک نقطه اعتماد جدید نیز به سیستم اضافه می‌کند.

در دنیای نرم‌افزار، این مسئله به مفهوم زنجیره تأمین شباهت دارد؛ با این تفاوت که در اکوسیستم Agentها، یک جزء مخرب فقط نمی‌تواند کد اجرا کند، بلکه می‌تواند بر تصمیم‌گیری خود مدل نیز تأثیر بگذارد.

MCP چیست و چرا به چنین بخش مهمی از Agentها تبدیل شده است؟

برای درک خطرات امنیتی MCP، ابتدا باید معماری ساده آن را بشناسیم.

در یک معماری معمول، کاربر با برنامه هوش مصنوعی تعامل دارد. این برنامه یک MCP Client در اختیار دارد و Client می‌تواند به یک یا چند MCP Server متصل شود. MCP Server نیز ابزارها، منابع یا قابلیت‌هایی را در اختیار Agent قرار می‌دهد.

به‌صورت ساده می‌توان این ساختار را چنین تصور کرد:

کاربر ← برنامه هوش مصنوعی ← MCP Client ← MCP Server ← ابزار یا سرویس خارجی

یک MCP Server می‌تواند به سرویس ایمیل، سیستم فایل، GitHub، پایگاه داده، تقویم، مرورگر یا تقریباً هر API دیگری متصل شود. در نتیجه Agent دیگر فقط متن تولید نمی‌کند؛ می‌تواند در دنیای واقعی عملیات انجام دهد.

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

این تفاوت کوچک به نظر می‌رسد، اما از دید امنیتی بسیار مهم است.

وقتی ابزار به بخشی از Context مدل تبدیل می‌شود

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

فرض کنید یک Agent به سه ابزار دسترسی دارد:

• خواندن فایل‌ها
• ارسال ایمیل
• جست‌وجوی اینترنت

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

مشکل زمانی آغاز می‌شود که یکی از این ابزارها یا اطلاعاتی که از آن دریافت می‌شود، قابل اعتماد نباشد.

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

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

Tool Poisoning؛ وقتی توضیحات ابزار تبدیل به سلاح می‌شوند

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

در این روش، مهاجم یک ابزار ظاهراً عادی ایجاد می‌کند؛ مثلاً ابزاری برای محاسبه، جست‌وجوی اطلاعات یا بررسی وضعیت یک سرویس.

اما در توضیحات داخلی ابزار، دستورهای مخفی یا فریبنده‌ای قرار می‌دهد.

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

Invariant Labs در آوریل ۲۰۲۵ این مسئله را به‌صورت عملی نشان داد و توضیح داد که یک Tool Description مخرب می‌تواند مدل را به سمت خواندن فایل‌های حساس و استخراج اطلاعات هدایت کند.

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

ممکن است سرور کاملاً طبق پروتکل کار کند؛ مشکل این باشد که اطلاعاتی که به مدل می‌دهد، مخرب است.

حمله فقط به توضیحات ابزار محدود نمی‌شود

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

محتوای دریافت‌شده از ابزار نیز می‌تواند حاوی دستورهای مخرب باشد.

برای مثال، یک Agent به یک MCP Server مربوط به GitHub متصل است. کاربر از Agent می‌خواهد Issueهای یک پروژه را بررسی کند. یکی از Issueها توسط مهاجم ساخته شده و در متن آن دستورهایی مخفی برای Agent قرار گرفته است.

مدل متن Issue را می‌خواند و ممکن است نتواند به‌درستی تشخیص دهد که این متن «داده» است یا «دستور».

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

این همان مشکلی است که در امنیت Agentها اهمیت بسیار زیادی دارد:

مدل باید بتواند بین چیزی که باید بخواند و چیزی که باید از آن دستور بگیرد تفاوت قائل شود.

اما این تفکیک همیشه ساده نیست.

Rug Pull؛ ابزار سالمی که بعداً مخرب می‌شود

یکی از سناریوهای خطرناک‌تر، حمله Rug Pull است.

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

نام ابزار همچنان همان است.

کاربرد ظاهری آن نیز همان است.

اما چیزی که Agent دریافت می‌کند دیگر همان چیزی نیست که هنگام تأیید اولیه بررسی شده بود.

Cloud Security Alliance این حمله را یکی از گونه‌های اصلی تهدیدهای زنجیره تأمین MCP معرفی کرده و ریشه مشکل را در نبود سازوکار کافی برای بررسی مداوم اعتماد میان Client و Server می‌داند.

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

Tool Shadowing؛ حمله‌ای که از یک ابزار به ابزار دیگر می‌رسد

تهدید مهم دیگری که در معماری MCP مطرح شده، Tool Shadowing است.

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

تصور کنید Agent به یک ابزار ناشناس برای دریافت اطلاعات آب‌وهوا و یک ابزار معتبر برای ارسال ایمیل دسترسی دارد.

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

در نتیجه، مهاجم از یک ابزار غیرمجاز برای سوءاستفاده از ابزار مجاز استفاده می‌کند.

این مسئله نشان می‌دهد که بررسی تک‌تک MCP Serverها به‌تنهایی کافی نیست. باید رفتار کل زنجیره ابزارها بررسی شود. Cloud Security Alliance نیز Tool Shadowing را در کنار Tool Poisoning و Rug Pull به‌عنوان یکی از الگوهای اصلی این حملات معرفی کرده است.

چرا این مسئله یک زنجیره تأمین واقعی است؟

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

Agentها همین مدل را به دنیای هوش مصنوعی منتقل کرده‌اند.

یک Agent ممکن است از:

• MCP Serverهای شخص ثالث
• پکیج‌های npm و PyPI
• پلاگین‌ها
• Agent Skills
• ابزارهای متن‌باز
• APIهای خارجی
• کانکتورهای سازمانی

استفاده کند.

هرکدام از این اجزا می‌تواند بخشی از زنجیره اعتماد باشد.

در سال ۲۰۲۶ حتی نمونه‌هایی از حملات زنجیره تأمین سنتی نیز مستقیماً به ابزارهای هوش مصنوعی نزدیک‌تر شده‌اند. در یک کمپین موسوم به SANDWORM_MODE، مهاجمان از بسته‌های مخرب npm برای دستکاری زنجیره ابزارهای توسعه هوش مصنوعی استفاده کردند و حتی ثبت یک MCP Server مخرب در ابزارهایی مانند Cursor را هدف قرار دادند.

مایکروسافت نیز در ماه مه ۲۰۲۶ از یک حمله گسترده به بسته‌های npm خبر داد که در آن بسته‌های Typosquatting برای سرقت اعتبارنامه‌های AWS، HashiCorp Vault و اطلاعات CI/CD استفاده می‌شدند.

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

حتی اجرای محلی MCP نیز بی‌خطر نیست

یکی از تصورات اشتباه این است که اگر MCP Server روی کامپیوتر خود کاربر اجرا شود، خطر کاهش پیدا می‌کند.

اما MCP Server محلی معمولاً به سیستم‌عامل دسترسی دارد.

Cloud Security Alliance در گزارشی در سال ۲۰۲۶ به ریسک‌های مربوط به انتقال STDIO اشاره کرده است؛ در این مدل، Server می‌تواند به‌صورت یک فرایند محلی اجرا شود و در صورت پیکربندی ناامن، اجرای فرایندهای سیستم‌عامل به بخشی از زنجیره حمله تبدیل شود.

این موضوع اهمیت زیادی دارد، زیرا یک MCP Server محلی ممکن است به فایل‌های کاربر، متغیرهای محیطی، کلیدهای API و سایر منابع سیستم دسترسی داشته باشد.

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

توکن‌های OAuth؛ کلیدهایی که نباید بیش از حد قدرتمند باشند

حتی اگر یک MCP Server کاملاً سالم باشد، نحوه مدیریت مجوزها می‌تواند مشکل‌ساز شود.

فرض کنید یک MCP Server به Gmail یا یک سرویس ابری متصل است و توکنی با دسترسی بسیار گسترده دریافت کرده است.

اگر Agent یا MCP Server به خطر بیفتد، مهاجم ممکن است بتواند از همان مجوز برای دسترسی به منابعی بسیار فراتر از نیاز واقعی ابزار استفاده کند.

استاندارد رسمی MCP برای Authorization به همین دلیل بر استفاده از OAuth ۲.۱، اعتبارسنجی Token و محدود کردن آن به Resource موردنظر تأکید دارد. MCP همچنین تصریح می‌کند که Server نباید Token دریافتی را بدون اعتبارسنجی یا به‌صورت مستقیم به سرویس دیگری منتقل کند؛ زیرا چنین کاری می‌تواند به Confused Deputy منجر شود.

بنابراین اصل مهم این است:

هر ابزار باید کمترین سطح دسترسی لازم را داشته باشد.

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

اگر یک Agent فقط باید یک فایل را بخواند، چرا باید به کل سیستم فایل دسترسی داشته باشد؟

مشکل اصلی فقط هک کردن مدل نیست

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

در بسیاری از سناریوهای MCP، چنین چیزی لازم نیست.

مدل همان مدلی است که شرکت نصب کرده است.

احراز هویت نیز ممکن است کاملاً سالم باشد.

Firewall هم ممکن است کار کند.

مشکل این است که Agent با مجوزهای واقعی در حال اجرای دستورهایی است که تحت تأثیر داده یا ابزار مخرب قرار گرفته‌اند.

این موضوع باعث می‌شود حمله از دید سیستم‌های امنیتی سنتی نیز پیچیده‌تر شود.

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

از دید API:

درخواست قانونی است.

از دید کاربر:

درخواست را نداده است.

و از دید مدل:

ممکن است تصور کند این همان کاری است که باید انجام دهد.

این شکاف میان سه دیدگاه، یکی از مهم‌ترین چالش‌های امنیت Agentهاست.

MCP خودش مشکل است یا نحوه استفاده از آن؟

پاسخ دقیق این است که MCP به‌تنهایی یک بدافزار یا آسیب‌پذیری واحد نیست.

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

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

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

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

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

سازمان‌ها باید قبل از نصب یک Server، منبع آن، کد، وابستگی‌ها، مجوزهای موردنیاز و سابقه تغییرات آن را بررسی کنند.

دومین اصل، حداقل سطح دسترسی است.

هیچ Agent یا MCP Server نباید بیشتر از چیزی که برای انجام وظیفه‌اش نیاز دارد مجوز داشته باشد.

سومین اصل، تأیید عملیات حساس است.

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

چهارمین اصل، کنترل خروجی ابزارهاست.

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

پنجمین اصل، ثبت و نظارت بر رفتار Agent است.

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

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

استاندارد MCP هم در حال تقویت لایه امنیتی خود است

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

در بازنگری مشخصات MCP در ژوئیه ۲۰۲۶، تغییراتی در بخش Authorization انجام شد؛ از جمله الزاماتی برای اعتبارسنجی iss، بهبود Dynamic Client Registration و اصلاح برخی مشکلات مربوط به جریان احراز هویت.

نسخه‌های جدید مشخصات همچنین بر موضوعاتی مانند OAuth ۲.۱، اعتبارسنجی Audience توکن‌ها، جلوگیری از Token Passthrough و استفاده از PKCE تأکید دارند.

این تغییرات مهم‌اند، اما یک مشکل اساسی را به‌تنهایی حل نمی‌کنند:

امنیت Agent فقط امنیت پروتکل نیست.

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

آینده Agentها بدون امنیت زنجیره تأمین قابل تصور نیست

رشد Agentic AI احتمالاً به معنای افزایش تعداد ابزارهایی است که این سیستم‌ها می‌توانند استفاده کنند.

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

حتی شرکت‌های امنیتی نیز به سمت ساخت سازوکارهای اختصاصی برای بررسی این اجزا حرکت کرده‌اند. برای نمونه، در سپتامبر ۲۰۲۶، Tenable و OpenAI یک فرایند بررسی امنیتی برای اجزای جامعه‌محور مانند Agentها، Skillها، MCP Serverها و Playbookهای چندعاملی معرفی کردند.

این اتفاق نشان می‌دهد صنعت به‌تدریج به یک واقعیت مهم رسیده است:

نمی‌توان به Agent قابلیت‌های بیشتری داد و هم‌زمان زنجیره تأمین ابزارهای آن را نادیده گرفت.

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

جمع‌بندی؛ Agent قدرتمند بدون زنجیره تأمین امن، یک ریسک بزرگ است

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

اما همین ویژگی باعث شده است MCP به یکی از مهم‌ترین نقاط تمرکز امنیتی در دنیای Agentic AI تبدیل شود.

Tool Poisoning، Rug Pull، Tool Shadowing، Prompt Injection، مجوزهای بیش از حد و اجرای کد در MCP Serverهای محلی نشان می‌دهند که حمله به Agent لزوماً به معنای حمله مستقیم به مدل نیست.

مهاجم می‌تواند به سراغ چیزی برود که مدل به آن اعتماد دارد.

و این دقیقاً همان جایی است که مفهوم زنجیره تأمین اهمیت پیدا می‌کند.

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

به همین دلیل، آینده Agentic AI فقط به مدل‌های قدرتمندتر وابسته نیست؛ به اکوسیستمی نیاز دارد که در آن هر ابزار، Server، Plugin و Skill از نظر هویت، مجوز، کد، رفتار و تغییرات مداوم تحت کنترل باشد.

در غیر این صورت، هرچه Agentها توانمندتر شوند، قدرت بیشتری نیز در اختیار زنجیره تأمین آسیب‌پذیر آن‌ها قرار خواهد گرفت.