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

چرا نگهدارندگانِ خود پروتکل راکشان را اصلاح کردند

در ۲۸ جولای ۲۰۲۶، تیمِ توسعه پروتکل زمینه مدل (MCP) یک به‌روزرسانی مشخصه منتشر کرد که تمام تمرکزش روی مجوزدهی (Authorization) بود: اعتبارسنجی صادرکننده (Issuer Validation)، اعتبارنامه‌های کلاینت وابسته به صادرکننده، و اسناد متادیتا شناسه کلاینت به عنوان روش پیش‌فرض ثبت‌نام. به زبان ساده، معماران پروتکل اعتراف کردند مدل اعتماد اصلی‌شان در مواجهه با محیط تولید (Production) زنده نمانده است.

اگر نویسندگانِ خودِ مشخصه در این عمق به بازنگری امنیتی نیاز داشتند، ابزاری که بابک در یک آخر هفته ساخته معاف نیست — به خصوص که بابک هرگز از «اعتبارسنجی صادرکننده» نشنیده است.

سه مکانیزم شکست در امنیت MCP که در عمل دیده می‌شوند

۱. توصیفِ ابزارها دستور می‌شوند، نه مستند

در مه ۲۰۲۵، پژوهشگران Invariant Labs نشان دادند سرور MCP گیت‌هاب می‌تواند از طریق یک Issue عمومی «مسموم» دزدیده شود: متن مهاجم در بدنه Issue توسط عامل (Agent) به عنوان دستور خوانده شد و توکن قربانی برای استخراج داده از مخازن خصوصی استفاده شد. کد مخرب، ابزار مخرب نبود؛ تنها یک فیلد توصیف بود که هیچ‌کس فکر پاک‌سازی‌اش را نکرده بود.

بنچمارک ۲۰۲۶ به نام MCPTox این الگو را بر ۴۵ سرور MCP زنده و ۲۰ مدل تست کرد: نرخ موفقیت حمله ۳۶.۵ درصد در میانگین و ۷۲.۸ درصد در برابر بدترین مدل. ابزار بابک شکل پایه مشابهی دارد: پیام‌های اسلیک و متن تیکت‌ها را می‌خواند تا اولویت‌بندی کند. نمی‌تواند تفاوت درخواست همکار و رشته‌ای طراحی‌شده برای تزریق دستور را تشخیص دهد، چون هیچ‌کس از آن نخواسته این تفکیک را انجام دهد.

۲. محدوده‌ها (Scopes) به‌صورت پیش‌فرض «همه‌چیز» هستند

شکست رایج نبودن مدل اجازه است؛ نادیده گرفتنِ آن است. سروری که تنها نیاز به دسترسی خواندنی تقویم دارد، برای خواندن، نوشتن و مدیریت در کل حوزه درخواست می‌دهد چون آموزش‌های مقدماتی همین‌طور کرده‌اند. در اکوسیستم MCP، ۸۸ درصد سرورها برای عملکرد به اعتبارنامه نیاز دارند، اما تنها ۸.۵ درصد واقعاً از OAuth 2.0 استفاده می‌کنند.

بیشتر موارد در حال اجرا اصلا محدود (Scoped) نشده‌اند، پس محدوده‌ای برای Scope Creep (расширение допусков) باقی نمانده. بابک نشست و محدوده‌ای انتخاب نکرد. از کلید API سطح مدیریت که دو سال پیش برای یک داشبورد گزارش‌گیری در مدیریت رمز عبورش ذخیره کرده بود، مجدد استفاده کرد — چون درخواست کلید محدود‌تر به معنای ثبت تیکت بود، و ثبت تیکت کلِ آن بیوروکراسی بود که سعی داشت دور بزند.

۳. توکن‌های استاتیک گردش (Rotate) نمی‌کنند، و никто نظارت نمی‌کند

اپلیکیشن سرور MCP شرکت Splunk تا نسخه ۱.۰.۳ (پچ‌شده در CVE-2026-20205) نشست و توکن‌های احراز هویت را در متن ساده (Cleartext) لاگ می‌کرد. آن بندر یک تیم امنیتی تخصصی دارد.

بر اساس تخمین‌ها، بیش از نیمی از سرورهای MCP در محیط‌های واقعی روی کلیدهای API استاتیک یا توکن‌های دسترسی شخصی (PAT) اجرا می‌شوند که به ندرت گردش می‌کنند. نزدیک به نیمی از فعالیت‌های هوش مصنوعی سازمانی از طریق حساب‌های شخصی به جای حساب‌های سرویس (Service Accounts) عبور می‌کند — یعنی اعتبارنامه‌ی که کار می‌کند متعلق به هویتِ کسی است، نه سیستم.

توکن بابک همان کلید داشبورد قدیمی است. از روز صدور معتبر بوده؛ تا زمانی که کسی یادتان برسد بکشید معتبر می‌ماند، و تنها سابقه‌ی اینکه این ماه به چه چیزی دسترسی داشته در حافظه بابک زندگی می‌کند — که یک لاگ نیست.

نمودار درصد سرورهای MCP با توکن استاتیک و فاقد چرخش اعتبارنامه
منبع: تجزیه‌وتحلیل‌های میدانی اکوسیستم MCP، ۲۰۲۶

چه چیزی در میدانه دیده شده است

در طول چند ماه گذشته، در حین راه‌اندازی یکپارچه‌سازی‌های MCP در محیط‌های مشتری و کاندیداها، مشاهده شد که بیش از ۲۰ درصد از سیاست‌های دسترسی مرتبط با MCP یا خراب بودند یا کاملاً گم‌شده.

  • در اکثر موارد، سرور MCP با توکن شخصیِ فردی احراز هویت شده بود، نه حساب سرویس.
  • هیچ‌کدام از آن توکن‌ها برنامه‌ریزی موثقی برای چرخش (Rotation) نداشتند.
  • هیچ‌کدام از سرورها لاگی از آنچه به آن‌ها دسترسی داده شده بود نگه نداشتند.

اگر ابزار بابک در آن دسته قرار گرفته باشد — و از نظر آماری احتمالاً رفته است — کسی تا زمانی که مشکلی پیش بیاید متوجه نمی‌شود، چون الان هیچ مکانیزمی برای بررسیِ «آیا اشتباه رفته است» وجود ندارد.

حکومت (Governance) هزینه دارد، اما بی‌حکومتی هزینه‌تر است

هیچ‌کدام از این‌ها به این معنی نیست که هر یکپارچه‌سازی Vibe-coded (ساخته‌شده بر اساس حس و حال، بدون فرآیند رسمی) نیاز به یک کمیته مشورتی تغییر دارد. بیشتر چیزهایی که بابک می‌سازد بی‌ضرر هستند، و گذاشتن هر پروژه آخر هفته پشت یک فرآیند بازبینی رسمی دقیقاً راهی است که شما را به چرخه تأمین ۱۸ ماهه‌ای برمی‌گرداند که 아무도 از دستش رنج نکشید. حاکمیت هزینه خود را دارد، که در ایده‌های خوب پرداختی می‌شود که هرگز مستقر نمی‌شوند چون فرآیند مومنتوم (Momentum) آخرهفته‌ای که آن‌ها را ممکن می‌ساخت را می‌خورد.

مشکل وجود این ابزارها نیست. مشکل این است که اکثر سازمان‌ها در حال حاضر نمی‌توانند تفاوت بین ابزارهای بی‌ضرر و آن‌هایی که توکنی دارند به تولید (Production) می‌رسد را تشخیص دهند، و سعی می‌کنند با یک سیاست کلی «ممنوعیت» یا «بی‌اختیاری» مقابله کنند — هر دو نتایج بدی دارند.

راه‌حل واقعی دیدِ متمرکز بر هویت (Identity-Centric Visibility) است: دانستن اینکه کدام توکن، متعلق به چه کسی، به چه چیز دسترسی دارد، و آخرین بار کی چرخش کرده. تا وقتی این دید وجود نداشته باشد، هر «بابک» جدید یک تهدید پنهان در انتظار است.