امنیت در پروتکل MCP: مسموم‌سازی متادیتا، مسیریابی و الگوی MRTR

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

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

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

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

اهداف یادگیری

• با توضیحات ابزار، حاشیه‌نویسی‌ها (annotations)، اطلاعات کلاینت و اطلاعات سرور مثل داده‌های غیرقابل‌اعتماد رفتار کنید.
• مسموم‌سازی متادیتا (metadata poisoning)، تغییرات توصیف‌گر (descriptor changes) و تداخل نام ابزارها بین چند سرور را شناسایی کنید.
• متادیتای درخواست پروتکل 2026-07-28 و هدرهای مسیریابی بستر انتقال Streamable HTTP را اعتبارسنجی کنید.
• از requestState در MRTR در برابر دستکاری محافظت کنید و تأییدیه را دقیقاً به آرگومان‌های ارسالی مقید سازید.
• مجوزها و محدودیت‌های نرخ درخواست را روی عامل اصلی (principal) اعمال کنید، نه روی نشست حذف‌شده‌ی پروتکل.

صورت مسئله

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

راهنمای رسمی امنیت MCP موضعی کاملاً شفاف دارد: با توضیحات و حاشیه‌نویسی‌ها باید مثل داده‌های غیرقابل‌اعتماد رفتار شود، مگر اینکه از سروری مطمئن بیایند. تازه با این فرض هم سطح اعتماد در محیط عملیاتی پایدار نیست؛ ارتقای یک سرور، آلوده شدن پکیج‌ها، اشتباه در ریجستری یا merge در گیت‌وی می‌تواند هر لحظه دید مدل به ابزارها را دگرگون کند.

نسخه‌ی فعلی پروتکل مرزهای امنیتی را هم جابه‌جا کرده است. در نسخه‌ی 2026-07-28 خبری از دست‌دادن (handshake) در لایه‌ی هسته یا نشست در بستر انتقال نیست. اگر سازوکار امنیتی شما تأییدیه‌ها، محدودیت‌های نرخ درخواست یا تاریخچه‌ی ممیزی را فقط بر اساس Mcp-Session-Id کلید می‌زند، با معماری پروتکل جدید همخوانی ندارد.

مفاهیم کلیدی

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

به‌جای توصیه‌های کلی مثل «مراقب باشید»، این فهرست مشخص را پیاده‌سازی کنید:

1. مسموم‌سازی متادیتا (Metadata poisoning): توضیحات ابزار شامل دستورالعمل‌هایی است که هیچ ربطی به رفتار اعلام‌شده‌ی ابزار ندارند.
2. عوض کردن زیرپوستی توصیف‌گر (Descriptor rug pull): نام، توضیحات، اسکیما یا حاشیه‌نویسی‌های ابزاری که قبلاً تأیید شده است، ناگهان تغییر می‌کند.
3. هم‌پوشانی ابزارها بین سرورها (Cross-server shadowing): دو سرور مختلف ابزاری با یک نامِ بدون‌پیشوند ارائه می‌دهند و مسیریاب بدون سر‌وصدا یکی را انتخاب می‌کند.
4. عدم تطابق هدر و بدنه (Header and body confusion): مقدار Mcp-Method یا Mcp-Name با محتوای درخواست JSON-RPC همخوانی ندارد.
5. ارتقای سطح دسترسی از طریق قابلیت‌ها (Capability escalation): طرف مقابل ادعای پشتیبانی از یک افزونه یا قابلیت کلاینت را مطرح می‌کند و سرور این ادعا را به‌اشتباه مجوز دسترسی تلقی می‌کند.
6. دستکاری وضعیت MRTR (MRTR state tampering): کلاینت فیلد requestState را دستکاری می‌کند، به سوال دیگری پاسخ می‌دهد، یا تأییدیه‌ی دریافتی را برای آرگومان‌های متفاوتی دوباره مصرف می‌کند.
7. جعل هویت در زنجیره‌ی تأمین (Supply-chain identity confusion): یک نام نمایشیِ آشنا به‌عنوان سند هویت ناشر یا سرور در نظر گرفته می‌شود.

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

بسته‌ی درخواست فعلی سند شواهد است، نه شناسه هویت

هر درخواست در نسخه‌ی 2026-07-28 شامل ساختار زیر است:

{
  "_meta": {
    "io.modelcontextprotocol/protocolVersion": "2026-07-28",
    "io.modelcontextprotocol/clientCapabilities": {
      "elicitation": {"form": {}}
    },
    "io.modelcontextprotocol/clientInfo": {
      "name": "security-lab",
      "version": "1.0.0"
    }
  }
}

نسخه و ساختار قابلیت‌ها را در تک‌تک درخواست‌ها اعتبارسنجی کنید. از قابلیت‌ها برای انتخاب ساختار پاسخ سازگار بهره ببرید. فیلد clientInfo را مبنای احراز هویت عامل اصلی ندانید؛ این مقدار صرفاً ادعایی از سمت کلاینت است.

همین هشدار درباره‌ی io.modelcontextprotocol/serverInfo در متادیتای پاسخ هم صدق می‌کند؛ این فیلد برای ثبت در لاگ و اشکال‌زدایی مفید است، اما گواهی امنیتی، سند ریجستری یا تصمیمی برای صدور مجوز نیست.

اعتبارسنجی مسیریابی پیش از ارزیابی خط‌مشی

برای فراخوانی ابزار (tools/call)، بستر انتقال Streamable HTTP شامل این هدرهاست:

MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: notes.export

متد ارسالی در هدر باید دقیقاً با متد درون بدنه یکی باشد. نام موجود در هدر هم باید با params.name مطابقت کند. در صورت مغایرت، قبل از اینکه به مرحله‌ی انتخاب سرور، اعمال RBAC یا کسر کردن توکن از محدودیت نرخ درخواست برسید، درخواست را با خطای -32020 رد کنید.

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

اعتبارسنجی پیام‌های ارسالی روی شبکه باید با این توالی دقیق اجرا شود: ابتدا انواع داده‌ها در JSON-RPC و متادیتا را اعتبارسنجی کنید، مقادیر هدر را با بدنه بسنجید، و سپس پشتیبانی شدن نسخه‌ی تطبیق‌یافته را بررسی کنید. در صورت مغایرت هدر، پاسخ HTTP 400 همراه با خطای -32020 بازگردانید. اگر هدر و بدنه روی نسخه‌ای نامعتبر توافق داشتند، پاسخ HTTP 400 همراه با کد -32022 و فیلد data با محتوای دقیق {"supported":["2026-07-28"],"requested":"<actual>"} برگردانید. اگر متد ناشناخته بود، پاسخ HTTP 404 با کد -32601 بفرستید.

هر شیء خطا در صورتی که قرارداد سیستم به اطلاعات ساختاریافته برای بازیابی نیاز داشته باشد، فیلد اختیاری data را به همراه دارد. اعلانات (notifications) فاقد فیلد id هستند؛ بنابراین هیچ پاسخی، چه موفقیت و چه خطا در قالب JSON-RPC، دریافت نمی‌کنند. در سطح HTTP، اعلانی که پذیرفته شده باشد با کد وضعیت 202 و بدنه‌ی خالی پاسخ داده می‌شود.

پین کردن تمام ابعاد توصیف‌گر

محاسبه‌ی هش فقط روی متن توضیحات، تغییرات اسکیما و حاشیه‌نویسی‌ها را نادیده می‌گیرد. باید تمام فیلدهایی را که کاربر تأیید کرده به شکل استاندارد (canonical) درآورید و هش کنید:

normalized = json.dumps(tool, sort_keys=True, separators=(",", ":"))
digest = hashlib.sha256(normalized.encode()).hexdigest()

مقدار خلاصه (digest) را تحت کلیدی با نام کامل مثل notes.export، همراه با شواهد ناشر و زمان تأیید ذخیره کنید (فراتر از کدهای این مثال ساده).

در هر بار بازخوانی:

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

تطابق هش تنها پایداری را ثابت می‌کند، نه امنیت را. توصیف‌گر مسموم حتی اگر بی‌نقص پین شده باشد، همچنان مسموم است.

اسکن استاتیک مثل تله‌گذاری عمل می‌کند

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

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

تفکیک دامنه قبل از ادغام

فرض کنید دو سرور هر دو ابزاری به نام search ارائه می‌دهند. هرگز اجازه ندهید ترتیب شناسایی ابزارها تعیین‌کننده باشد.

notes.search
issues.search

نام کامل و پیشونددار همان نام عمومی گیت‌وی است. نگاشت سرورهای پشتیبان را جداگانه ثبت کنید. نام‌های پایدار تضمین می‌کنند که تأییدیه‌ها، لاگ‌های ممیزی، پین‌های هش و مسیریابی Mcp-Name همگی به یک شیء واحد اشاره داشته باشند.

قابلیت‌ها صرفاً اعلام سازگاری هستند

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

مجوزها همچنان بر اساس عامل اصلیِ احراز هویت شده و خط‌مشی منابع تعیین می‌شوند. توالی درست به این صورت است:

1. اعتبارسنجی‌های بستر انتقال را احراز هویت کنید.
2. نسخه، هدرها و ساختار درخواست را اعتبارسنجی کنید.
3. سازگاری قابلیت‌ها را بسنجید.
4. عامل اصلی، ابزار، منبع و آرگومان‌ها را تأیید صلاحیت کنید.
5. درخواست را اجرا کنید یا از کاربر ورودی بخواهید.

حفاظت از تأییدیه بی‌وضعیت در الگوی MRTR

ابزارهای پرپیامد ممکن است به تأیید کاربر نیاز داشته باشند. نسخه‌ی فعلی MCP به‌جای فراخوانی سرور به کلاینت (callback)، از الگوی درخواست‌های چند مرحله‌ای رفت‌وبرگشتی (MRTR) استفاده می‌کند.

پاسخ نخست:

{
  "resultType": "input_required",
  "inputRequests": {
    "confirm": {
      "method": "elicitation/create",
      "params": {
        "mode": "form",
        "message": "Export notes to archive?",
        "requestedSchema": {
          "type": "object",
          "properties": {
            "confirm": {"type": "boolean"}
          },
          "required": ["confirm"]
        }
      }
    }
  },
  "requestState": "opaque-integrity-protected-value"
}

کلاینت ورودی کاربر را می‌گیرد و متد اصلی را با یک شناسه‌ی JSON-RPC جدید دوباره فراخوانی می‌کند:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "notes.export",
    "arguments": {"query": "private", "destination": "archive"},
    "requestState": "opaque-integrity-protected-value",
    "inputResponses": {
      "confirm": {
        "action": "accept",
        "content": {"confirm": true}
      }
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": {"form": {}}
      }
    }
  }
}

هر مقدار درون inputRequests یک درخواست کامل و جاسازی‌شده همراه با method و params است. کلید آن باید دقیقاً با ورودی متناظر در inputResponses مطابقت داشته باشد. دریافت ورودی از نوع فرم به یک ریشه‌ی شیء در requestedSchema نیاز دارد و کلاینت باید حتماً پیش از ارسال درخواست فرم توسط سرور، قابلیت فرم را اعلام کرده باشد.

در نسخه‌ی فعلی، اعلام این قابلیت به دو شکل معتبر انجام می‌شود: مقدار {"elicitation":{}} به‌طور ضمنی از فرم پشتیبانی می‌کند، در حالی که {"elicitation":{"form":{}}} آن را به‌صورت صریح بیان می‌دارد. اگر کلاینت فقط پشتیبانی از آدرس را اعلام کند (مثل {"elicitation":{"url":{}}})، امکان ارسال فرم وجود ندارد؛ در این حالت سرور پاسخ HTTP 400 با خطای -32021 ارسال می‌کند و مقدار data.requiredCapabilities را برابر با {"elicitation":{"form":{}}} قرار می‌دهد.

فیلد requestState را ورودیِ غیرقابل‌اعتماد فرض کنید. آن را امضا یا رمزگذاری کنید، اعتبارسنجی‌اش کنید، و وضعیت آن را به متد، ابزار، تک‌تک آرگومان‌ها، هدف عملیات، زمان انقضا، عامل اصلی و در مواقعی که ارسال مجدد مهم است، به یک نانس (nonce) یک‌بارمصرف مقید سازید. در کد این درس از HMAC و تطبیق دقیق آرگومان‌ها استفاده شده است تا این مرزبندی به‌خوبی دیده شود.

دفتر ثبت نانس‌ها نباید درون یک شیء گیت‌وی نگهداری شود. مدل اجرایی این درس، یک مخزن ثبت نانس محدود و با تاریخ انقضا (TTL) تزریق می‌کند که چندین نمونه از گیت‌وی می‌توانند آن را به اشتراک بگذارند. ادعای اتمیک (atomic claim) روی نانس، همان مرز اجرای عملیات است: فقط پاسخ تأییدشده و معتبر یا رد نهایی صریح، وضعیت را می‌سوزاند. پاسخ‌های ناقص یا لغو شده (cancel) هیچ کدی را اجرا نمی‌کنند و وضعیت را برای تلاش مجدد تا رسیدن به زمان انقضا باز می‌گذارند. در ناوگان‌های عملیاتی، به همین ادعای شرطی روی حافظه‌ی ذخیره‌سازی پایدار و مشترک نیاز خواهید داشت.

داده‌های پنهان تأییدیه را درون نشست‌های پروتکل ذخیره نکنید. هر نمونه‌ای از سرور باید بتواند تلاش مجدد را به‌تنهایی اعتبارسنجی کند.

قاعده‌ی دوتایی برای فراخوانی‌های پرخطر

هر فراخوانی را در سه بعد ارزیابی کنید:

• داده‌های غیرقابل‌اعتماد را مصرف می‌کند.
• به داده‌های حساس دسترسی دارد.
• باعث ایجاد یک پیامد یا اقدام خارجیِ مهم می‌شود.

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

محدود کردن اختیارات قبل از اجرا

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

1. فعل نوع‌دار (Typed verb): عملیاتی مشخص و محدود ارائه دهید (مثل archive_note)، نه یک ابزار همه‌کاره مثل run یا request که اختیارات نامحدودی دارد.
2. آرگومان‌های اعتبارسنجی‌شده: تا حد امکان اسکیماهای بسته به کار ببرید، فیلدهای ناشناخته را رد کنید، شناسه‌ها را یک بار نرمال‌سازی کنید، سقف اندازه بگذارید، و مقصد، مستأجر (tenant) و مالکیت منبع را قبل از ارزیابی خط‌مشی (policy evaluation) بسنجید.
3. مجوز لحظه‌ای: عامل اصلیِ احراز هویت شده را مستقیماً به فعل، منبع، محیط و آرگومان‌های نرمال‌سازی‌شده پیوند بزنید. حاشیه‌نویسی‌های ابزار و قابلیت‌های کلاینت به خودی خود چنین مجوزی صادر نمی‌کنند.
4. تأیید مقید به اقدام: برای فراخوانی‌های پرپیامد، تأییدیه را به خلاصه‌ی فعل نوع‌دار و آرگومان‌های نرمال‌سازی‌شده، به‌علاوه‌ی عامل اصلی، زمان انقضا و خط‌مشی یک‌بارمصرف مقید کنید. با تغییر هر فیلد، تصمیم‌گیری باید از اول انجام شود.
5. رد درخواست به‌عنوان حالت استاندارد: رد دسترسی، انقضای تأییدیه، لغو توسط کاربر و مقصد ناامن را نتایج عادی سیستم در نظر بگیرید که نباید هیچ اثر جانبی اجرا کنند. هرگز رد درخواست را به اجرای یک ابزار جایگزین با دسترسی کمتر تبدیل نکنید.
6. شواهد ممیزی پاک‌سازی‌شده: اطلاعات لازم را ثبت کنید: چه کسی درخواست داد، چه توصیف‌گر و چه نسخه‌ای از خط‌مشی استفاده شد، چه هدف نرمال‌سازی‌شده‌ای تأیید شد، چرا درخواست پذیرفته یا رد شد، و آیا اجرا آغاز شد یا خیر. به‌جای اسرار، خلاصه‌ها یا مقادیر پوشانده‌شده (redacted) را ثبت کنید.

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

مسیرهای تعامل مدرن و موروثی

قابلیت‌های Roots ،Sampling و Logging در نسخه‌ی جدید 2026-07-28 منسوخ شده‌اند. یک گیت‌وی ممکن است کدهای مربوط به این کانال‌های قدیمی را صرفاً برای سازگاریِ مبتنی بر شرطِ نسخه نگه‌داری کند.

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

بررسی‌های بستر انتقال در مدل بی‌وضعیت

• پیام‌های مدرن MCP را فقط روی تک‌اندپوینت POST بپذیرید.
• در پاسخ به متدهای GET و DELETE مدرن، کد 405 برگردانید.
• مقدار Mcp-Session-Id تولید نکنید و به آن وابسته نباشید.
• هدرهای نشست و بازپخش قدیمی را به‌عنوان ورودی‌های معتبر نادیده بگیرید.
• در پاسخ به آن POST، فرمت JSON یا رویدادهای SSE در دامنه‌ی همان درخواست را برگردانید.
• متد subscriptions/listen را فقط برای دریافت اعلان‌های بلندمدتِ تغییرات که کاربر صریحاً فعال کرده استفاده کنید.

پیاده‌سازی عملی

فایل code/main.py یک مدل جمع‌وجور از گیت‌وی امنیتی را به‌صورت in-process پیاده‌سازی می‌کند. این کد کل توصیف‌گرهای ابزار را استانداردسازی و پین می‌کند، مسموم‌سازی متادیتا و هم‌پوشانی نام‌ها را گزارش می‌دهد، بسته‌ی درخواست‌های مدرن و هدرهای مسیریابی را می‌سنجد، و عملیات برون‌بری تأییدشده‌ی دو مرحله‌ای را به همراه requestState امضاشده و مخزن نانس‌های اشتراکیِ تزریق‌شده به اجرا درمی‌آورد.

کار این مدل درست پس از اینکه تطبیق‌دهنده (adapter) پروتکل HTTP بدنه JSON و هدرهای مسیریابی را پارس کرد آغاز می‌شود و بررسی Content-Type یا Accept را انجام نمی‌دهد. می‌توانید همین توزیع‌کننده را به تطبیق‌دهنده‌ی کامل Streamable HTTP در درس 09 وصل کنید؛ کدی که وجود Content-Type: application/json و هدر Accept حاوی هم‌زمان application/json و text/event-stream را الزامی می‌داند.

کد را اجرا کنید:

cd phases/13-tools-and-protocols/15-mcp-security-tool-poisoning
python3 code/main.py
python3 -m unittest discover code/tests -v

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

استفاده از ابزارهای واقعی

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

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

خروجی این درس

حاصل این درس سند outputs/skill-mcp-threat-model.md است. این سند مدل تهدیدات پروتکل فعلی را در ابعاد متادیتا، مسیریابی، قابلیت‌ها، مجوزها، MRTR، حافظه‌ی کش، ریجستری و مرزهای سازگاری تدوین می‌کند.

تمرین‌ها

1. عامل اصلیِ احراز هویت شده و تصمیم لحظه‌ایِ صدور مجوز را به وضعیت مهروموم‌شده‌ی MRTR مقید کنید و درخواست مجدد را در صورتی که با عامل دیگری ارسال شد رد نمایید.
2. مخزن حافظه‌محور ثبت نانس را با یک عملیات درج شرطی پایدار (persistent conditional insert) جایگزین کنید و اثبات کنید دو پروسس هم‌زمان نمی‌توانند یک نانس مشترک را بسوزانند.
3. بلافاصله پس از ادعای نانس اما قبل از اجرای برون‌بری شبیه‌سازی‌شده، خطایی تزریق کنید. سازوکار تراکنش یا قانون idempotent بودن را طوری طراحی و تست کنید که بازیابی خطا امن باشد.
4. بدون دستکاری فیلد توضیحات، inputSchema یک ابزار را تغییر دهید و مطمئن شوید پین بودن کل توصیف‌گر این تغییر را ردیابی می‌کند.
5. خط‌مشی‌ای بنویسید که اگر خروجی tools/list به ازای عامل‌های اصلیِ مختلف فرق دارد، کش عمومی آن را ممنوع کند.
6. سروری قدیمی را پشت گیت‌وی شبیه‌سازی کنید؛ تمام رفتارهای مربوط به دست‌دادن و نشست‌ها را پشت یک branch صریح برای سازگاری با نسخه‌ی 2025-11-25 ببرید.

اصطلاحات کلیدی

برای مطالعه‌ی بیشتر

• راهنمای امنیت و اعتماد در MCP
• درخواست‌های چند مرحله‌ای رفت‌وبرگشتی (MRTR)
• بستر انتقال Streamable HTTP
• قابلیت‌های منسوخ‌شده