اگر فکر می‌کنید فایل README یا یادداشت‌های قدیمی مهاجرت کد شما فقط آشغال‌های بی‌خطری هستند، در واقع یک حفره امنیتی در حال رشد را نادیده می‌گیرید. در ۱۸ ژوئن ۲۰۲۶، تحلیل دقیقی از وب‌سایت dev.to هشدار داد که برای ابزارهای کدنویسی عامل‌محور، کل مخزن کد شما دیگر صرفاً مکانی برای ذخیره کد نیست، بلکه یک جریان ورودی اصلی است که می‌تواند به سلاحی علیه شما تبدیل شود.
بسیاری از برنامه‌نویسان تصور می‌کنند امنیت هوش مصنوعی فقط به معنای جلوگیری از نوشتن کدهای ناامن توسط مدل است. این دیدگاه بسیار محدود است. خطر واقعی در هر چیزی نهفته است که عامل هوش مصنوعی (AI Agent) قبل از نوشتن اولین خط کد می‌خواند و هر چیزی است که اجازه اجرای آن را پس از نوشتن دارد. در واقع، بافت مخزن کد شما اکنون به یک سطح حمله تبدیل شده است.
یک عامل هوش مصنوعی را به عنوان یک برنامه‌نویس تازه‌کار تصور کنید که دسترسی کامل به شل (Shell) دارد و سرعت تایپ خیره‌کننده‌ای دارد، اما هیچ حافظه اجتماعی درباره این موضوع ندارد که چرا مخزن کد شما به این شکل است. آن‌ها نمی‌دانند که فایل 'example_setup.sh' مربوط به سال ۲۰۲۲ منسوخ شده است؛ آن‌ها فقط یک دستور می‌بینند و با اعتماد به نفس کامل آن را اجرا می‌کنند. آن‌ها عادات خواندن عجیبی دارند و هیچ مفهومی از تاریخچه انسانی پشت یک فایل ندارند.
تغییر در مرزهای اعتماد
عامل‌های کدنویس، بافت اجتماعی پروژه را نمی‌فهمند. آن‌ها درک نمی‌کنند که یک فایل «فقط یک ابزار کمکی بود که کسی فصل گذشته اضافه کرد». در عوض، آن‌ها فقط متن، ابزارها، مسیرها، دستورات و الگوها را می‌بینند. وقتی یک عامل از بافت پروژه استفاده می‌کند تا بفهمد چه چیزی «عادی» است، آن محتوا وارد محدوده اعتماد می‌شود.
این تغییر برای تیم‌هایی که سال‌ها مستندات و مثال‌ها را به عنوان زباله‌های کم‌ریسک دیده‌اند، تکان‌دهنده است. اکنون مستندات قدیمی، مثال‌های منسوخ، فایل‌های دستورالعمل محلی، قراردادهای پنهان پروژه، اسکریپت‌های وابستگی، هوک‌های شل (Shell Hooks)، وب‌هوک‌ها، حافظه‌ها، کارگران تفویض‌شده (Delegated Workers) و تغییرات قبلی (Diffs) همگی می‌توانند به ابزاری برای هدایت مدل تبدیل شوند. برخی از این بافت‌ها مفید، برخی زباله و برخی ممکن است خصمانه باشند.
طبق گزارش dev.to، این وضعیت دو حالت شکست متمایز ایجاد می‌کند:
- بافت بدِ خسته‌کننده: دستورالعمل‌های راه‌اندازی قدیمی، مثال‌هایی که از APIهای منسوخ استفاده می‌کنند، یادداشت‌های معماری قدیمی که دیگر با محیط عملیاتی (Production) مطابقت ندارند، تست‌هایی که مفروضات ناامن را کدگذاری کرده‌اند، یا قطعه‌کدهایی کپی‌شده با تنظیمات امنیتی ضعیف. این موارد مدل را به سمت الگوهای منسوخ یا شکننده سوق می‌دهند.
- بافت بدِ خصمانه: دستوراتی به سبک تزریق پرامپت (Prompt Injection) که در فایل‌هایی پنهان شده‌اند که احتمالاً عامل آن‌ها را می‌خواند، اسکریپت‌های وابستگی که بیش از حد انتظار اجرا می‌شوند، پیکربندی‌های هوکی که یک دستور محلی را به یک مسیر اجرای گسترده‌تر تبدیل می‌کنند، یا مثال‌های مسموم که تغییرات آینده را به سمت الگوهای ناامن می‌برند.
در هر دو حالت، نتیجه یکسان است: عامل خروجی خود را بر اساس فرضیه‌ای می‌سازد که شما هرگز قصد تایید آن را نداشتید.
خطر اتوماسیون محلی
برای اینکه این ابزارها مفید باشند، باید بتوانند کارهایی انجام دهند. آن‌ها باید فرمتر را اجرا کنند، تست‌ها را بگیرند، فایل‌ها را جستجو کنند، درخواست‌های Pull Request باز کنند، اسکریپت‌های پروژه را فرا بخوانند، وب‌هوک‌ها را فعال کنند و کار را به عامل دیگری بسپارند. این همان ارزش اصلی کدنویسی عامل‌محور است، اما دقیقاً جایی است که «شعاع تخریب» آغاز می‌شود.
یک سیستم هوک فقط یک ویژگی بهره‌وری نیست؛ بلکه اتوماسیون است. وقتی این سیستم می‌تواند دستوراتی را در محیط واقعی توسعه‌دهنده اجرا کند، باید با همان سخت‌گیریی对待 شود که یک اسکریپت Build对待 می‌شود.
بر اساس گزارش dev.to، توسعه‌دهندگان باید سوالات سخت و غیرمعمولی درباره هوک‌های خود بپرسند:
- چه کسی اجازه ویرایش این هوک را دارد؟
- چه دستور خاصی را اجرا می‌کند؟
- به کدام متغیرهای محیطی دسترسی دارد؟
- آیا اعتبارنامه‌های توسعه‌دهنده را به ارث می‌برد؟
- آیا یک اسکریپت نصب بسته (Package Install Script) می‌تواند روی آن اثر بگذارد؟
- آیا داده‌ای را خارج از مخزن کد می‌نویسد؟
- آیا هنگام اجرا، لاگ (Log) واضحی وجود دارد؟
هیچ‌کدام از این‌ها دانش امنیتی جدیدی نیست. خط لوله‌های CI، اسکریپت‌های بیلد و نصب‌کننده‌های وابستگی سال‌هاست که در این دنیا هستند. تفاوت این است که عامل‌های کدنویسی، اتوماسیون محلی را شبیه به یک گفتگو سبک و ساده جلوه می‌دهند. این احساس خطرناک است. اگر یک بسته آلوده یا یک هوک شلخته بتواند یک اقدام کوچک عامل را به یک رویداد سطح ماشین تبدیل کند، هوشمندی مدل دیگر اهمیتی ندارد؛ این گردش کار (Workflow) است که اهمیت دارد.
ریسک‌های حافظه و تفویض اختیار
پلتفرم‌های مدرن از چت‌های تک‌مرحله‌ای به سمت حافظه بلندمدت و تفویض اختیار حرکت می‌کنند، جایی که کار بین کارگران متخصص تقسیم می‌شود. در حالی که این‌ها ارتقای قابلیت هستند، اما ارتقای حاکمیتی (Governance) نیز می‌باشند.
حافظه باعث می‌شود عامل‌ها تکراری نباشند و ردیابی نتایج، هدایت آن‌ها را آسان‌تر می‌کند. وب‌هوک‌ها و ویژگی‌های دیده‌شدن (Visibility) باعث می‌شوند سیستم کمتر شبیه یک جعبه متن جادویی و بیشتر شبیه زیرساخت توسعه‌دهنده به نظر برسد. با این حال، وضعیت مفید همچنان «وضعیت» (State) است و تفویض اختیار همچنان تفویض اختیار است.
وقتی یک عامل می‌تواند ترجیحات پروژه را به خاطر بسپارد، کار واگذار کند، سیستم‌های خارجی را فعال کند و در یک حلقه وظیفه‌ی طولانی‌تر عمل کند، باید شکل این حلقه را بازرسی کنید:
- چه حافظه خاصی در حال ذخیره شدن است؟
- چه کسی اختیار تغییر آن حافظه را دارد؟
- دقیقاً چه زمانی از آن حافظه استفاده می‌شود؟
- کدام عامل‌ها می‌توانند این بافت ذخیره‌شده را به ارث ببرند؟
- کارگران تفویض‌شده اجازه فراخوانی چه ابزارهایی را دارند؟
- نتایج چگونه قبل از قرارگیری در کدبیس بازبینی می‌شوند؟
این یک دعوت به پانیک نیست، بلکه دعوتی است برای اینکه دست از تصور این برداریم که عامل‌ها فقط یک Auto-complete پیشرفته‌تر هستند. Auto-complete متن پیشنهاد می‌دهد، اما گردش‌های کاری عامل‌محور، مفروضات را جمع می‌کنند، ابزارها را فرا می‌خوانند، دستورات را اجرا می‌کنند و تغییراتی به جای می‌گذارند که اجراهای آینده به آن‌ها اعتماد می‌کنند. این یک کلاس متفاوت از سیستم است.
کنترل‌های عملی برای تیم‌ها
توقف استفاده از عامل‌ها یک پاسخ غیرجدی است. در عوض، تیم‌ها باید گردش کار را از طریق چهار گام عملی «کمتر لغزنده» (Less Squishy) کنند:
۱. محدود کردن دامنه: وقتی عامل فقط به سه فایل نیاز دارد، او را به کل جهان دسترسی ندهید. از وظایف محدود و Worktreeهای یک‌بارمصرف برای تغییرات ریسکی استفاده کنید. تغییرات (Diffs) غیرمرتبط را از درخت کاری خارج کنید تا عامل مجبور نباشد حدس بزند کدام آشفتگی عمدی است.
۲. بازرسی دستورالعمل‌ها: فایل‌هایی را که احتمالاً عامل‌ها به عنوان راهنما می‌خوانند، بازبینی کنید: مستندات ریشه، فایل‌های دستورالعمل عامل، استانداردهای کدنویسی، مثال‌ها، یادداشت‌های قدیمی مهاجرت و چک‌لیست‌های داخلی. اگر منسوخ شده‌اند، آن‌ها را حذف یا اصلاح کنید. هر دستوری در یک فایل راهنما را به عنوان بخشی از کد اجرایی سیستم تلقی کنید.
۳. سخت‌سازه کردن اجرا: کارهای ریسکی را در صورت امکان در Sandbox اجرا کنید. اعتبارنامه‌ها را محدود نگه دارید و از Secrets محیطی در شل بپرهیزید. پیکربندی هوک‌ها را با همان سخت‌گیریِ خط لوله CI بررسی کنید. رفتار وابستگی‌ها را برای گردش کارهایی که عامل‌ها فعال می‌کنند، پین (Pin) یا بازرسی کنید. مطمئن شوید که «اجرای تست‌ها» به طور مخفیانه به معنای «اجرای هر اسکریپت با هر توکن موجود» نباشد.
۴. مطالبه شفافیت: شما باید بتوانید دقیقاً پاسخ دهید که عامل چه چیزی خوانده، چه ابزارهایی را فراخوانده، چه فایل‌هایی را تغییر داده، چه دستوراتی اجرا شده، چه مفروضاتی داشته و چه مواردی هنوز نیاز به بازبینی انسانی دارد. اگر پاسخ این است که «فکر می‌کنم خوب بود»، گردش کار برای کارهای با شعاع تخریب بالا به اندازه کافی بالغ نیست.
مدل مالکیت انسانی
در نهایت، توسعه‌دهندگان نمی‌توانند قضاوت را برون‌سپاری کنند. عامل‌ها می‌توانند در زمین‌های شناخته‌شده سریع حرکت کنند — آن‌ها می‌توانند ساختار بسازند، بازسازی (Refactor) کنند، بازرسی کنند، خلاصه کنند و قطعات را به هم متصل کنند — اما آن‌ها همچنین می‌توانند با اعتماد به نفس مطلق، بافت اشتباه را دنبال کنند.
مالکیت انسانی باید صریح باقی بماند. شخصی که سیستم را مدیریت می‌کند همچنان مالک معماری، اعتبارنامه‌ها، بازبینی، کیفیت تست و تصمیمات انتشار است. این بدان معناست که:
- اگر یک عامل یک Pull Request باز می‌کند، استاندارد بازبینی نباید به دلیل غیرانسانی بودن نویسنده کاهش یابد.
- اگر یک عامل کد احراز هویت را ویرایش می‌کند، بازبینی امنیتی باید سخت‌گیرانه‌تر شود، نه سهل‌تر.
- اگر یک عامل اسکریپت‌ها یا هوک‌ها را ویرایش می‌کند، با آن به عنوان کار زیرساختی برخورد کنید.
- اگر یک عامل ادعا می‌کند تست‌ها پاس شده‌اند، بررسی کنید که دقیقاً کدام تست‌ها اجرا شده‌اند و چه چیزی را اثبات می‌کنند.
اسکریپت‌ها یا هوک‌های تولید شده توسط عامل را به عنوان کار زیرساختی در نظر بگیرید. بهترین تیم‌ها کسانی نخواهند بود که عامل‌ها را ممنوع می‌کنند، یا کسانی که به هر عامل یک توکن دائمی و یک پرامپت قهرمانانه می‌دهند. بلکه کسانی خواهند بود که کار عامل‌محور را به یک فرآیند توسعه خسته‌کننده، قابل بازرسی و با نظارت دقیق تبدیل می‌کنند.
گفتگو