یک عامل کدنویس می‌تواند در یک لحظه باگی را رفع کند و در لحظه‌ای دیگر، یک درِ پشتی (Backdoor) به محیط عملیاتی شما باز کند. ریسک‌ها سیستماتیک هستند؛ چه یک عامل یک وابستگی آلوده را نصب کند، چه دستورات جاسازی‌شده در محتوای نامعتبر را دنبال کند، و چه دستوری را با اعتبارنامه‌های بیش از حد اجرا نماید، امنیت به خطر می‌افتد. Chainguard معتقد است تنها راه توقف این تهدیدها، برخورد با هر عامل (Agent) — شبیه به کارمندی تازه‌وارد که هنوز مورد اعتماد نیست — به عنوان یک تهدید بالقوه و محبوس کردن آن در یک محیط ایزوله یا سندباکس است.
این چرخش راهبردی در حالی رخ می‌دهد که سازمان‌ها از چت‌های ساده مبتنی بر هوش مصنوعی به سمت عامل‌های خودمختاری می‌روند که می‌توانند بسته‌ها را نصب و دستورات شل (Shell) را اجرا کنند. در حالی که این قابلیت‌ها عامل‌ها را مفید می‌کنند، هم‌زمان حفره‌های امنیتی عظیمی ایجاد می‌کنند. این چالش‌ها مشابه مواردی است که DeepKeep با معرفی AI Lens برای مسدود کردن نشت داده‌ها در عامل‌های کدنویس به دنبال حل آن‌هاست. طبق گزارش این شرکت، اگر یک عامل دستور مخربی را که در یک کتابخانه شخص ثالث جاسازی شده اجرا کند، می‌تواند تمام کلیدهای امنیتی و مخزن اسرار (Secret Store) شما را در چند ثانیه لو دهد. همان‌طور که تیم‌ها عامل‌های بیشتری را به‌صورت موازی به کار می‌گیرند، تأمین امنیت کدی که آن‌ها تولید می‌کنند تنها بخشی از مشکل است؛ در واقع خودِ محیط اجرا به سطح حمله (Attack Surface) تبدیل می‌شود.
برای حل این مشکل، Chainguard در رویداد Assemble London سه رکن امنیتی جدید معرفی کرد: Workspaces، Checks و حفاظت‌های گسترده‌تر برای کتابخانه‌ها. این ابزارها به سه پرسش حیاتی سازمان‌های سازمانی پاسخ می‌دهند: عامل کجا اجرا می‌شود، خروجی آن چگونه تأیید می‌شود و چه نرم‌افزارهای خارجی اجازه ورود به سازمان را دارند. در حال حاضر Workspaces و Checks در مرحله بتا و بخش کتابخانه‌های Go و .NET در دسترسی زودهنگام (Early Access) هستند.
سخت‌سازی محیط اجرا
مرکز این استراتژی، Workspaces است که برای هر توسعه‌دهنده و عامل، یک میکرو-ماشین مجازی (MicroVM) — شبیه به یک اتاق دربسته و ضدصدا که هیچ ارتباطی با اتاق‌های دیگر ندارد — فراهم می‌کند. این محیط، درخت کاری محلی توسعه‌دهنده را همگام‌سازی می‌کند تا او بتواند از ویرایشگر و گردش‌کار Git خود استفاده کند، در حالی که اجرای کد دور از ماشین شخصی او رخ می‌دهد. همچنین، محیط‌های مجزا اجازه می‌دهند چندین عامل به‌طور موازی تغییرات را آزمایش کنند بدون اینکه محیط کاری یکدیگر را به اشتراک بگذارند یا مختل کنند.
به نقل از مستندات Chainguard، این جداسازی حیاتی است زیرا قابلیت‌های مفید یک عامل، مانند اجرای دستورات، نصب بسته‌ها و دسترسی به سرویس‌ها، دقیقاً همان مسیرهای بالقوه برای نفوذ هستند. این رویکرد با استراتژی‌های جدیدی نظیر پلتفرم امنیتی آناکوندا برای جلوگیری از رفتارهای پیش‌بینی‌نشده در دسته‌های عامل‌های خودمختار هم‌سو است. در حالی که یک سیاست (Policy) که در دستورات یک عامل نوشته شده، به این بستگی دارد که عامل از آن پیروی کند، اما مرزهای سخت‌افزاری که توسط محیط اجرا تحمیل می‌شوند، می‌توانند حتی زمانی که مدل تصمیم اشتباهی می‌گیرد، اتفاقات را محدود کنند. Workspaces ابزارهای مورد نیاز مهاجم را حذف می‌کند:
- میانجی‌گری اعتبارنامه‌ها: طبق اعلام شرکت، اعتبارنامه‌های واقعی هرگز مستقیماً وارد محیط ورک‌اسپیس نمی‌شوند. ابزارهایی که به اعتبارنامه‌های مبتنی بر دیسک نیاز دارند، جایگزین‌های رمزنگاری‌شده و کوتاه‌مدت دریافت می‌کنند تا اسرار قابل استفاده مجدد از دسترس عامل دور بمانند.
- کنترل شبکه: امنیت شبکه از طریق سیاست‌های خروجی (Egress Policies) اختیاری مدیریت می‌شود. این سیاست‌ها ارتباطات خروجی را فقط به مقاصد تأییدشده محدود می‌کنند و توانایی یک وابستگی آلوده یا عاملی که دچار Prompt Injection شده است را برای ارسال داده‌ها به بیرون کاهش می‌دهند.
- ایزولاسیون سخت‌افزاری: استفاده از MicroVMها باعث می‌شود بارهای کاری به‌طور فیزیکی جدا شوند و تضمین گردد که نفوذ به یک جلسهٔ عامل، به جلسات دیگر سرایت نکند.
این محیط‌ها از بسته‌های سیستم‌عامل Chainguard استفاده کرده و وابستگی‌ها را در زمان اجرا با فایل lockfile تطبیق می‌دهند. پیشنهاد فعلی Chainguard در بخش OS Packages، بسته‌هایی است که به‌طور مداوم از سورس کد نگهداری می‌شوند و شامل لیست مواد نرم‌افزاری (SBOM) هستند. همچنین Workspaces سوابق امضاشده‌ای از محیط، تغییرات کد و نتایج بررسی‌ها تولید می‌کند تا تیم‌های امنیتی به‌جای تکیه بر خلاصهٔ ارائه‌شده توسط خودِ هوش مصنوعی، بتوانند دقیقاً بررسی کنند که عامل چه کاری انجام داده است.
بستن حلقه اعتبارسنجی
اعتبارسنجی معمولاً کندترین بخش چرخه کدنویسی هوش مصنوعی است. یک عامل کد می‌نویسد، آن را به خط لوله یکپارچه‌سازی مداوم (CI) می‌فرستد، منتظر می‌ماند تا یک Runner آماده شود و سپس پس از آنکه بستر متنی (Context) مدل تغییر کرده است، گزارش خطا را دریافت می‌کند. تکرار این فرآیند برای چندین عامل، صف‌های انتظار را افزایش داده و کارهای مربوط به آماده‌سازی را تکرار می‌کند.
Chainguard Checks این فرآیند را به عنوان یک فراخوانی ابزار (Tool Call) مستقیماً وارد حلقه کاری عامل می‌کند. وقتی عامل تغییری ایجاد می‌کند، جلسه متوقف شده و بررسی‌ها در یک MicroVM ایزوله سخت‌افزاری اجرا می‌شوند. سپس عامل با لاگ‌های خطای ساختاریافته در بستر متنی خود بازمی‌گردد تا پیش از آنکه انسانی کد را ببیند، خطاها را تکرار و رفع کند.
برای بهینه‌سازی سرعت، این سیستم از اسنپ‌شات‌های گرم (Warm Snapshots) حاوی وابستگی‌های پیش‌نصب‌شده استفاده می‌کند که فقط هنگام تغییر lockfile بازسازی می‌شوند. این فرآیند همچنین شامل تزریق اعتبارنامه‌های کوتاه‌مدت در سمت میزبان به درخواست‌های خروجی و سیاست‌های اعلامی (Declarative) برای دسترسی به شبکه است. Chainguard ادعا می‌کند این طراحی نتایج را در چند ثانیه بازمی‌گرداند و محاسبات تکراری را کاهش می‌دهد، هرچند هنوز بنچمارک‌های مستقل در مخازن مختلف برای تأیید این ادعا ارائه نشده است.
نکته کلیدی این است که هر اجرای موفق، یک گواهی امضاشده (Signed Attestation) تولید می‌کند. این یک رکورد رمزنگاری‌شده است که محیط، نتیجه تست و کامیت خاص را به هم وصل می‌کند. گیت‌های ادغام (Merge Gates) در مراحل بعدی می‌توانند این شواهد را تأیید کرده و نتیجه را بپذیرند بدون اینکه نیاز باشد کل مجموعه تست‌ها را مجدداً اجرا کنند. این یک تمایز حیاتی بین «انتقال یک سند امضاشده» و «انتقال ادعای یک عامل مبنی بر اینکه تست‌ها پاس شده‌اند» ایجاد می‌کند.
حاکمیت بر زنجیره تأمین
عامل‌ها اغلب کتابخانه‌های خارجی را فراخوانی می‌کنند که ممکن است حاوی بدافزار یا آسیب‌پذیری‌های شناخته‌شده باشند. Chainguard Libraries برای جلوگیری از این اتفاق، کاتالوگ مدیریت‌شده و نقاط انتهایی (Endpoints) خود را برای وابستگی‌های زبان‌های متن‌باز گسترش داده است. این سرویس به‌گونه‌ای طراحی شده است که با مدیریت آرتیفکت‌ها و گردش‌کارهای توسعه سازگار باشد و منشأ (Provenance) و SBOMهای امضاشده را برای بسته‌های ساخته‌شده توسط Chainguard فراهم کند.
اندپوینت‌های جدید Go و .NET که در حال حاضر در دسترسی زودهنگام هستند، قابلیت‌های زیر را ارائه می‌دهند:
- اسکن پیشرفته: شناسایی بدافزارها و نرم‌افزارهای خاکستری (Greyware) در بسته‌های ورودی.
- اجرای سیاست‌ها: استفاده از سیاست‌های قابل تنظیم برای بسته‌های نرم‌افزاری جهت مسدود کردن وابستگی‌های پرریسک.
- رفع CVEها: اندپوینت .NET جایگزینی برای مصرف مستقیم NuGet ارائه می‌دهد، در حالی که هر دو زبان Go و JavaScript اکنون شامل اصلاحات Backport برای آسیب‌پذیری‌های با شدت بحرانی (Critical) و بالا (High) هستند.
اصلاحات Backport برای تیم‌هایی حیاتی است که نمی‌توانند بدون تست‌های گسترده یا تغییرات در اپلیکیشن، فوراً به یک نسخه اصلی (Major Version) جدیدتر مهاجرت کنند. برای زبان‌های جاوا و پایتون، این شرکت از ائتلاف صنعتی Athena استفاده می‌کند تا آرتیفکت‌های اصلاح‌شده برای آسیب‌پذیری‌هایی که توسط مدل‌های پیشرو هوش مصنوعی کشف شده‌اند را در همان روز انتشار عمومی فراهم کند.
شکاف استثمار در سازمان‌های بزرگ
هم‌زمان با این ابزارها، Chainguard گزارش «شکاف استثمار هوش مصنوعی» (The AI Exploit Gap) را منتشر کرد که حاصل نظرسنجی از ۱,۳۰۰ مدیر امنیت در سپتامبر ۲۰۲۶ است. پاسخ‌دهندگان حداقل در سطح مدیر (Director) بودند و عموماً در سازمان‌هایی با حداقل ۵۰۰ کارمند (با حداقل ۲۵۰ کارمند در سنگاپور و امارات/عربستان) فعالیت می‌کردند.
داده‌ها نشان‌دهنده یک شکاف عمیق در نحوه مدیریت ریسک توسط شرکت‌ها است:
- شکاف وصله‌گذاری: در سازمان‌هایی با درآمد بیش از ۱ میلیارد دلار، ۶۶٪ اعتراف کردند که گاهی آسیب‌پذیری‌های بحرانی یا با شدت بالا را بدون وصله رها می‌کنند؛ در حالی که این عدد در شرکت‌های با درآمد زیر ۲۵۰ میلیون دلار تنها ۲۷٪ است.
- اضطراب هوش مصنوعی: ۹۳٪ پاسخ‌دهندگان ابراز نگرانی کردند که نمی‌توانند اکسپلویت‌های مبتنی بر هوش مصنوعی را با سرعت کافی رفع کنند.
- تکرار حملات: ۷۶٪ از شرکت‌ها یک حمله تأییدشده یا مشکوک مبتنی بر هوش مصنوعی را در سال گذشته گزارش کرده‌اند.
شرکت‌های بزرگ دلیل این اتفاق را تضادهای تجاری، مانند ترس از اختلال در خدمات و اولویت‌های متناقض محصولات می‌دانند. این نشان می‌دهد مشکل تنها یافتن باگ‌ها نیست، بلکه توانایی عملیاتی برای استقرار اصلاحات بدون شکستن سیستم‌های قدیمی و عظیم (Legacy) است.
برای یک مدیر کسب‌وکار، این یعنی گلوگاه پذیرش هوش مصنوعی دیگر «هوش» مدل نیست، بلکه «اعتماد» به زیرساخت است. اگر نتوانید مستقل از خلاصه ارائه‌شده توسط مدل، آنچه را که عامل انجام داده تأیید کنید، نمی‌توانید آن را در مقیاس وسیع مستقر کنید. Chainguard با خودکارسازی اعتبارسنجی و ایزولاسیون چرخه اصلاح، قصد دارد این پنجره مواجهه با خطر را ببندد.
باید منتظر ماند و دید که آیا انتقال Workspaces و Checks از مرحله بتا به دسترسی عمومی (GA) می‌تواند این کنترل‌ها را در محیط‌های سازمانی پیچیده و چند-مخزنی (Multi-repo) بدون تبدیل شدن به یک گلوگاه عملکردی، مقیاس‌پذیر کند یا خیر.
گام بعدی شما
- اگر از عامل‌های کدنویس استفاده می‌کنید، دسترسی آن‌ها به توکن‌های محیط عملیاتی را فوراً محدود و از جایگزین‌های کوتاه‌مدت استفاده کنید.
- بررسی کنید آیا ابزارهای CI/CD شما قابلیت پذیرش گواهی‌های امضاشده (Attestations) را دارند یا همچنان به اجرای مجدد تست‌ها متکی هستید.
- برای وابستگی‌های بحرانی، به‌جای مصرف مستقیم از مخازن عمومی، از سرویس‌های مدیریت‌شده‌ای که SBOM ارائه می‌دهند استفاده کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell و تأثیر آن‌ها بر استنتاج مدل‌های امنیتی مراجعه کنید.
گفتگو