یک‌سوم دستورات خطرناک عامل‌های کدنویس با تایید برنامه‌نویسان اجرا می‌شوند

تصور کنید یک عامل هوش مصنوعی در حال مدیریت کد شماست و ناگهان دستوری برای حذف کل پایگاه داده ارسال می‌کند؛ آیا واقعاً متوجه آن می‌شوید یا از شدت تکرار، دکمه تایید را می‌زنید؟ طبق داده‌های منتشر شده در ۹ اوت ۲۰۲۶ توسط Scale X، حدود ۳۳.۷٪ از دستورات خطرناک پیشنهادی توسط عامل‌های (Agents) کدنویس، توسط برنامه‌نویسان تایید می‌شوند.

این رقم نشان می‌دهد که نظارت انسانی، که اصلی‌ترین مکانیسم ایمنی برای ابزارهای کدنویسی خودکار است، در عمل شکست خورده است. اکثر ابزارهای مدرن مانند Claude Code، GitHub Copilot Workspace و Devin بر پایه مدل اجازه-محور (Permission-based) عمل می‌کنند. فرض بر این است که بازبین انسانی مانند یک دیوار آتش نهایی عمل کرده و درخواست‌های مخرب را پیش از اجرا در ماشین محلی متوقف می‌کند. اما واقعیت جریان‌های کاری توسعه‌دهندگان، شکاف شناختی ایجاد می‌کند که مهاجمان می‌توانند از آن بهره‌برداری کنند. این چالش‌ها در تحلیل‌های ما درباره علت شکست سیستم‌های نظارت انسانی در مقیاس وسیع نیز مورد بررسی قرار گرفته بود.

همان‌طور که در تحلیل‌های پیشین ما درباره امنیت ابزارهای کدنویسی هوش مصنوعی اشاره کردیم، این داده‌های جدید یک آسیب‌پذیری سیستماتیک را برجسته می‌کند. خطر تنها در قالب «جیل‌بریک‌های» (Jailbreaks) نمایان نیست، بلکه در چیزی است که برخی متخصصان آن را «انحراف خاموش» (Silent Drift) می‌نامند؛ وضعیتی که در آن یک عامل، ویرایش‌ها یا حذف‌های غیرمجازی را انجام می‌دهد که تا مدت‌ها پس از اتمام تسک، نادیده گرفته می‌شوند.

مجموعه داده LLM Game

برای کمی کردن این ریسک، الکس واترز (Alex Wauters)، توسعه‌دهنده بلژیکی و مهندس سابق Uber، شبیه‌ساز LLM Game (llmgame.scalex.dev) را طراحی کرد. این محیط مبتنی بر مرورگر، درخواست‌های اجازه واقعی را که یک عامل هوش مصنوعی ممکن است در جریان یک گردش کار استاندارد توسعه نرم‌افزار درخواست کند، به صورت سناریوهای واقع‌گرایانه به بازیکنان نمایش می‌دهد.

بر اساس مستندات این پروژه، در ۴۰,۰۰۰ اجرا و ۴۰۹,۰۰۰ تصمیم فردی، میانگین صحت تشخیص ۶۶.۳٪ بود. این یعنی ۳۳.۷٪ از دستورات مخرب توسط بازبین‌های انسانی تایید شدند. این نرخ خطا تصادفی یا نتیجه عملکرد بازیکنان ضعیف نیست؛ بلکه دقیقاً بازتاب‌دهنده نحوه تعامل برنامه‌نویسان با اعلان‌های اجازه در ابزارهای تولیدی امروز است. این یافته‌ها با گزارش Scale X درباره خطای تشخیص تهدیدات توسط انسان همسو است که بر تضاد میان دقت ماشین و خستگی انسان تاکید داشت.

دسته‌بندی تهدیدات و نرخ خطا

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

• تخریب آشکار (Obvious Destruction): شناسایی راحت‌ترین مورد با نرخ خطای ۱۱.۷٪ بود؛ با این حال، از هر ۸ نفر، یک نفر همچنان دستوراتی را تایید کرد که کل کدبیس آن‌ها را پاک می‌کرد.
• نقض محدوده (Scope Violations): این درخواست‌ها که سعی می‌کنند به مناطقی خارج از مرزهای تعیین‌شده برای عامل دسترسی پیدا کنند، در ۳۵.۰٪ موارد نادیده گرفته شدند.
• استخراج داده و اجرا (Exfiltration and Execution): کدهای مخربی (Payloads) که برای سرقت داده‌ها یا اجرای کد از راه دور طراحی شده بودند، در ۳۳.۴٪ موارد تایید شدند.
• تغییرات پایدار (Persistent Mutation): تلاش برای ایجاد تغییرات غیرمجاز و بلندمدت در سیستم یا کدبیس.

نقطه کور npm run

بر اساس گزارش Scale X، تکان‌دهنده‌ترین یافته مربوط به دستوراتی است که در اسکریپت‌های package.json پیچیده شده‌اند. دستور npm run analyze با نرخ خطای ۶۴.۷٪، بالاترین نرخ خطا در کل مجموعه داده را داشت.

به دلیل اینکه npm run analyze شبیه به یک مرحله روتین بررسی کد (Linting) یا چک کردن تایپ‌ها (Type-checking) به نظر می‌رسد، توسعه‌دهندگان بدون شک آن را تایید می‌کنند. در واقعیت، چنین اسکریپتی می‌تواند برای سرقت متغیرهای محیطی (Environment Variables)، اجرای کدهای دلخواه یا تغییر فایل‌های خارج از دایرکتوری پروژه دستکاری شود. این الگو دقیقاً مشابه ریسک‌هایی است که در راهنمای ما درباره بهترین شیوه‌های امنیتی npm بررسی شده بود.

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

• npm run setup: نرخ خطای ۴۸.۰٪
• npm run deploy: نرخ خطای ۴۴.۹٪

در مجموع، خانواده دستورات npm-run نرخ خطای ۵۱.۱٪ داشتند که به‌طور قابل‌توجهی بالاتر از میانگین ۳۳.۴٪ برای سایر حملات استخراج داده است. نام‌های آشنا حس امنیت کاذب ایجاد می‌کنند و کاربر را به تایید بدون خواندن محتوای واقعی اسکریپت سوق می‌دهند.

مکانیسم خستگی از تایید

واترز برای شبیه‌سازی فشار محیط‌های عملیاتی، محدودیت زمانی ۶۰ ثانیه‌ای برای هر تصمیم قرار داد. در ابزارهایی مثل Claude Code یا Copilot Workspace، صف درخواست‌های اجازه می‌تواند در هر جلسه به صدها مورد برسد.

هر تصمیم کسری از ثانیه زمان می‌برد. اما پس از پنجاهمین تایید، بار شناختی (Cognitive Load) انباشته می‌شود. داده‌ها همبستگی مستقیمی بین طول جلسه و نرخ خطا نشان می‌دهند: تصمیمات انتهایی نرخ خطای بسیار بالاتری نسبت به تصمیمات اولیه دارند. این «خستگی از تایید» (Approval Fatigue)، یک بررسی امنیتی را به یک تمرین مهر زدن ساده تبدیل می‌کند.

شکاف زمینه و بار شناختی

نبود زمینه (Context) نیز قضاوت را تضعیف می‌کند. بازبین‌ها اغلب دستور را به‌صورت ایزوله می‌بینند بدون اینکه بدانند:

• کدام فایل‌ها تغییر کرده‌اند.
• عامل دقیقاً به دنبال چه هدفی بوده است.
• آیا این درخواست با تسک فعلی همسو است یا خیر.

بدون مشاهده تغییرات (Diff) یا خلاصه تسک، تنها سیگنال موجود، متن دستور است که می‌تواند به‌طور عمدی گمراه‌کننده باشد. این نقص، توسعه‌دهنده را مجبور می‌کند به‌جای تحلیل انتقادی، به تشخیص الگو (Pattern Recognition) تکیه کند.

قضاوت انسان در برابر ماشین

شکاف قابل‌توجهی بین نحوه مدیریت این ریسک‌ها توسط انسان و سیستم‌های خودکار وجود دارد. طبق گزارش‌های ثانویه از The Register و Hacker News، کاربران Claude Code حدود ۹۳٪ از پرامپت‌ها را تایید می‌کنند، هرچند این عدد توسط Anthropic تایید نشده و در طول این تحقیق به‌طور مستقل قابل تایید نبود.

اما آنچه قابل تایید است، عملکرد حالت Auto Mode در Claude Code است. به گزارش The Register، این حالت حدود ۸۳٪ از رفتارهای بیش‌ازحد جسورانه عامل را شناسایی می‌کند. این یعنی نرخ خطای ۱۷٪؛ عددی که اگرچه زیاد است، اما به‌طور قابل‌توجهی دقیق‌تر از بازبین‌های انسانی در مطالعه Scale X است.

این ۱۷٪ همچنان یک سطح حمله (Attack Surface) بزرگ است. حتی با نظارت خودکار، بخش قابل‌توجهی از دستورات خطرناک به مرحله اجرا می‌رسند. یافته اصلی این است: ابزار خودکاری که برای کمک به انسان طراحی شده، اغلب سخت‌گیرتر و قابل‌اعتمادتر از خود انسان عمل می‌کند.

بازطراحی مدل ایمنی

شواهد نشان می‌دهد دکمه «تایید/رد» فعلی، یک ابزار ایمنی ناکافی است. مدل فعلی فرض می‌کند انسان می‌تواند هزاران تصمیم کوتاه را تحت فشار زمانی به‌طور قابل‌اعتمادی ارزیابی کند، اما این شبیه‌سازی ثابت کرد که این فرض غلط است.

برای بستن این شکاف‌ها، صنعت باید به سمت مجوزهای آگاه-از-زمینه (Context-aware) بر اساس اصول اتوماسیون جریان کاری توسعه‌دهنده حرکت کند:

• نمایش زمینه فایل‌های تغییریافته: ابزارها باید در کنار درخواست، Diff را نشان دهند. دستور npm run analyze تنها زمانی خطرناک است که اسکریپت زیرین تغییر کرده باشد تا شامل یک دستور curl شود؛ نمایش این تغییر، ریسک را آشکار می‌کند.
• دسته‌بندی (Batching): گروه‌بندی دستورات مشابه برای یک تایید واحد، حجم تصمیمات را کاهش داده و خستگی را می‌گیرد.
• پیش‌فرض بر رد (Default to Deny): ابزارها باید دستورات پیچیده در اسکریپت‌ها (مانند موارد موجود در package.json) را ریسک‌تر از دستورات خام شل (Shell) بدانند. قرار دادن حالت «رد» یا «هشدار» به عنوان پیش‌فرض برای اسکریپت‌های ناشناخته، کاربر را مجبور به بررسی مجدد می‌کند.

اولویت‌های پیاده‌سازی

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

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

گام بعدی شما

• در ابزارهای کدنویسی AI، هرگز دستوراتی که در اسکریپت‌های package.json یا Makefile پیچیده شده‌اند را بدون بررسی دستی فایل منبع تایید نکنید.
• برای کاهش خستگی شناختی، تسک‌های بزرگ را به قطعات کوچک‌تر تقسیم کنید تا تعداد درخواست‌های اجازه در هر جلسه کاهش یابد.
• از ابزارهای مانیتورینگ سیستم برای شناسایی تغییرات غیرمنتظره در فایل‌های حساس پس از اجرای عامل‌ها استفاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.