۱۶۴۳ ایمیل ارسالی توسط هوش مصنوعی، تنها با تغییر یک خط کد در یک ابزار جانبی به دست مهاجمان افتاد. اگر امروز از ابزارهای متن‌باز برای اتصال عامل‌های خود به دنیای بیرون استفاده می‌کنید، باید بدانید که تأیید امنیتی یک ابزار در لحظه نصب، تضمینی برای امنیت آن در آینده نیست.
این رخنه‌ی امنیتی در سپتامبر ۲۰۲۵ توسط تیم امنیتی Koi کشف شد. ابزار postmark-mcp که یک بسته npm و در واقع یک سرور پروتکل زمینهٔ مدل (MCP) — شبیه به یک مترجم که اجازه می‌دهد دستیاران هوش مصنوعی با خدمات خارجی مثل Postmark صحبت کنند — است، به ابزاری برای سرقت داده‌ها تبدیل شده بود. طبق گزارش Koi، این حمله ثابت می‌کند که اعتماد به ابزارهای هوش مصنوعی یک رویداد یک‌باره نیست، بلکه یک آسیب‌پذیری مستمر است. این حادثه یادآور مخاطرات نشت اطلاعات حساس است، مشابه آنچه در مورد نشت داده‌های نظارتی متا و ثبت گفتگوهای خصوصی کارکنان مشاهده شد.
در حالی که پروتکل زمینهٔ مدل (MCP) در حال تبدیل شدن به استاندارد اتصال عامل‌های هوش مصنوعی به داده‌ها و ابزارهای خارجی است، اکثر توسعه‌دهندگان نصب یک ابزار را به معنای تأیید همیشگی و دائمی آن می‌دانند. آن‌ها یک بار ساختار (Schema) را بررسی می‌کنند، مجوزها را می‌پذیرند و فرض می‌کنند ابزار در تمام طول چرخه حیاتش ایمن می‌ماند. اما حادثه postmark-mcp فاش می‌کند که این «اعتماد نقطه‌ای» دقیقاً همان چیزی است که مهاجمان از آن بهره‌برداری می‌کنند. اعتماد در واقع یک عمل در لحظه است؛ شما ساختاری را بازبینی می‌کنید، قضاوتی می‌سازید و سپس روی آن قضاوت بنا می‌کنید، گویی که ابدی است. اما این اثر (Artifact) دائمی نیست؛ بلکه موجودی زنده است که شخصی دیگر آن را کنترل می‌کند و می‌تواند بدون هیچ تعهدی به اطلاع‌رسانی به شما، آن را تغییر دهد.
کالبدشکافی حمله
این حمله با مهندسی اجتماعی پیچیده‌ای در فرآیند به‌روزرسانی اجرا شد. یک مهندس ابتدا یک کپی دقیق از سرور قانونی و متن‌باز Postmark ساخت، آن را تقریباً خط به خط کپی کرد و با نام خود منتشر نمود. برای ایجاد حس امنیت کاذب، مهاجم ۱۵ نسخه متوالی و کاملاً «پاک» منتشر کرد که دقیقاً طبق وعده‌ها و تبلیغات عمل می‌کردند. این ۱۵ نسخه صادقانه، نشانه ایمنی نبودند؛ بلکه خودِ حمله بودند. هدف این نسخه‌ها جلب اعتمادی بود که مهاجم در نهایت در نسخه شانزدهم آن را خرج کند.
وقتی پایگاه کاربران ابزار را نصب کرده و آن را در عامل (Agent) — همان دستیاران هوش مصنوعی که می‌توانند به‌صورت مستقل هدف را دنبال کنند — ادغام کردند، مهاجم نسخه ۱.۰.۱۶ را عرضه کرد. این نسخه دقیقاً مشابه نسخه قبلی بود، به جز یک تغییر در خط ۲۳۱. این تغییر ساده، یک کپی مخفی (BCC) به آدرس phan@giftshop[.]club اضافه می‌کرد تا هر ایمیل ارسالی توسط هوش مصنوعی، هم‌زمان برای مهاجم هم ارسال شود. اکسپلویت (Exploit) کاملاً در شکاف میان این دو باور زندگی می‌کرد: «من یک بار این را ارزیابی کردم» و «این ابزار هنوز همان چیزی است که ارزیابی کردم».
طبق مستندات امنیتی Koi، پیامدهای این اقدام سریع و شدید بود:
- ابزار به‌طور مخفیانه داده‌های بسیار حساس، از جمله لینک‌های بازنشانی رمز عبور، فاکتورها، اعتبارنامه‌ها (Credentials) و قراردادهای حقوقی را برای یک فرد غریبه ارسال می‌کرد.
- این بسته مخرب پیش از آنکه جامعه امنیتی متوجه این انحراف (Drift) شود، ۱۶۴۳ بار دانلود شد.
- قربانیان روزها متوجه حادثه نشدند، زیرا متادیتای ظاهری و لیست ابزارهای نمایش داده شده در ابزار تغییری نکرده بود.
حل مسئله «زوال اعتماد»
پژوهشگران امنیتی استدلال می‌کنند که برای جلوگیری از این اتفاق، اعتماد باید به عنوان مقداری دیده شود که به محض امکان تغییر قرارداد (Contract)، دچار زوال می‌شود. اگر اعتماد در لحظه امکان تغییر قرارداد کاهش یابد، تنها رویکرد صادقانه این است که با قرارداد به عنوان چیزی برخورد کنید که باید به‌طور مستمر بازبینی شود، نه چیزی که یک بار تأیید شده و سپس فراموش می‌گردد. این کار مستلزم تبدیل «حس» (Vibe) اعتماد به یک توصیف ساختاری و عینی است.
توسعه‌دهندگان نمی‌توانند یک «حس» را با ابزارهای مقایسه‌ای (Diff) بررسی کنند. در عوض، آن‌ها باید توصیفات ساختاری و عینی ابزار را مقایسه کنند. این موارد شامل موارد زیر است:
- فیلدهای خاص در یک Payload و انواع داده‌های مرتبط با آن‌ها.
- لیست ابزارهایی که سرور MCP به عامل معرفی می‌کند.
همچنین باید موارد زیر بررسی شوند:
- پارامترهای دقیقی که هر ابزار می‌پذیرد.
- متن توصیفی که مدل می‌خواند تا بر اساس آن تصمیم بگیرد چگونه از ابزار استفاده کند.
با تبدیل این وعده‌ها به آثار صریح — اسنپ‌شات‌هایی که می‌توانند ذخیره، نسخه‌بندی و در کنار یکدیگر قرار گیرند — توسعه‌دهندگان می‌توانند یک سطح API متغیر را به چیزی پایدار تبدیل کنند. زمانی که شکل ابزارِ امروز با اسنپ‌شات تأیید شده‌ی دیروز متفاوت باشد، سؤال «آیا مورد حمله قرار گرفته‌ام؟» به یک مقایسه مکانیکی تبدیل می‌شود. در مورد postmark-mcp، اگرچه نسخه‌های ۱.۰.۱۵ و ۱.۰.۱۶ ابزارهای یکسانی را توصیف می‌کردند، اما رفتار آن‌ها واگرا شده بود و متادیتای آن‌ها، از جمله هش‌ها (Hashes) و نسخه‌ها، تغییر کرده بود.
تفکیک تغییر از حمله
با این حال، مقایسه ساده (Diffing) کافی نیست زیرا قراردادها باید تغییر کنند. APIها فیلدهای جدیدی اضافه می‌کنند و ابزارها توصیفات خود را بهبود می‌بخشند. اگر هر تفاوت جزئی باعث به صدا درآمدن زنگ خطر شود، توسعه‌دهندگان دچار «خستگی از هشدار» شده و در نهایت هشدارها را نادیده می‌گیرند. بنابراین، یک مقایسه مفید باید بتواند تغییری که یک وعده را می‌شکند از تغییری که صرفاً آن را گسترش می‌دهد، تشخیص دهد.
تمایزات حیاتی عبارتند از:
- افزایشی در مقابل تخریبی: افزودن یک فیلد اختیاری (Optional) اغلب بی‌خطر است، در حالی که حذف یک فیلد ضروری، یک تغییر شکست‌دهنده (Breaking Change) محسوب می‌شود.
- جهش توصیفات: تغییر در توصیف ابزار به گونه‌ای که بتواند عامل را به سمت یک اقدام جدید و ناخواسته سوق دهد، یک رویداد با ریسک بالا است.
- رشد پارامترها: اضافه شدن یک پارامتر جدید به یک ابزار موجود، پروفایل ریسک متفاوتی نسبت به ظهور یک ابزار کاملاً جدید دارد.
این طبقه‌بندی تضمین می‌کند که توجه انسان تنها زمانی صرف شود که یک وعده واقعاً شکسته شده است، و بدین ترتیب مقایسه خام را به یک فرآیند مهندسی پایدار تبدیل می‌کند.
استراتژی‌های پیاده‌سازی
برای اثربخشی این بررسی‌ها، دو نقطه حیاتی وجود دارد که این چک‌ها باید در آن‌ها رخ دهند:
۱. درگاه‌های پیش از ادغام (Pre-merge Gates): این‌ها «صیدهای ارزان» هستند. این بررسی در مرز تغییرات شما و پیش از ادغام کد اتفاق می‌افتد. وقتی یک یکپارچه‌سازی (Integration) شکل خاصی از پاسخ را فرض می‌کند، لحظه کشف اشتباه بودن این فرض، در Pull Request است. این کار باعث شکست بیلد (Build) می‌شود پیش از آنکه فرض غلط هرگز به دست کاربر برسد. این مکانیسم جلوی انحرافی را می‌گیرد که خود شما ایجاد می‌کنید.
۲. پایش مستمر (Continuous Polling): این مورد برای انحرافاتی است که شما کنترل ندارید. در حمله postmark-mcp، هیچ‌کس در سمت قربانی کد خود را تغییر نداد؛ انحراف از یک برنامه انتشار خارجی مدت‌ها پس از آخرین ادغام کد (Merge) آمد. هیچ درگاه پیش از ادغامی نمی‌توانست این مورد را شکار کند. این وضعیت نیازمند سیستمی است که به‌طور مداوم سطح زنده (Live Surface) را پایش کند، کاتالوگ ابزارها را مجدداً دریافت کند و شکل‌های معرفی شده را طبق برنامه زمانی خود، برای همیشه بازخوانی کند.
برای عملیاتی کردن این روند، Koi ابزاری به نام DriftGuard را توسعه داد؛ ابزاری که برای طبقه‌بندی تغییرات شکست‌دهنده در خط لوله‌های CI و نگهداری تاریخچه شکل‌های قرارداد در طول زمان طراحی شده است. تشخیص تنها نیمی از راه‌حل است؛ نیم دیگر، تحویل و تاریخچه است. یک بررسی بی‌فایده است اگر نتیجه آن در لاگی قرار بگیرد که هیچ‌کس نمی‌خواند. ارزش زمانی محقق می‌شود که یک انسان با یک «رسید» (Receipt) مشخص و خوانا متوقف شود که وضعیت «قبل» و «بعد» از تغییر را نشان می‌دهد.
این رویکرد، یک رکورد بادوام و یک خط زمانی از شکل قرارداد در طول هفته‌ها ایجاد می‌کند. این به تیم‌ها اجازه می‌دهد به سؤالی پاسخ دهند که قربانیان postmark-mcp تا روزها قادر به پاسخ دادن به آن نبودند: «این تغییر از چه زمانی رخ داد و در فاصله بین آن تا امروز، در معرض چه خطراتی بودیم؟»
این حادثه پیش‌فرض صنعت را از «آیا این ابزار ایمن است؟» به «آیا این ابزار هنوز همان چیزی است که من تأیید کردم؟» تغییر می‌دهد. در دنیای عامل‌محور (Agentic World)، تهدید دیگر یک نفوذ یک‌باره نیست، بلکه انحراف بیرونی مستمر است. بستن شکاف بین تأیید اولیه و وضعیت لحظه‌ای، اکنون یک الزام ضروری برای امنیت هوش مصنوعی است. برای کسانی که عامل‌های هوش مصنوعی می‌سازند، اولویت بعدی بازرسی هر سرور MCP شخص ثالث و ایجاد یک حلقه پایش مستمر برای تعریف ابزارهاست.
گام بعدی شما
- تمام سرورهای MCP شخص ثالث که در محیط‌های تست یا تولید استفاده می‌کنید را بازبینی کنید.
- برای هر وابستگی AI، یک اسنپ‌شات از توصیفات ابزارها (Tool Definitions) تهیه کنید تا مبنایی برای مقایسه داشته باشید.
- اگر از CI/CD استفاده می‌کنید، مکانیزم‌های پایش تغییرات APIهای خارجی را در خط لوله خود بگنجانید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو