تصور کنید ابزاری که برای افزایش بهره‌وری نصب می‌کنید، در پس‌زمینه در حال جمع‌آوری رمزهای عبور شما باشد. طبق گزارش Snyk در فوریه ۲۰۲۶، یک ممیزی امنیتی فاش کرد که ۳۶.۸۲٪ از ۳۹۸۴ مهارت (Skill) عمومی برای عامل‌های هوش مصنوعی (AI Agents) حداقل یک نقص امنیتی جدی دارند.
این داده‌ها نشان می‌دهند که ۱۳.۴٪ از این ابزارها دارای مشکلات بحرانی هستند و ۷۶ مورد از آن‌ها به‌طور قطعی توسط انسان به عنوان بدافزار تأیید شده‌اند. این وضعیت گسست خطرناکی را در نحوه ارزیابی ابزارهای هوش مصنوعی در مقایسه با کتابخانه‌های نرم‌افزاری سنتی نشان می‌دهد.
رفلکس وابستگی
بسیاری از مهندسان پیش از اجرای دستور npm install، تعداد دانلودهای هفتگی، تاریخ آخرین تغییرات (commit) و اینکه آیا نگهدارنده پروژه یک انسان واقعی است یا یک حساب رهای شده را بررسی می‌کنند. اما وقتی نوبت به نصب بسته‌های پرامپت یا پلاگین‌های هوش مصنوعی می‌رسد، اغلب با یک کلیک ساده آن‌ها را فعال می‌کنند. این رفلکس یا واکنش سریع، که پس از تجربه‌های تلخ از وابستگی‌های نرم‌افزاری شکل گرفته بود، هنوز به حوزه مهارت‌های عامل‌های هوش مصنوعی منتقل نشده است.
این فقدان دقت، یک سطح حمله (Attack Surface) عظیم ایجاد می‌کند. مهارت‌های عامل‌های هوش مصنوعی اغلب با دسترسی‌های محیطی بسیار بیشتری نسبت به یک کتابخانه ساده برای فرمت تاریخ اجرا می‌شوند. به گزارش Datadog Security Labs در می ۲۰۲۶، یک مهارت فعال در محیط واقعی شناسایی شد که در حالی که خود را ابزاری برای آپلود گزارش‌های استفاده معرفی می‌کرد، در واقع در حال سرقت اعتبارنامه‌های (Credentials) توسعه‌دهندگان بود.
شکست‌های سیستماتیک در نظارت
بر اساس بررسی‌های آکادمیک انجام شده در بازه ۲۰۲۵ تا ۲۰۲۶، سیستم‌های نظارت بر محتوا در این پلتفرم‌ها دچار شکست ساختاری شده‌اند. اکثر مخازن عمومی ابزارهای عامل‌محور، تنها به نظارت واکنشی (Reactive) و گزارش‌های جامعه کاربران تکیه می‌کنند. این پلتفرم‌ها در حال حاضر فاقد بررسی کد پیش از انتشار (Pre-publication code review) و سیستم‌های استاندارد تأیید هویت ناشر هستند و همین موضوع در را برای حملات هماهنگ باز می‌گذارد. در یک مورد خاص، یک کمپین موفق شد بیش از ۳۰ مهارت مخرب را به یک بازارچه عمومی واحد تزریق کند.
بازارهای فعلی به‌خوبی پاسخ می‌دهند که «این ابزار چه می‌کند؟» (از طریق رتبه‌بندی‌های محبوبیت و قابلیت جستجو)، اما در پاسخ به این سؤال که «چه کسی این را ساخته و من از کجا بدانم؟» ناتوان‌اند. در بازارهای باز، پاسخ معمولاً یک نام کاربری است و یک نام کاربری هرگز به معنای یک هویت تأییدشده نیست. این چالش در تایید منشأ ابزارها، یادآور بحران مالکیت کد و ضرورت اثبات منشأ است که شرکت‌ها را با فشارهای قانونی جدیدی مواجه کرده است.
برای کاهش این خطرات، توسعه‌دهندگان باید چهار بررسی کلیدی را پیش از نصب هر مهارت انجام دهند:
- هویت: به‌جای نام‌های مستعار و کلی، به‌دنبال سازمان یا فردی با نام واقعی بگردید. بررسی کنید آیا آن‌ها حضوری در فضای وب دارند که تاریخ آن به پیش از ثبت این ابزار بازگردد.
- خوانایی: دستورالعمل‌های متنی ساده و شفاف را که می‌توانید سریعاً مرور کنید، به کدهای مبهمی که نیاز به اعتماد کورکورانه دارند ترجیح دهید؛ به‌ویژه برای ابزارهایی که به فایل‌های شما دسترسی دارند.
- منشأ: تعیین کنید که آیا بازارچه از بررسی‌های پیش از انتشار استفاده می‌کند یا مدل «آپلود و امیدواری» (Upload-and-hope) را دنبال می‌کند. چه کسی تصمیم گرفته است که این ابزار متعلق به این مکان است؟
- تاریخچه تغییرات: بررسی کنید که نویسنده هنگام یافتن خطاهای قبلی چگونه واکنش نشان داده است؛ سکوت در برابر خطا یک زنگ خطر جدی است.
بیشترین ارزش در بررسی‌های اول و چهارم نهفته است. این دو مورد ارزان‌ترین بررسی‌ها هستند و دقیقاً همان نقاطی هستند که آپلودهای مخرب به‌طور قابل‌اطمینانی در آن‌ها شکست می‌خورند.
یک جایگزین ساختاری
به عنوان یک جایگزین برای بازارچه‌های باز، چارچوب CRAFT برای Claude Cowork مدل «قفسه منتخب» (Curated Shelf) را پیاده کرده است. CRAFT در دوره بتا رایگان و بدون محدودیت دسترسی است و روی Claude Cowork اجرا می‌شود (که نیازمند دسترسی به Cowork در پلن Claude شماست)، بنابراین هزینه یا حساب کاربری اضافه‌ای نمی‌طلبد.
این سیستم به‌جای توده‌ای از قطعات پراکنده و قابل جستجو، «کتاب‌های آشپزی» (Cookbooks) متوالی ارائه می‌دهد؛ مجموعه‌ای از دستورالعمل‌ها که حول یک هدف واحد ترتیب یافته‌اند تا هر مرحله خروجی را به مرحله بعد تحویل دهد. این رویکرد بیشتر شبیه به یک برنامه سفر (Itinerary) است تا یک نتیجه جستجو. در اینجا، وسعت فدای منشأ و اعتبار می‌شود تا اطمینان حاصل شود که اسمبل کردن ابزارها یک بار توسط شخصی پاسخگو انجام شده است، نه توسط کاربر در لحظه اجرا.
مکانیسم نظارت (Curation)
برای تضمین اینکه این نظارت صادقانه باقی بماند، CRAFT از یک لایه تأیید متشکل از دستورالعمل‌هایی استفاده می‌کند که به‌طور خاص برای بررسی کارها با گیت‌های حقیقت‌سنجی (Fact-check gates) و امتیازدهی اطمینان از ۰ تا ۱۰۰ طراحی شده‌اند.
در یک مورد، این بررسی خودکار ۹ فایل محتوای داخلی را شناسایی کرد که به‌اشتباه چارچوب را «متن‌باز» معرفی کرده بودند، در حالی که لایسنس چیز دیگری می‌گفت. این امر اجازه داد تا خطا پیش از ارسال فایل‌ها اصلاح شود؛ از نوع خطاهایی که یک بازبین انسانی احتمالاً در دهمین بار خواندن از آن چشم‌پوشی می‌کرد. این سطح از دقت در شناسایی حفره‌ها، مشابه عملکرد سیستم‌های تحلیل چند-مدلی مانند NexaVerify است که در شناسایی سریع نشت‌های امنیتی، متخصصان انسانی را به چالش کشیده‌اند. ارزش اصلی در اینجا این است که این بررسی فارغ از اینکه کسی به یاد داشته باشد دقت کند یا خیر، اجرا می‌شود.
این چرخش به سمت نظارت دقیق، بازتابی از نیاز گسترده‌تر به پاسخگویی در عصر عامل‌محور است. CRAFT در مرحله بتا است و نظارت در اینجا یک وعده درباره «مراقبت» است، نه «کمال». مطمئن‌ترین تضمین امنیتی، بازرسی شخصی منشأ هر ابزاری است که نصب می‌کنید، حتی ابزارهای ارائه شده توسط CRAFT.
گام بعدی شما
- تمام پلاگین‌ها و مهارت‌های نصب‌شده روی عامل‌های خود را بازبینی کرده و دسترسی‌های غیرضروری را حذف کنید.
- هنگام انتخاب ابزار، اولویت را به ناشرانی بدهید که سوابق GitHub یا وب‌سایت رسمی تأییدشده دارند.
- از ابزارهای مانیتورینگ برای رصد درخواست‌های خروجی (Outbound requests) عامل‌های خود استفاده کنید تا سرقت داده‌ها شناسایی شود.
اما داستان سخت‌افزاری این تحول و نحوه اجرای امن‌تر این مدل‌ها در لایه تراشه حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو