پیش از نصب ابزار: دروازه زنجیره تأمین برای عامل‌های هوش مصنوعی

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

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

قاعده مرکزی ساده است: کشف ابزار به معنای اعتماد نیست و نام بسته واحد پذیرش محسوب نمی‌شود. یک مصنوع تغییرناپذیر را همراه با پوشش قابلیتِ قابل‌اجرا، پرونده شاهد، مالک و سیاست به‌روزرسانی بپذیرید. با تغییر هرکدام، اعتبار تصمیم پذیرش پایان می‌یابد.

نصب، دو سامانه ریسک را به هم پیوند می‌دهد

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

به همین دلیل، پرسش پذیرش دو محور مستقل دارد:

1. اعتماد به مصنوع: آیا این همان مصنوع مورد انتظار از منبع و فرایند ساخت مورد انتظار است و هیچ جایگزینی بی‌توضیح رخ نداده؟
2. اختیار زمان اجرا: حتی اگر مصنوع اصیل باشد، به کدام فایل، فرایند، شبکه، اعتبارنامه، داده و اقدام کسب‌وکار دسترسی دارد؟

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

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

منابع چه چیزی را ثابت می‌کنند و قضاوت از کجا آغاز می‌شود

چند استاندارد، اجزای مفیدی برای پاسخ فراهم می‌کنند، اما هیچ‌کدام ابزار عامل را «ایمن» گواهی نمی‌کنند.

نسخه نهایی ژوئیه ۲۰۲۶ راهنمای راستی‌آزمایی تأمین‌کننده NIST SP 1326، ارزیابی تأمین‌کننده را با منشأ، تاب‌آوری، رویه‌های پایه امنیت سایبری، لایه‌های زنجیره تأمین و مالکیت یا نفوذ بررسی می‌کند. راهنمای گسترده‌تر NIST SP 800-161 Rev. 1 ریسک زنجیره تأمین را در خرید، استقرار، نگهداری و کنارگذاری می‌بیند، نه فقط در لحظه خرید. NIST SP 800-218 نیز واژگان مشترکی برای رویه‌های توسعه امن در اختیار تولیدکننده و خریدار می‌گذارد. این‌ها کنترل‌های عمومی نرم‌افزار و تأمین‌کننده‌اند؛ شِمای یک ابزار MCP را بازرسی نمی‌کنند و درباره خروجی شبکه مجاز عامل تصمیم نمی‌گیرند.

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

شیء مورد پذیرش را دقیق تعریف کنید

«ابزار تقویم»، «نسخه چهار» یا برچسب شناور کانتینر را تأیید نکنید. شیئی ثبت کنید که بتوان آن را بی‌ابهام بازسازی کرد:

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

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

این شیء پذیرش، گذرنامه انتشار هوش مصنوعی را کامل می‌کند. گذرنامه، مونتاژ کامل سامانه تولیدی را نام‌گذاری می‌کند؛ پرونده ابزار، شاهد و محدودیت یکی از پرقدرت‌ترین اجزای آن را می‌دهد.

منشأ را با انتظارهای ازپیش‌نوشته‌شده بسنجید

منشأ فقط زمانی مفید است که در برابر سیاست مشخص راستی‌آزمایی شود. راهنمای تصویب‌شده راستی‌آزمایی مصنوع در SLSA 1.2 بررسی امضای گواهی، تطبیق موضوع بیانیه با چکیده مصنوع، شناسایی نوع گزاره، ارزیابی هویت سازنده و مقایسه مخزن اصلی و پارامترهای بیرونی ساخت با انتظارها را توصیه می‌کند. همان راهنما محدودیت‌های مهمی نیز دارد: حتی سطح سه ساخت، قابل‌اعتمادبودن سکوی ساخت منتخب را فرض می‌کند و شاهد وابستگی‌های بازگشتی ممکن است کامل نباشد.

گواهی مصنوع GitHub می‌تواند مصنوع را به گردش‌کار، مخزن، ثبت تغییر و رویداد ساخت متصل کند. خود GitHub صریحاً هشدار می‌دهد که گواهی، ایمن‌بودن مصنوع را تضمین نمی‌کند. راهنمای راستی‌آزمایی Sigstore نشان می‌دهد باید چکیده مصنوع و هویت و صادرکننده مورد انتظار گواهی بررسی شوند؛ صرف وجود امضا کافی نیست. منشأ بسته در npm نیز بسته را به کد منبع و دستور ساخت پیوند می‌دهد، اما نبود کد مخرب را ثابت نمی‌کند.

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

• امضایی را که هویت، صادرکننده، موضوع مصنوع یا مخزن اصلی آن مطابق انتظار نیست رد کنید.
• مصنوع راستی‌آزمایی‌ناپذیر را «ناشناخته» بدانید، نه «احتمالاً رسمی».
• نشان منشأ را جایگزین بررسی کد، وابستگی یا رفتار نکنید.
• دقیقاً ثبت کنید کدام ویژگی‌ها راستی‌آزمایی شده‌اند؛ همه را در یک علامت سبز ادغام نکنید.
• هنگام بارگیری یا استقرار دوباره راستی‌آزمایی کنید تا دست‌کاری رجیستری یا مسیر انتقال بیرون از کنترل نماند.

پوشش قابلیت را قابل‌اجرا بسازید

شرح ابزار ورودی بررسی است، نه مرز اجرایی. کوچک‌ترین محیطی را تعریف کنید که کاربرد مورد نظر هنوز در آن کار می‌کند:

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

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

پیش از اعتماد، قرنطینه کنید

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

هم مسیر عادی و هم حالت‌های خصمانه را بیازمایید:

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

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

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

مثال عملی: سرور دسته‌بندی تیکت‌ها

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

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

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

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

این جداسازی همان منطق واسطه‌گری اعتبارنامه کوتاه‌عمر را دنبال می‌کند: ابزار پس از ارزیابی سیاست فقط اختیار لازم برای همین وظیفه را می‌گیرد و راز دائمی را به ارث نمی‌برد.

تصمیم صریح بگیرید: رد، قرنطینه یا پذیرش

به‌جای امتیاز مبهم، نتیجه روشن داشته باشید:

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

راستی‌آزمایی تأمین‌کننده همچنان مهم است. پرونده خرید تأمین‌کننده هوش مصنوعی مالکیت، حاکمیت، پاسخ امنیتی، تداوم کسب‌وکار و شیوه داده را پوشش می‌دهد. این شاهد را از راستی‌آزمایی مصنوع و مشاهده اجرا جدا نگه دارید.

هر به‌روزرسانی یک پذیرش تازه است

نسخه شناور، یک بررسی را به مجوز نامحدود برای کد آینده تبدیل می‌کند. مصنوع را با چکیده ثابت کنید و اجازه دهید خدمت به‌روزرسانی ــ نه عامل تولیدی ــ انتشار تازه را کشف کند. برای هر نامزد مقایسه کنید:

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

تغییرها را طبقه‌بندی کنید. انتشار صرفاً مستنداتی شاید فقط تازه‌سازی شاهد بخواهد. تغییر وابستگی، نقطه ورود، شِمای ابزار، دامنه مجوز، شبکه یا اعتبارنامه باید به قرنطینه بازگردد. تغییر بی‌توضیح منشأ باید بسته بماند.

نسخه سالم قبلی را نگه دارید، اما بازگشت را معادل ایمنی ندانید؛ آلودگی امضاکننده، سکوی ساخت یا وابستگی مشترک ممکن است چند نسخه را درگیر کند. توقف قابلیت و لغو هویت باید مستقل از استقرار باشد.

بسنجید که دروازه واقعاً کار می‌کند

معیار مفید، اختیار کنترل‌نشده را آشکار می‌کند؛ نه اینکه تعداد بررسی‌ها را جشن بگیرد:

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

دروازه پذیرش ابزار عامل

پیش از فعال‌کردن ابزار بیرون قرنطینه، پاسخ مثبت بخواهید:

• آیا مصنوع اجرایی دقیق با چکیده شناسایی شده و از کانال کنترل‌شده نگهداری می‌شود؟
• آیا ناشر، امضاکننده، صادرکننده، مخزن، سازنده و پارامتر ساخت با انتظار مکتوب مطابق‌اند؟
• آیا وابستگی، رفتار نصب، کد بومی و آسیب‌پذیری شناخته‌شده به عمق متناسب با پیامد بررسی شده‌اند؟
• آیا کوچک‌ترین پوشش مفید فایل، فرایند، شبکه، هویت، داده، اقدام و خروجی ثبت و بیرون ابزار اجرا می‌شود؟
• آیا همین مصنوع آزمون عادی، خصمانه، شکست و به‌روزرسانی را بدون دسترسی بی‌توضیح گذرانده است؟
• آیا اعتبارنامه کوتاه‌عمر، محدود به مخاطب، بیرون زمینه مدل و مستقل قابل‌لغو است؟
• آیا هر تغییر مهم در مصنوع، وابستگی، شِما، دامنه مجوز، مقصد یا تأمین‌کننده پذیرش دوباره را فعال می‌کند؟
• آیا مالک می‌تواند ابزار را متوقف کند، اجرای متاثر را بیابد، شاهد را حفظ و وضعیت کسب‌وکار را بازیابی کند؟
• آیا نتیجه یکی از رد، قرنطینه یا پذیرش محدود است و انقضا و مالک استثنا دارد؟

هدف، اثبات نبود هر نقص یا مسیر مخرب در ابزار نیست؛ چنین ادعایی برای نرم‌افزار پیچیده در دسترس نیست. هدف، گزاره‌ای کوچک‌تر و دفاع‌پذیر است: سازمان می‌داند کدام مصنوع را اجرا می‌کند، درباره منشأ آن شاهد دارد، رفتار آن را دیده و اختیار اعلام‌نشده را از نظر فنی ناممکن کرده است. شاهد و مرز را با هم نصب کنید؛ وگرنه ابزار را نصب نکنید.

یادداشت منابع — بازبینی ۲۱ اوت ۲۰۲۶

• NIST SP 1326: Cybersecurity Supply Chain Risk Management Due Diligence Assessment Quick-Start Guide — راهنمای نهایی ژوئیه ۲۰۲۶ برای اجزای ارزیابی تأمین‌کننده و محصول.
• NIST SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management Practices — راهنمای چرخه‌عمر مدیریت ریسک زنجیره تأمین برای خرید، استقرار، نگهداری و کنارگذاری محصول و خدمت.
• NIST SP 800-218: Secure Software Development Framework 1.1 — واژگان رویه توسعه امن برای تولیدکننده، خریدار و مصرف‌کننده.
• SLSA 1.2: Verifying artifacts — راهنمای تصویب‌شده برای امضا، موضوع مصنوع، هویت سازنده، انتظار منبع، پارامتر و وابستگی.
• MCP Security Best Practices, protocol version 2026-07-28 — خطر و کنترل رسمی برای اجرای محلی، رضایت، محیط ایزوله، درخواست سمت‌سرور، توکن و کمینه‌سازی دامنه مجوز.
• GitHub: Artifact attestations — ویژگی منشأ ساخت و محدودیت صریح اینکه گواهی، کد امن را تضمین نمی‌کند.
• Sigstore: Verifying signatures — راهنمای راستی‌آزمایی چکیده مصنوع، هویت گواهی، صادرکننده، امضا و گواهی ساخت.
• npm: Generating provenance statements — سازوکار منشأ رجیستری و محدودیت مستند آن.