دسترسی کامل به محیط‌های توسعه، حالا به بزرگ‌ترین نقطه ضعف امنیتی عامل‌های هوش مصنوعی تبدیل شده است. اگر تصور می‌کنید با پاک‌سازی پرامپت‌ها امنیت را تأمین کرده‌اید، باید بدانید مهاجمان اکنون مستقیماً از طریق زیرساخت‌های مورد اعتماد شما به مدل نفوذ می‌کنند.
به گزارش تحلیل فنی منتشر شده در پلتفرم dev.to در ۳۰ ژوئن ۲۰۲۶، مهاجمان با قرار دادن دستورات مخرب در فایل‌های پیکربندی و مخازن کد، عامل‌های عامل‌محور (Agentic) را از درون محیط‌هایشان می‌ربایند. در حالی که تمرکز صنعت بر «بهسازی» ورودی‌های کاربر برای جلوگیری از تزریق پرامپت (Prompt Injection) است، این رویکرد به‌کل زنجیره تأمین را نادیده می‌گیرد. بسیاری از تیم‌ها مخازن داخلی خود را مرزهای امن می‌دانند، اما این اعتماد زمانی به یک ریسک تبدیل می‌شود که به یک عامل (Agent) اجازه داده شود به‌طور خودمختار کدها را بخواند و بر اساس آن‌ها عمل کند. تصور کنید ابزاری که برای رفع باگ طراحی شده، به‌دلیل خواندن یک دستور مخرب در فایل تنظیمات Git، اقدام به سرقت اعتبارنامه‌های ابری (Cloud Credentials) کند. این آسیب‌پذیری در واقع تبدیل مخازن کد به سطح حمله برای عامل‌های هوش مصنوعی است که مسیر نفوذ از طریق اسکریپت‌های غیرفعال را هموار می‌کند.
سازوکار تزریق غیرمستقیم
برخلاف تزریق پرامپت سنتی که مهاجم از طریق کانال «کاربر» به مدل می‌رسد، در روش مخزن مسموم، عامل از مجوزهای قانونی خود برای خواندن مخازن، فایل‌های پیکربندی یا لیست وابستگی‌ها استفاده می‌کند. به محض اینکه این منابع مسموم شوند، عامل بدون آنکه متوجه شود، به مجری دستورات مهاجم تبدیل می‌شود.
طبق مستندات ارائه شده، این روش پیش از این اجازه داده است تا عامل‌ها اعتبارنامه‌های ابری را جمع‌آوری کنند، زیرساخت‌های داخلی را شناسایی نمایند و کلیدهای CI/CD را استخراج کنند. در این حالت، استدلال مدل دست‌کاری نشده است؛ بلکه عامل صرفاً وظیفه اصلی خود یعنی خواندن کد و پیکربندی محیط و اجرا بر اساس آن را انجام داده است.
همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد مطلق به داده‌های ورودی در سیستم‌های خودکار خطرناک است. حوادث سال ۲۰۲۵ ابعاد این آسیب‌پذیری را روشن کرد:
- Cline: یک عنوان مهندسی‌شده در Issueهای گیت‌هاب، یک نشست کدنویسی احراز شده را به نصب‌کننده بسته‌های مخرب تبدیل کرد و ۴,۰۰۰ سیستم را تحت تأثیر قرار داد.
- LiteLLM: یک نسخه دارای درِ پشتی (Backdoor) در PyPI، در یک بازه سه ساعته تقریباً ۴۷,۰۰۰ بار دانلود شد.
- سرورهای MCP: حدود ۲۰۰,۰۰۰ سرور پروتکل زمینهٔ مدل (MCP) به‌دلیل طراحی ناقص، بدون احراز هویت در معرض دید بودند.
شواهد تکمیلی در پژوهش‌های مربوط به AWS DevOps Agent دیده می‌شود. این عامل برای تحلیل ریشه خطا، داده‌های مانیتورینگ و لاگ‌ها را می‌خواند و خطوط لاگ را به‌جای شواهد فنی، به‌عنوان دستورات زبان طبیعی تلقی می‌کند؛ این امر مسیر تزریق مستقیم در لایه عملیات را باز می‌کند. این نوع تهدیدات نشان می‌دهد که برخی معماری‌های مدرن ممکن است در برابر حملات بومی عامل‌های هوش مصنوعی نابینا باشند و لایه‌های امنیتی سنتی را دور بزنند.
نقطه کور حفاظ‌ها
این تغییر در بردار حمله، پیش‌فرض‌های بنیادی امنیت هوش مصنوعی را به چالش می‌کشد. حفاظ‌ها (Guardrails) سنتی بر لایه پرامپت و محدودیت‌های استفاده از ابزار متمرکز هستند و فرض می‌کنند داده‌هایی که عامل مصرف می‌کند پاک هستند. اما وقتی «سم» در یک لیست وابستگی یا مخزن Git باشد، این پیش‌فرض‌ها فرو می‌پاشند. حمله در اینجا نه با شکستن استدلال مدل، بلکه با سوءاستفاده از اختیاراتی است که عامل در حال حاضر دارد.
شاخص‌های ریسک
اگر عامل شما قابلیت‌های زیر را دارد، در معرض حملات زنجیره تأمین است:
- خواندن کد یا پیکربندی از مخازن داخلی یا خارجی
- اجرا یا اقدام بر اساس اطلاعات خوانده شده
- فعال‌سازی خط لوله‌ها (Pipelines)، تغییر فایل‌ها یا فراخوانی APIها
اگرچه امضای کامیت‌ها و تثبیت نسخه‌ی وابستگی‌ها (Pinning) کمک می‌کنند، اما این‌ها اقدامات ناقصی هستند. عاملی که در مقیاس بزرگ عمل می‌کند، در نهایت با محتوای مخربی مواجه می‌شود که به‌اندازه کافی قانونی به‌نظر برسد.
تغییر مسیر به سمت امنیت واقعی
برای مقابله با این تهدید، تیم‌های امنیت تهاجمی در حال حرکت به سمت معماری «اعتماد صفر» (Zero Trust) برای جریان‌های کاری عامل‌محور هستند. تمرکز بر این کنترل‌های دقیق است:
- بررسی‌های یکپارچگی: پیاده‌سازی کنترل‌های منشأ و یکپارچگی پیش از هر اقدامی توسط عامل روی کد.
- حداقل سطح دسترسی (Least Privilege): محدود کردن شدید اقدامات عامل، حتی در مواجهه با منابع «مورد اعتماد».
- تشخیص ناهنجاری: نظارت بر رفتارهای غیرعادی هنگام تعامل عامل با وابستگی‌ها یا مخازن.
- تأیید انسانی (Human-in-the-Loop): طراحی جریان‌هایی که در آن‌ها اقدامات حساس به‌جای اجرای خودمختار، نیاز به تأیید صریح انسان داشته باشند. در همین راستا، بررسی شده است که آیا جداسازی پیشنهاد از اجرا می‌تواند جلوی اقدامات غیرقابل‌بازگشت AI را به‌طور مؤثر بگیرد یا خیر.
در نهایت، اقدامات حساس باید از خودمختاری کامل فاصله بگیرند. بسیاری از معماری‌های فعلی ابتدا برای «قابلیت» بهینه شده‌اند و امنیت در اولویت دوم قرار گرفته است. طراحی جریان‌هایی که تغییرات حیاتی را مشروط به تایید انسان کند، تنها راه جلوگیری از حملات با سرعت ماشین است.
گام بعدی شما
- دسترسی‌های عامل‌های خود را از سطح Admin به سطح Read-only برای مخازنی که نیاز به تغییر ندارند تغییر دهید.
- برای هر اکشن حساس (مانند حذف فایل یا تغییر تنظیمات شبکه)، یک لایه تأیید انسانی (Manual Approval) اضافه کنید.
- وابستگی‌های پروژه را با ابزارهای تحلیل امنیتی اسکن کنید تا از نبود کدهای مخرب در نسخه‌های قدیمی مطمئن شوید.
این تنها آغاز ماجراست؛ اثر موج‌گونه‌ی این تصمیم بر اکوسیستم متن‌باز را در گزارش بعدی بررسی خواهیم کرد.
گفتگو