یک نقطهٔ کنترل واحد و قابل حسابرسی، اکنون به استاندارد طلایی برای ایمنسازی عاملهای هوش مصنوعی تبدیل شده است. برای عملیاتی کردن این اصل، مایکروسافت در ۲۸ ژوئیه ۲۰۲۶ ابزار Agent Governance Toolkit را منتشر کرد. این مخزن کد که تحت لایسنس MIT منتشر شده، غریزهٔ مبهم امنیتی را به یک مشخصهٔ سخت و قابل آزمایش برای مرز پروتکل زمینهٔ مدل (Model Context Protocol - MCP) تبدیل میکند.
با تکیه بر پوششهای قبلی ما دربارهی نوسانات حقوقی پیرامون دادههای آموزشی هوش مصنوعی و مسئولیت شرکتها، مانند نبرد حقوقی میان نیویورک تایمز و مایکروسافت، این ابزار روی ریسک متفاوتی اما به همان اندازه حیاتی تمرکز دارد: لحظهای که یک عامل (Agent) — یعنی برنامهای هوشمند که میتواند بهطور مستقل کارهای پیچیده را انجام دهد، شبیه به کارمند اداری که دسترسی به ابزارهای مختلف دارد — با کدی تعامل میکند که کنترل آن در دست خودش نیست. برای اکثر متخصصان، ایمنسازی این مرز تا پیش از این به معنای دنبال کردن توصیههای کلی مانند «سرورهای خود را بررسی کنید»، «پاسخها را اسکن کنید» یا «در صورت خطا، دسترسی را ببندید» بود؛ توصیههایی که هیچ محک (Benchmark) اندازهگیریشدنی نداشتند. در همین راستا، ما چکلیست ۶ مرحلهای برای ایمنسازی سرورهای MCP پیش از استقرار را منتشر کرده بودیم تا خلأ این استانداردهای عملیاتی را پر کنیم.
طبق اعلام مایکروسافت، مرکز ثقل این انتشار، نسخه ۱.۰ «دروازهٔ امنیتی MCP» است. این مشخصه، یک لایهٔ رهگیری (Interception Layer) برای اجرای سیاستها تعریف میکند که هر فراخوانی ابزار و هر پاسخ باید از آن عبور کند. این سند با زبان استاندارد RFC-2119 نوشته شده است؛ به این معنی که عباراتی مثل «باید» (MUST)، «باید سعی کند» (SHOULD) و «مجاز است» (MAY) الزامات فنی و ساختاری هستند که بار عملیاتی دارند. برای اینکه پیادهسازیها صرفاً بر اساس «حس خوب» (Vibe-check) نباشند، مایکروسافت یک مجموعهٔ تطبیق شامل ۱۲۷ تست را علیه یک پیادهسازی پایتونی ارائه داده است تا دقت اجرای استاندارد تضمین شود.
سازوکارهای فنی دروازه
بر اساس مستندات این ابزار، دروازهٔ امنیتی یک ترتیب عملیاتی سختگیرانه را برای رهگیری فراخوانی ابزارها اجرا میکند:
- ابتدا لیست سیاه (Deny-list) و سپس لیست سفید (Allow-list) را بررسی میکند.
- یک بررسی برای ابزارهای حساس فعال میکند. اگر پاسخ بازگشتی از تابع بازگشتی تأیید (Approval Callback) بهجای «تأیید شده» (APPROVED)، عبارت «رد شد» (DENIED) یا «در انتظار» (PENDING) باشد، فراخوانی بلافاصله مسدود میشود.
- برای جلوگیری از تحلیل رفتن منابع و حملات Denial-of-Service، محدودیت نرخ (Rate Limit) اعمال میکند.
اسکن پاسخها و تهدیدات
پاسخهای ابزار از طریق سه اقدام ممکن مدیریت میشوند: مسدود کردن (BLOCK)، پاکسازی (SANITIZE) — که در آن بخشهای مخرب حذف شده و بقیه متن عبور میکند — یا ثبت در گزارش (LOG). این اسکنر پنج دستهبندی اصلی تزریق و نشت داده را هدف قرار میدهد:
- تزریق تگهای دستوری: شناسایی نشانگرهایی مانند
<SYSTEM>یا[INST]که برای تغییر رفتار مدل استفاده میشوند. - تزریقهای امری: شناسایی دستوراتی نظیر «دستورات قبلی را نادیده بگیر».
- نشت اعتبارنامهها و اطلاعات شخصی (PII): شناسایی دادههای حساس مانند شماره کارتهای اعتباری و شمارههای تأمین اجتماعی (SSN).
- URLهای استخراج داده: شناسایی لینکهایی که برای جاسوسی و انتقال دادهها از طریق پارامترهای پرسوجو (Query Parameters) استفاده میکنند.
این رویکرد تکمیلی است برای آنچه ما در تحلیل مسدودسازی خروج دادهها در برابر پیشگیری از تزریق در چهارچوب MCP بررسی کردیم و بر لزوم دفاع چندلایه تأکید داشتیم.
این موارد در یک فهرست نامگذاری شده به نام MCPThreatType تعریف شدهاند که شامل دقیقاً ۶ تهدید مشخص است:
- TOOL_POISONING: وجود دستورات مخرب در تعریف یک ابزار.
- RUG_PULL: تغییرات در توصیف یا طرحواره (Schema) ابزار پس از ثبت اولیه.
- CROSS_SERVER_ATTACK: تلاشی از سوی یک ابزار برای دسترسی به ابزارهای موجود در سرورهای دیگر.
- CONFUSED_DEPUTY: ابزاری که سعی میکند سطح دسترسی خود را ارتقا دهد یا از طرف عامل دیگری عمل کند.
- HIDDEN_INSTRUCTION: محمولههای کدگذاری شده، کامنتهای پنهان یا استفاده از کاراکترهای نامرئی یونیکد.
- DESCRIPTION_INJECTION: تزریق دستورات (Prompt Injection) که در توصیف ابزار جاسازی شده است.
یکپارچگی طرحواره و حالتهای شکست
برای جلوگیری از حملات Rug-pull — جایی که یک ابزار مورد اعتماد در یک نسخهٔ جدید به ابزاری خصمانه تبدیل میشود — این ابزار از یک آشکارساز تغییر طرحواره (Schema-drift detector) استفاده میکند. این مکانیزم اثر انگشت (Fingerprint) هر ابزار را در هر بار بارگذاری میگیرد؛ هرگونه تغییر در این اثر انگشت باید یک هشدار بحرانی (CRITICAL alert) ایجاد کند. این نیاز به استانداردسازی، بهویژه پس از آنکه مشخص شد ۲۵٪ از استقرارهای پروتکل MCP دارای حفرههای امنیتی شدید هستند، بیش از پیش حیاتی شده است.
سامانه بر اساس اصل «شکست بسته» (Fail-closed) طراحی شده است. طبق مستندات، هر مؤلفه — از دروازه و اسکنر گرفته تا محدودکننده نرخ و مجری احراز هویت — باید در صورت بروز هرگونه خطا، دسترسی را قطع کند. یک جدول تطبیق، حالت شکست هر مؤلفه را به پیشفرض امن آن متصل میکند. اگر اسکنر کرش کند، بهجای عبور دادن پاسخ، آن را مسدود میکند تا امنیت فدا نشود.
این چرخش فنی، گفتوگو را برای توسعهدهندگان تغییر میدهد. تیمها دیگر نمیپرسند «آیا پاسخهای ما بهاندازه کافی اسکن شدهاند یا نه؟»، بلکه میپرسند «آیا دروازهٔ ما از ۱۲۷ تست رسمی عبور میکند؟». این یعنی سطح امنیت از یک چکلیست ذهنی و ذهنیاتی به یک معیار باینری (قبول/رد) تبدیل شده است.
این چارچوب همچنین به عنوان ستونی برای BRACE عمل میکند؛ یک چارچوب باز و مستقل از فروشنده که برای ایمنسازی عاملهای خودمختار بر اساس تحقیقات دنیای واقعی و گزارشهای حوادث طراحی شده است. راهنمای اکوسیستم BRACE به این الگوی دروازهٔ MCP اشاره میکند و میپرسد که کدام کنترلهای سختگیرانه و ملموس میتوانستند جلوی حوادث تاریخی خاص را بگیرند.
متخصصان اکنون باید تمام ترافیک MCP را از یک نقطهٔ خروجی واحد و بسته عبور دهند. با اجتناب از بررسیهای پراکنده در سراسر کد عامل، اطمینان حاصل میشود که پاسخ به سؤال «آیا این امن است؟» فقط در یک مکان داده میشود و در صورت بروز هرگونه مشکل، فقط یک نقطه برای حسابرسی وجود دارد. چه از ابزار مایکروسافت استفاده کنید و چه نسخه سفارشی بسازید، هدف این است که یک نقطه شکست واحد داشته باشید که پیشفرض آن، امنیت باشد.
گام بعدی شما
- اگر از پروتکل زمینهٔ مدل (MCP) در پروژههای خود استفاده میکنید، مجموعه ۱۲۷ تست مایکروسافت را روی لایهٔ امنیتی خود اجرا کنید.
- ساختار دسترسی ابزارها را از حالت «اجازه به همه بهجز...» به مدل «ممنوعیت برای همه بهجز...» تغییر دهید.
- مکانیزم اثر انگشت طرحواره (Schema Fingerprinting) را برای ابزارهایی که از سرورهای خارجی میگیرید، پیادهسازی کنید.
اما تأمین سختافزاری این لایههای امنیتی در مقیاس بالا چالشهای جدیدی ایجاد میکند — به تحلیل ما دربارهی بهینهسازی هزینه استنتاج در GPUها مراجعه کنید.
گفتگو