سرور MCP را امن کنید؛ stdio به‌تنهایی sandbox نیست

برای امن‌سازی سرور MCP، مسیر ارتباط و اختیار اجرای ابزار را دو مسئلهٔ جدا بدانید. راهنمای امنیت MCP در OWASP توضیح می‌دهد که stdio درگاه شنوندهٔ MCP ایجاد نمی‌کند، اما دسترسی فرایند سرور به فایل، شبکه یا اعتبارنامه را محدود نمی‌سازد. محدودیت این منابع باید در محیط اجرا و کد ابزار اعمال شود.

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

چک‌لیست سرور محلی: اختیار فرایند را محدود کنید

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

• سرور را با حساب کم‌اختیار یا در محیطی اجرا کنید که دسترسی آن به فایل و فرایندهای میزبان واقعاً محدود شده باشد. فقط پوشه‌های موردنیاز را در اختیارش بگذارید؛ ابزاری که فایل می‌خواند به مجوز نوشتن در همان پوشه نیاز ندارد.
• شبکهٔ خروجی را در سطح محیط اجرا ببندید، مگر برای مقصدهایی که کار ابزار به آن‌ها وابسته است. اگر ابزار URL می‌گیرد، نشانی و هر مقصدِ تغییرمسیر را پیش از اتصال بررسی کنید تا درخواست به سرویس داخلی یا محل نگهداری اعتبارنامه هدایت نشود.
• برای هر سرور اعتبارنامهٔ جدا با دامنهٔ دسترسی محدود تعریف کنید. رازهای نامربوط را از محیط فرایند حذف کنید و توکن را در پیکربندی متن ساده، خروجی ابزار یا گزارش اجرا قرار ندهید.
• اگر سرور محلی به‌جای stdio از HTTP استفاده می‌کند، شنود را به نشانی محلی محدود و دسترسی به آن را کنترل کنید. بازبودن فقط روی localhost مانع استفادهٔ هر فرایند دیگرِ دارای دسترسی به آن نشانی نمی‌شود.

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

چک‌لیست سرور راه‌دور: درخواست و اختیار کاربر را جداگانه بسنجید

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

• اتصال راه‌دور را با TLS برقرار کنید. در هر درخواست حفاظت‌شده، اعتبار توکن و مجوز کاربر برای ابزار و منبع موردنظر را بررسی کنید؛ حق اتصال به سرور به‌معنای حق اجرای همهٔ ابزارهای آن نیست.
• برای Originهای مجاز و نام میزبان مورد انتظار فهرست مشخص داشته باشید. Origin حاضر اما نامعتبر را رد کنید؛ نبودن این سرآیند در کلاینت غیربراوزری، به‌تنهایی دلیل رد درخواست نیست. همین قاعده را در تنظیمات پراکسی معکوس هم حفظ کنید.
• اگر سرور نقش پراکسی OAuth دارد، رضایت کاربر را به کلاینت درخواست‌کننده، دامنه‌های دسترسی و نشانی بازگشت آن گره بزنید. رضایت قبلی برای یک کلاینت نباید مجوز کلاینت دیگری شود.
• برای هر ابزار محدودیت زمان، نرخ و مصرف منابع بگذارید. گزارش اجرا باید هویت احرازشده، ابزار فراخوانده‌شده و نتیجهٔ تصمیم دسترسی را نگه دارد، اما توکن و دادهٔ حساس را از آن حذف کنید.

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

در برابر تعریف آلوده، تزریق دستور و زنجیرهٔ ابزار چه کنید؟

نام ابزار، توضیح، پارامترها و schema بخشی از محتوایی هستند که مدل می‌بیند. پیش از فعال‌سازی، تعریف کامل ابزار را بازبینی و نسخهٔ تأییدشده را تثبیت کنید؛ تغییر آن باید دوباره بررسی شود. هشِ تعریف می‌تواند تغییر فراداده را آشکار کند، اما تغییر رفتار پیاده‌سازی پشت همان تعریف را نشان نمی‌دهد.

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

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

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

شناسهٔ وضعیت را جای احراز هویت نگذارید

در نسخهٔ 2026-07-28، اعلام رسمی تغییرات MCP حذف نشست در سطح حمل‌ونقل و سرآیند Mcp-Session-Id را شرح می‌دهد. سروری که برای ادامهٔ کار میان درخواست‌ها شناسهٔ وضعیتِ مخصوص برنامه صادر می‌کند، باید آن شناسه را به کاربر احرازشده مقید سازد. داشتن شناسه، حتی اگر حدس‌زدنش دشوار باشد، جای بررسی هویت و مجوز همان درخواست را نمی‌گیرد.

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

بیشتر بخوانید:

• Structured Outputs یا Function Calling؛ JSON معتبر هنوز ابزار نیست
• حذف My Activity کافی نیست؛ تاریخچهٔ Chrome و Timeline جدا می‌ماند
• رمز WhatsApp را فعال کنید؛ کد یک‌بارمصرف به‌تنهایی کافی نیست