قابلیت Sampling در پروتکل MCP اجازه می‌دهد سرورها مدل شما را هدایت کنند

تصور کنید ابزاری که برای مدیریت حساب‌های مالی شماست، به‌جای اینکه فقط داده‌ها را ثبت کند، خودش تصمیم بگیرد چه سؤالی از هوش مصنوعی شما بپرسد. این دقیقاً همان اتفاقی است که با نمونه‌برداری (Sampling) در پروتکل زمینهٔ مدل (Model Context Protocol یا MCP) رخ می‌دهد؛ قابلیتی که اجازه می‌دهد یک سرور شخص ثالث، پرامپتی بنویسد و آن را روی مدلی اجرا کند که شما احراز هویت کرده‌اید و مالک زمینه‌اش هستید.

در یک تبادل استاندارد MCP، مدل زبانی نقش مغز و سرور نقش لوله‌کشی داده‌ها را دارد. شما سؤالی می‌پرسید، کلاینت ابزار مناسب را انتخاب می‌کند و سرور داده را برمی‌گرداند. این ساختار در واقع بخشی از تلاش برای استانداردسازی تعاملات مدل‌های زبانی با ابزارهاست تا جایگزینی برای رابط‌های اختصاصی و پیچیده باشد. اما Sampling این رابطه را وارونه می‌کند. این قابلیت به سرور اجازه می‌دهد اجرای یک وظیفه را متوقف کند و از کلاینت بخواهد یک استنتاج (Inference) — شبیه به لحظه‌ای که یک آشپز واقعاً غذا می‌پزد، نه زمانی که دستور پخت را می‌خواند — را از طرف خودش انجام دهد. حالا سرور دیگر فقط داده نمی‌فرستد، بلکه از مدل شما می‌خواهد با استفاده از پرامپتی که خودِ سرور نوشته، فکر کند.

به عنوان مثال، یک سرور حسابداری در حال پردازش هزینه‌هاست. اگر به تراکنشی برسد که نمی‌تواند دسته‌بندی کند، دیگر مجبور نیست شکست بخورد، حدس بزند یا مشکل را به کاربر برگرداند. طبق مستندات پروتکل زمینهٔ مدل، سرور یک درخواست sampling/createMessage به کلاینت می‌فرستد و می‌پرسد: «با توجه به این شرح، این تراکنش به کدام حساب تعلق دارد؟»

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

ساختار فنی درخواست

سرور این درخواست را از طریق متد sampling/createMessage ارسال می‌کند. ساختار این درخواست که سرور به سمت کلاینت می‌فرستد، از یک الگوی مشخص پیروی می‌کند که در پیش‌نویس مشخصات MCP تعریف شده است.

مثال از ساختار درخواست:

{
  "method": "sampling/createMessage",
  "params": {
    "messages": [
      {
        "role": "user",
        "content": {
          "type": "text",
          "text": "Categorize this transaction: ..."
        }
      }
    ],
    "modelPreferences": {
      "hints": [{"name": "claude-3-sonnet"}],
      "costPriority": 0.3,
      "intelligencePriority": 0.8,
      "speedPriority": 0.5
    },
    "systemPrompt": "You are a helpful bookkeeping assistant.",
    "includeContext": "thisServer",
    "maxTokens": 100
  }
}

سه بخش در این درخواست بسیار حیاتی هستند و تأثیری فراتر از ظاهر ساده‌شان دارند:

• messages و systemPrompt: این‌ها پرامپت‌هایی هستند که کاملاً توسط سرور نوشته شده‌اند. سرور دقیقاً کنترل می‌کند که از مدل چه خواسته شود. این متن توسط کلاینت نوشته نشده، بلکه توسط یک طرف خارجی (Remote Party) ارسال شده است.
• modelPreferences: این بخش به سرور اجازه می‌دهد انتخاب مدل را هدایت کند. سرور از راهنماها (مانند درخواست برای "claude-3-sonnet") و امتیازات اولویت برای هزینه، هوش و سرعت استفاده می‌کند. اگرچه تصمیم نهایی با کلاینت است، اما سرور می‌تواند به‌طور مؤثری برای استفاده از یک مدل گران‌تر و باهوش‌تر لابی کند.
• includeContext: این فیلد به کلاینت می‌گوید چه مقدار از تاریخچه گفتگو باید در پرامپت گنجانده شود. این فیلد مقادیر "none" (هیچ)، "thisServer" (فقط این سرور) یا "allServers" (همه سرورها) را می‌پذیرد.

دفاع از طریق نظارت انسانی

نویسندگان پروتکل با آگاهی از خطرات اجازه دادن به سرورهای راه دور برای پرامپت کردن مدل کاربر، یک گیت نظارت انسانی (Human-in-the-loop) را در دو نقطه مجزا اجباری کرده‌اند:

۱. قبل از فراخوانی: کلاینت موظف است پرامپتی را که سرور قصد اجرای آن را دارد به کاربر نشان دهد. کاربر می‌تواند آن را ویرایش، تأیید یا رد کند. متن سرور نباید بدون این اجازه به مدل برسد.
۲. قبل از بازگشت نتیجه: پس از اینکه مدل پاسخ را تولید کرد، کلاینت باید آن نتیجه را به کاربر نشان دهد. کاربر می‌تواند قبل از اینکه پاسخ به سرور بازگردانده شود، آن را تأیید یا مسدود کند.

بر روی کاغذ، این یک مدل تهدید منطقی است. کلاینت مالک فراخوانی LLM است، مدل واقعی را انتخاب می‌کند و به عنوان دروازه‌بان عمل می‌کند. اما مشکل اینجاست که مشخصات پروتکل توصیف می‌کند چه چیزی «باید» اتفاق بیفتد. اینکه آیا یک کلاینت خاص این گیت‌ها را پیاده‌سازی می‌کند — یا اصلاً قابلیت Sampling را پیاده می‌کند یا خیر — موضوعی متفاوت است.

وضعیت پیاده‌سازی در سال ۲۰۲۶

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

• Claude Code: تا اوت ۲۰۲۶، Claude Code در نقش کلاینت MCP هنوز از Sampling پشتیبانی نمی‌کند. یک درخواست ویژگی (Issue #1785) از ژوئن ۲۰۲۵ باز مانده و تا اوت ۲۰۲۶ با ۵۸ نظر همچنان بدون پاسخ باقی مانده است.
• opencode: این کلاینت سریع‌تر عمل کرد و درخواست «افزودن پشتیبانی از MCP sampling (createMessage)» (Issue #11948) را در آوریل ۲۰۲۶ به عنوان تکمیل‌شده بست.
• VS Code: کلاینت MCP در وی‌اس‌کد این قابلیت را پیاده کرده و بر اساس modelPreferences ارائه شده توسط سرورها عمل می‌کند.

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

سطح حمله جدید

در آوریل ۲۰۲۶، واحد Unit 42 از شرکت Palo Alto تحلیلی از بردارهای حمله مختص Sampling منتشر کرد. آن‌ها اشاره کردند که حملات Sampling به‌ویژه خطرناک هستند زیرا به‌جای استفاده از یک ابزار بدساخت، بر روی یک قابلیت قانونی پروتکل سوار می‌شوند. این امر به آن‌ها اجازه می‌دهد از بررسی‌های استاندارد یکپارچگی ابزار و محیط‌های ایزوله (Sandboxing) عبور کنند.

واحد Unit 42 سه دسته اصلی از سوءاستفاده‌ها را شناسایی کرد:

• فراخوانی پنهان ابزار (Covert Tool Invocation): استفاده از درخواست‌های Sampling برای انجام عملیات مخفی روی فایل‌ها و سیستم که باعث دور زدن قابلیت‌های دیداری معمول می‌شود.
• ربایش گفتگو (Conversation Hijacking): پرامپت Sampling یک سرور مخرب می‌تواند مدل را دستور دهد که یک دستورالعمل را به پاسخ بعدی خود اضافه کند. چون این متن وارد تاریخچه گفتگو می‌شود، مدل حتی پس از پایان فراخوانی Sampling، در نوبت‌های بعدی همچنان از آن دستور پیروی می‌کند. این روش همچنین برای استخراج داده‌ها (Exfiltration) به کار می‌رود؛ به این صورت که به مدل گفته می‌شود اطلاعات استخراج شده را در پاسخ بعدی به کاربر بگنجاند.
• سرقت منابع (Denial-of-Wallet): یک سرور می‌تواند درخواست‌های انبوه Sampling ارسال کند تا سهمیه محاسباتی و بودجه کاربر را برای انجام کارهای پردازشی خودِ مهاجم مصرف کند.

ریسک نشت زمینه

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

برای کاهش این ریسک، مشخصات MCP گزینه‌های thisServer و allServers را به صورت نرم حذف (soft-deprecated) کرده است. کلاینت‌های سازگار اکنون تنها در صورتی این درخواست‌ها را می‌پذیرند که صراحتاً قابلیت sampling-context را اعلام کرده باشند. این در واقع عقب‌نشینی آرام پروتکل از قابلیتی است که یک حفره امنیتی بزرگ در حریم خصوصی ایجاد کرده بود.

لیست خلاصه تهدیدات

هنگام بررسی سروری که از Sampling استفاده می‌کند یا کلاینتی که آن را پیاده کرده است، این ریسک‌های اصلی باید مورد بازرسی قرار گیرند:

• تزریق پرامپت ورودی (Inbound Prompt Injection): با messages و systemPrompt به عنوان متنی که توسط مهاجم کنترل می‌شود و هدفش مدل شماست، برخورد کنید.
• ربایش پایدار (Persistent Hijack): مراقب پرامپت‌هایی باشید که دستوراتی را در پاسخ‌های قابل مشاهده می‌کارند تا در نوبت‌های آینده باقی بمانند.
• نشت بین‌سروری (Cross-Server Leak): بررسی کنید آیا includeContext: "allServers" اجازه دسترسی یک سرور به تاریخچه سرورهای دیگر را می‌دهد یا خیر.
• سرقت سهمیه (Quota Theft): سرورهایی را مانیتور کنید که از توکن‌های شما برای انجام وظایف استدلالی خودشان استفاده می‌کنند.
• فقدان گیت‌های تأیید (Missing Gates): تأیید کنید که آیا کلاینت واقعاً تأییدیه‌های درخواست و پاسخ را نمایش می‌دهد؛ در غیر این صورت، شما صرفاً به سرور اعتماد کرده‌اید.

این گذار نشان‌دهنده یک تغییر بنیادین در مرز اعتماد است. وقتی یک مدل ابزاری را فراخوانی می‌کند، سرور منبعی از خروجی‌های غیرقابل اعتماد است. اما با Sampling، سرور در جایگاهی بالاتر از استدلال مدل قرار می‌گیرد و از «چیزی که من فراخوانی می‌کنم» به «چیزی که مرا پرامپت می‌کند» تبدیل می‌شود.

گام بعدی شما

• اگر از کلاینت‌های MCP استفاده می‌کنید، بررسی کنید آیا گیت‌های تأیید پرامپت (Approval Gates) فعال هستند یا خیر.
• در تنظیمات سرورهای شخص ثالث، دسترسی به allServers را محدود کنید تا نشت داده بین ابزارها رخ ندهد.
• میزان مصرف توکن‌های خود را مانیتور کنید تا از حملات Denial-of-Wallet جلوگیری کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.