آداپتور همگانی: هوش مصنوعی و معماری پروتکل زمینه مدل

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

این راهنما برای تیم‌های پلتفرم، امنیت و محصولی است که یکپارچه‌سازی MCP را برای محیط عملیاتی طراحی می‌کنند. مبنا، نسخه نهایی 2026-07-28 است. در این نسخه، هسته پروتکل بدون نشست و stateless شده، اطلاعات نسخه و قابلیت همراه درخواست می‌آید و الگوی میزبان، کلاینت و سرور حفظ شده است. این تغییرها مسیریابی را ساده‌تر می‌کنند، ولی مسئولیت نگهداری وضعیت کسب‌وکار، کنترل دسترسی و بازیابی را از برنامه نمی‌گیرند.

مرز اعتماد میزبان، کلاینت و سرور را رسم کنید

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

هر اتصال یک مرز اعتماد مستقل است:

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

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

سازگاری پروتکل را با اجازه عملیاتی اشتباه نگیرید

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

برای نمونه، invoice.lookup می‌تواند خواندنی باشد، invoice.draft_credit فقط برای حساب‌های واگذارشده مجاز شود و invoice.issue_credit بالاتر از سقف مالی تأیید مدیر مالی بخواهد. یک ابزار کلی با پارامتر mode این تفاوت‌ها را پنهان می‌کند. ابزارهای باریک و جدا، سیاست و گزارش روشن‌تری می‌سازند.

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

کشف پویا را با کنترل تغییر همراه کنید

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

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

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

مجوز را برای مقصد دقیق طراحی کنید

برای سرور دوردست، مشخصات مجوز MCP نسخه 2026-07-28 مبنای انتقال است. این مشخصات از کشف OAuth استفاده می‌کند و مقصد توکن را صریح می‌خواهد. قاعده عملی این است: توکنی که برای یک سرور MCP صادر شده فقط همان سرور، برای همان subject و دامنه اجازه، آن را بپذیرد.

بهترین رویه امنیتی OAuth 2.0 در RFC 9700 محدودسازی امتیاز توکن و دفاع در برابر بازپخش را توصیه می‌کند. توکن دریافتی از کلاینت MCP را بدون تغییر به CRM، مخزن کد یا درگاه پرداخت نفرستید. عبور مستقیم توکن مرز audience را می‌شکند و گزارش حسابرسی را مبهم می‌کند. سرور باید برای هویت خود و اقدام واگذارشده، توکن پایین‌دستی جدا بگیرد.

توکن کوتاه‌عمر، نگهداری امن، بررسی دقیق audience، تطبیق کامل redirect URI، PKCE در محل مناسب و ابطال سریع ضروری‌اند. سرور محلی هم امن فرض نمی‌شود؛ آن را با دسترسی محدود فایل، فرایند، متغیر محیطی و شبکه در sandbox اجرا کنید.

سیاست و تأیید باید پیش از اجرا قرار گیرند

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

تأیید یک دکمه تزئینی نیست. باید زمینه کافی نشان دهد، زمان انقضا داشته باشد، هویت تأییدکننده را ثبت کند و همراه اجرای واقعی بماند. طراحی تأیید انسانی این مرز را با جزئیات بیشتری توضیح می‌دهد.

تلاش دوباره را idempotent و وضعیت را صریح کنید

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

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

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

تصمیم را مشاهده کنید، نه فقط درخواست HTTP را

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

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

سطح حمله مخصوص اتصال را آزمون کنید

راهنمای امنیت MCP نسخه 2026-07-28 درباره confused deputy، عبور توکن، SSRF، ربایش handle وضعیت، آلودگی سرور محلی، URL مجوز و حداقل‌سازی scope توضیح می‌دهد. هر مورد باید به کنترل قابل اجرا و آزمون منفی تبدیل شود.

در کشف metadata، کلاینت ممکن است URL تحت کنترل مهاجم را fetch کند. parser بالغ، HTTPS اجباری، مسدودسازی مقصدهای خصوصی و link-local، بررسی هر redirect و egress proxy لازم است. handle وضعیت به caller احرازشده بسته شود. هنگام نصب سرور محلی، فرمان کامل نشان داده و فقط پس از رضایت صریح در محیط محدود اجرا شود. اگر proxy از client ID مشترک بالادستی استفاده می‌کند، رضایت باید برای هر کلاینت جدا ثبت شود.

فهرست ده ریسک برتر برنامه‌های Agentic در OWASP برای ۲۰۲۶ چک‌لیست وسیع‌تری برای ربایش هدف، اختیار بیش‌ازحد، سوءاستفاده ابزار، مسموم‌سازی حافظه، خرابی آبشاری و ردپای ناکافی است. این فهرست گواهی انطباق نیست؛ مبنای سناریوهای آزمون است.

بازگشت را در سه لایه جدا بسازید

«خاموش‌کردن عامل» برای بیشتر رخدادها بسیار کلی است. سه کنترل مستقل داشته باشید:

1. بازگشت قابلیت: یک ابزار یا نسخه شِمای آن حذف شود.
2. بازگشت اعتبارنامه: grant کاربر، client یا توکن پایین‌دستی ابطال شود، بدون توقف ترافیک سالم.
3. بازگشت کسب‌وکار: تغییر ثبت‌شده در سامانه مرجع معکوس یا جبران شود.

feature flag باید بر اساس سرور، ابزار، tenant، سطح اقدام و محیط قابل اعمال باشد. نسخه last-known-good رجیستری و مسیر downgrade آزموده‌شده نگه دارید. برای ابزار پراثر، circuit breaker را با نرخ خطا، حجم غیرعادی، تعداد رد سیاست یا گیرنده ناشناخته فعال کنید. توقف اجرا نباید شواهد و وضعیت کارهای در جریان را پاک کند.

ارزش اتصال و کیفیت کنترل را با هم بسنجید

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

• زمان میانه افزودن ابزار تأییدشده و استفاده دوباره آن در میزبان دوم؛
• نرخ تکمیل پس از بررسی نتیجه در سامانه مقصد، نه صرفاً پاسخ 200؛
• رد سیاست تفکیک‌شده به حفاظت درست و پیکربندی غلط؛
• زمان تأیید، انصراف و نرخ تأیید دوباره پس از تغییر آرگومان؛
• نرخ اثر جانبی تکراری پس از retry؛
• زمان کشف شِمای کهنه و غیرفعال‌سازی ابزار پرریسک؛
• تلاش دسترسی میان tenantها و اقدام غیرمجاز موفق؛
• زمان ابطال، جبران و بازگرداندن خدمت؛
• نرخ اصلاح کاربر و کاهش زمان چرخه کسب‌وکار.

از یک گردش‌کار برگشت‌پذیر، یک مالک و فهرست ابزار کوچک شروع کنید. توضیح آلوده ابزار، منبع مسموم، تغییر شِما، توکن سرقت‌شده، URL مخرب، تأیید بازپخش‌شده، درخواست تکراری و شکست نیمه‌کاره مقصد را red-team کنید. فقط زمانی دامنه را گسترش دهید که KPI کسب‌وکار و کنترل، هر دو بهتر شده باشند.

یادداشت منابع

بازبینی محتوایی در ۲۰۲۶-۰۷-۳۰ انجام شد. ادعاهای معماری بر نسخه نهایی 2026-07-28 MCP تکیه دارند. توصیه‌های امنیتی با مشخصات مجوز و راهنمای امنیت جاری MCP، راهنمای IETF برای OAuth، برنامه استاندارد عامل‌های NIST و چارچوب ریسک Agentic در OWASP تطبیق داده شدند.

• معماری MCP، نسخه ۲۰۲۶-۰۷-۲۸
• مشخصات مجوز MCP، نسخه ۲۰۲۶-۰۷-۲۸
• بهترین رویه‌های امنیتی MCP، نسخه ۲۰۲۶-۰۷-۲۸
• بهترین رویه امنیتی OAuth 2.0، RFC 9700
• برنامه استانداردهای عامل هوش مصنوعی NIST
• ده ریسک برتر برنامه‌های Agentic در OWASP برای ۲۰۲۶