mcpward: ابزاری برای جلوگیری از تغییر رفتار ناگهانی عامل‌های هوش مصنوعی

تصور کنید یک تغییر کوچک و بی‌سروصدا در توصیف یک ابزار، بدون اینکه هیچ خطای طرح‌واره (Schema Error) یا فنی ایجاد کند، منطق تصمیم‌گیری عامل هوش مصنوعی شما را به‌کل تغییر دهد. این یک کابوس واقعی برای توسعه‌دهندگان است؛ جایی که کد از نظر سینتکسی سالم است اما «رفتار» مدل به دلیل تغییر در دستورالعمل‌های دریافتی، به بیراهه می‌رود. برای جلوگیری از این اتفاق، ابزار متن‌باز mcpward در ۲۱ ژوئیه ۲۰۲۶ منتشر شد تا قراردادهای سرورهای پروتکل زمینهٔ مدل (Model Context Protocol - MCP) را دقیقاً مانند وابستگی‌های npm مدیریت کند و به توسعه‌دهندگان اجازه دهد این قراردادها را در خط لوله‌های CI «قفل» (Pin) کرده و تفاوت‌های آن‌ها را بررسی (Diff) کنند.

bیشتر توسعه‌دهندگان وابستگی‌های کد خود را با استفاده از فایل‌های قفل (Lockfiles) تثبیت می‌کنند و هنگام تغییر آن‌ها، تفاوت‌ها را بازبینی می‌کنند. با این حال، سرورهای MCP که یک عامل به آن‌ها وابسته است، معمولاً فاقد چنین سخت‌گیری‌هایی هستند. وقتی یک سرور به‌روزرسانی می‌شود، عامل به‌طور کورکورانه به نام‌ها، توصیفات و طرح‌واره‌های JSON ارائه شده توسط tools/list اعتماد می‌کند. از آنجا که این توصیفات در واقع همان دستورالعمل‌هایی هستند که مدل برای تصمیم‌گیری درباره «چه ابزاری چه کاری انجام می‌دهد» و «چه زمانی باید آن را فراخوانی کند» می‌خواند، یک تغییر متنی جزئی در توصیف، در عمل به معنای تغییر منطق در مغز عامل است. در این مدل سنتی، هیچ نسخه قفل‌شده‌ای، هیچ بررسی یکپارچگی (Integrity Check) و هیچ تفاوت قابل بازبینی وجود ندارد.

به نقل از مستندات پروژه، mcpward بر پایه دستاوردهای Invariant Labs ساخته شده است؛ آزمایشگاهی که ابزار mcp-scan را توسعه داد و از آوریل ۲۰۲۵ تغییرات در هش ابزارها را رصد می‌کرد. تفاوت اصلی در این است که mcpward دروازهٔ امنیتی را از دستگاه محلی به خط لوله ساخت (CI Pipeline) منتقل می‌کند. در حالی که ابزارهای قبلی بر این تمرکز داشتند که آیا یک لپ‌تاپ را در برابر «سایه‌اندازی ابزار» (Tool Shadowing یا ارتقای سطح دسترسی از طریق منشأ متقاطع) ایمن کنند و حالت‌های پروکسی با گاردریل‌های زنده ارائه می‌دادند، mcpward تمرکز خود را بر این می‌گذارد که آیا قرارداد یک وابستگی از آخرین نسخه منتشر شده تغییر کرده است یا خیر. برای کسانی که به دنبال استقرار امن ابزارهای دیتابیس هستند، پیاده‌سازی لایه‌های امنیتی سخت‌گیرانه گامی حیاتی برای تبدیل ابزارهای آزمایشی به نسخه تولیدی است. این ابزار به عنوان یک دروازه CI طراحی شده است که علیه سرورهای داخلی اجرا می‌شود بدون اینکه توصیفات ابزارها به هیچ API خارجی ارسال کند.

مکانیسم قفل کردن قراردادها

این ابزار از طریق دو دستور اصلی عمل می‌کند: npx mcpward baseline برای ثبت وضعیت فعلی سرور در یک فایل قفل (Snapshot)، و npx mcpward diff برای متوقف کردن ساخت (Build) در صورت بروز هرگونه تغییر یا انحراف (Drift) در وضعیت. این سیستم چهار بُعد حیاتی از قرارداد سرور را رصد و ثبت می‌کند: نام ابزار، هش توصیفات (Description Hash)، طرح‌واره‌های ورودی/خروجی (Input/Output Schemas) و یادداشت‌ها (Annotations).

بر اساس گزارش‌های فنی، اگر سروری به‌روزرسانی شود، گزارش تغییرات (Drift Report) نقاط شکست مشخص را برجسته می‌کند. برای نمونه، ممکن است سیستم هشدار دهد که توصیف ابزار «echo» تغییر کرده است (که می‌تواند نشانه‌ای از یک Rug-pull یا تغییر ناگهانی رفتار باشد)، یا ابزار «compute» یک ویژگی اجباری به نام «multiplier» به طرح‌واره ورودی خود اضافه کرده است، و یا ابزار «read_data» تغییر وضعیت readOnlyHint را از «درست» به «نادرست» تجربه کرده است. همچنین، اگر ابزاری مانند «removed_tool» به‌طور کامل حذف شود، فرآیند ساخت با کد خروج ۱ (Exit Code 1) متوقف می‌شود.

تفکیک تغییرات تخریبی و غیرتخریبی

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

• تغییرات تخریبی (به‌طور پیش‌فرض باعث شکست ساخت می‌شوند): حذف ابزار، تغییر در توصیفات (Rug-pulls)، افزودن فیلدهای اجباری به ورودی‌ها، محدود کردن انواع داده (Narrowing Types)، سخت‌گیرانه‌تر کردن شمارشگرها (Tightening Enums) یا تغییر readOnlyHint از درست به نادرست (و همچنین تغییر destructiveHint از نادرست به درست).
• تغییرات غیرتخریبی (باعث شکست ساخت نمی‌شوند): افزودن فیلدهای اختیاری، گسترش انواع داده (Widening Types)، کاهش محدودیت‌ها یا اضافه کردن ابزارهای کاملاً جدید به سرور.

این طبقه‌بندی به صورت یک «تابع خالص» (Pure Function) پیاده‌سازی شده است و دارای یک مجموعه تست جامع مبتنی بر نمونه‌های ثابت (Fixture-backed) است تا اطمینان حاصل شود که مرز بین تغییرات ایمن و ناایمن کاملاً دقیق است.

اعتبارسنجی سخت‌گیرانه و ایمنی

این ابزار فراتر از مقایسه ساده تفاوت‌ها، انطباق کامل با پروتکل را اجباری می‌کند؛ مواردی شامل دست‌دادن (Handshake)، مذاکره نسخه (Version Negotiation)، ثبات قابلیت‌ها (Capability Consistency) و صحت ساختاری JSON-RPC. طبق اعلام توسعه‌دهندگان، یکی از نقاط تمرکز اصلی، اعتبار‌سنجی «قرارداد خطای دو لایه» است. پروتکل MCP بین خطاهای پروتکل (که یک شیء خطای JSON-RPC است) و خطاهای ابزاری (نتیجه‌ای موفق که در آن isError: true است) تفاوت قائل می‌شود. ابزاری که در اجرای وظیفه خود شکست می‌رود — مثلاً خطای «فایل پیدا نشد» یا خطای ۵۰۰ از یک سرویس بالادستی — باید لایه دوم (خطای ابزاری) را برگرداند. این تفکیک اهمیت زیادی دارد، چرا که اشتباه در مدیریت خطاهای ۴۰۴ می‌تواند منجر به قطع دسترسی کامل عامل‌ها به ابزارهای حیاتی شود. سرورها معمولاً این دو را جابه‌جا پیاده می‌کنند که این امر باعث تغییر در نحوه مدیریت شکست توسط کلاینت‌ها می‌شود.

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

• شناسایی مسموم‌سازی ابزار (Tool-Poisoning Heuristics): شناسایی عباراتی شبیه به حملات تزریقی در توصیفات، رصد کاراکترهای یونیکد با عرض صفر (Zero-width unicode)، شناسایی طرح‌واره‌هایی که درخواست کلیدهای API یا رمز عبور می‌کنند، یا مقدار readOnlyHint که با ماهیت تخریبی آشکار یک ابزار در تضاد است. در این راستا، مقایسه روش‌های مسدودسازی خروج داده‌ها و پیشگیری از تزریق می‌تواند درک بهتری از لایه‌های حفاظتی پروتکل MCP ارائه دهد.
• مجموعه‌های رفتاری: استفاده از موارد定义‌شده در YAML با توأیدیه (Assertion) از طریق JSONPath. برای مثال، یک تست می‌تواند تأیید کند که نبود یک فایل باید «خطای ابزار» برگرداند، در حالی که پارامترهای نامعتبر باید «خطای پروتکل» با کد ۳۲۶۰۲- ایجاد کنند.
• بودجهٔ تأخیر (Latency Budgets): اندازه‌گیری تأخیر p50 و p95 برای هر ابزار و مقایسه آن با آستانه‌های قابل پیکربندی.

خروجی‌ها در قالب استاندارد SARIF ارائه می‌شوند تا یافته‌ها مستقیماً در تب Security گیت‌هاب قرار گیرند.

فلسفه آزمایش و تست

برای جلوگیری از تبدیل شدن ابزار به یک «تولیدکننده اعتماد کاذب»، رویکرد تست به‌طور عمدی «پارانوئید» طراحی شده است. هر بررسی (Check) در برابر سرورهای نمونه کنترل‌شده توسعه یافته است: یک سرور کاملاً منطبق، یک سرور عمداً بدساخت (Malformed)، یک جفت سرور که دقیقاً در یک کلاس تغییر با هم تفاوت دارند، یک سرور کند و یک سرور مسموم. هر تست باید یک «تست منفی» داشته باشد تا ثابت کند که در صورت بروز خطا، واقعاً می‌تواند وضعیت را «قرمز» (Fail) کند.

طبق مستندات پروژه در GitHub، ابزار mcpward تحت مجوز MIT است، کاملاً محلی اجرا می‌شود و به هیچ حساب کاربری، API call یا سیستم تله‌متری نیاز ندارد. این ابزار به صورت یک «جعبه سیاه» (Black-box) در برابر سرورهایی که با هر زبانی نوشته شده‌اند و از طریق stdio یا Streamable HTTP ارتباط برقرار می‌کنند، عمل می‌کند.

برای کسانی که در حال پیاده‌سازی عامل‌ها در محیط عملیاتی (Production) هستند، گام بعدی ادغام بررسی تغییرات قراردادها در GitHub Actions یا GitLab Pipelines است تا «انحراف توصیفات» (Description Drift) را پیش از آنکه به ترافیک کاربران برسد، شکار کنند. می‌توانید با دستورات npx mcpward init و npx mcpward run شروع کنید.

گام بعدی شما

• اگر عامل‌های هوش مصنوعی را در محیط عملیاتی مستقر کرده‌اید، بررسی تغییرات قراردادها را به GitHub Actions یا GitLab اضافه کنید.
• با دستور npx mcpward init اولین خط پایه (Baseline) سرورهای خود را ثبت کنید.
• تست‌های رفتاری YAML را برای ابزارهای حساس خود بنویسید تا از صحت پاسخ‌ها مطمئن شوید.

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