حملات عملی علیه ایجنت‌های هوش مصنوعی در سازمان‌ها

امروزه بخش قابل‌توجهی از اخبار امنیت سایبری به استفاده مهاجمان از هوش مصنوعی برای شناسایی اهداف، کشف آسیب‌پذیری‌ها و تولید اسکریپت یا بدافزار اختصاص دارد.

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

ایجنت‌های هوش مصنوعی ویژه برنامه‌نویسی و ابزارهای خط فرمان مانند Claude Code CLI، Gemini CLI، Codex CLI، Amazon Q CLI و ابزارهای مشابه، از جذاب‌ترین اهداف برای مهاجمان محسوب می‌شوند.

این ایجنت‌ها قادرند فایل‌ها را بخوانند و ویرایش کنند، دستورات Shell را اجرا کنند، بسته‌های نرم‌افزاری را نصب کنند و به سرویس‌های خارجی متصل شوند.

توسعه‌دهندگان نیز برای اینکه مجبور نباشند اجرای هر اقدام را به‌صورت دستی تأیید کنند، اغلب این ایجنت‌ها را در حالت خودکار (Autonomous Mode) اجرا می‌کنند.

برای یک مهاجم، چنین ایجنتی در واقع یک ابزار چندمنظوره آماده است که از همان ابتدا به مجوزهای لازم، اطلاعات حساس و سطح دسترسی موردنیاز مجهز شده است.

البته این تهدید تنها به ایجنت‌های برنامه‌نویسی محدود نمی‌شود. سایر ایجنت‌های هوش مصنوعی، مانند دستیارهای خودکار مدیریت فرایندهای مالی نیز به همین اندازه در معرض سوءاستفاده قرار دارند.

چرا ایجنت‌های مورد اعتماد می‌توانند به یک تهدید تبدیل شوند؟

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

راهکارهای امنیتی سازمانی مانند EPP، EDR، XDR و SIEM معمولاً فایل‌های مخرب، الگوهای شناخته‌شده دستورات و توالی فعالیت‌های مشکوک را شناسایی می‌کنند.

حتی اگر نمونه خاصی از یک بدافزار قبلاً دیده نشده باشد، رفتار آن معمولاً آن را لو می‌دهد؛ برای مثال:

• جست‌وجوی گسترده در میان اسناد
• اجرای فرایندهای PowerShell
• دسترسی به مخازن اطلاعات احراز هویت
• انتقال داده‌ها از یک برنامه ناشناس به یک سرور خارجی

تمام این فعالیت‌ها معمولاً باعث ایجاد حجم زیادی از هشدارها در SOC می‌شوند.

اما اعمال همین منطق تشخیص روی یک ایجنت هوش مصنوعی قانونی که از قبل روی سیستم نصب شده، بسیار دشوارتر است.

این ابزارها ذاتاً برای انجام طیف گسترده‌ای از عملیات طراحی شده‌اند.

اجرای اسکریپت‌ها، خواندن فایل‌های پیکربندی (حتی فایل‌های حاوی اطلاعات محرمانه)، جابه‌جایی اسناد و نصب وابستگی‌های نرم‌افزاری، همگی می‌توانند بخشی کاملاً عادی از فعالیت این ایجنت‌ها، به‌ویژه روی سیستم توسعه‌دهندگان، باشند.

زمانی که مهاجم قصد سوءاستفاده از چنین ایجنتی را دارد، دستورهای خود را با زبان طبیعی در اختیار آن قرار می‌دهد.

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

علاوه بر این، دستور مخرب می‌تواند در هر نوع داده‌ای که ایجنت آن را پردازش می‌کند پنهان شود؛ از جمله:

• متن داخل اسناد
• نام فایل‌ها
• حتی پیام‌های ثبت‌شده در لاگ‌های خطا

که یکی از نمونه‌های آن در ادامه این مطلب بررسی خواهد شد.

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

این ایجنت‌ها معمولاً به سرویس‌هایی مانند ایمیل، پیام‌رسان‌ها، سامانه‌های مدیریت وظایف، پایگاه‌های دانش و سرورهای MCP متصل هستند.

در نتیجه، دستور مخرب می‌تواند تقریباً از هر منبعی که ایجنت داده‌های آن را به‌صورت خودکار پردازش می‌کند، وارد سیستم شود.

در ادامه، چند نمونه از حملاتی را بررسی می‌کنیم که مهاجمان برای رسیدن به اهداف خود از ایجنت‌های هوش مصنوعی سوءاستفاده کرده‌اند.

حمله Nx؛ زمانی که یک ایجنت برنامه‌نویسی به شکار رمزهای عبور می‌رود

یکی از شناخته‌شده‌ترین و گسترده‌ترین نمونه‌ها، آلودگی بسته‌های Nx npm در آگوست ۲۰۲۵ بود؛ حمله‌ای که با نام s1ngularity شناخته می‌شود.

مهاجمان از یک آسیب‌پذیری در GitHub Actions Workflow سوءاستفاده کردند، توکن انتشار بسته‌ها را به سرقت بردند و نسخه‌های آلوده‌ای از چند بسته @nx منتشر کردند که وظیفه آن‌ها سرقت اطلاعات محرمانه توسعه‌دهندگان بود.

اسکریپت مخرب که پس از نصب اجرا می‌شد، ابتدا بررسی می‌کرد آیا Claude Code، Gemini CLI یا Amazon Q CLI روی سیستم قربانی نصب هستند یا خیر.

در صورت شناسایی هر یک از این ابزارها، ایجنت هوش مصنوعی دستوری دریافت می‌کرد تا به جست‌وجوی موارد زیر بپردازد:

• کیف پول‌های ارز دیجیتال
• فایل‌های ENV
• کلیدهای API
• و سایر اطلاعات حساس

این ایجنت‌ها نیز با گزینه‌های تأیید خودکار مانند --dangerously-skip-permissions، --yolo و --trust-all-tools اجرا می‌شدند.

پس از پایان جست‌وجو، اطلاعات جمع‌آوری‌شده به مخازن عمومی GitHub که توسط مهاجمان ایجاد شده بود، ارسال می‌شد.

در چندین موج از این حمله، هزاران داده محرمانه متعلق به صدها سازمان افشا شد.

نکته جالب این است که مهاجمان به‌جای توسعه یک ابزار اختصاصی و پیچیده برای سرقت اطلاعات، از همان ایجنت قانونی موجود روی سیستم قربانی استفاده کردند.

این ایجنت از قبل قادر بود در فایل‌های سیستم جست‌وجو کند، محتوای فایل‌ها را درک کند و اطلاعات ارزشمند را شناسایی کند.

با این حال، بررسی‌های انجام‌شده پس از حادثه توسط کارشناسان امنیت سایبری نشان داد این روش نیز بدون نقص نبوده است.

در برخی موارد، هوش مصنوعی از انجام درخواست‌هایی که غیراخلاقی تشخیص می‌داد خودداری می‌کرد.

علاوه بر این، نویسندگان بدافزار مجبور بودند کد خود را به‌گونه‌ای تغییر دهند که برای تکمیل پردازش، منتظر پاسخ ایجنت هوش مصنوعی بماند؛ فرایندی که گاهی زمان قابل‌توجهی طول می‌کشید و حجم زیادی از خروجی‌های میانی تولید می‌کرد.

ارتباط از طریق... لاگ‌های خطا

مطالعه AgentJacking یک حمله مخرب واقعی نبود، اما تنها تفاوت آن با یک حمله واقعی، هدف و نیت پژوهشگران بود؛ زیرا آن‌ها قصد سرقت اطلاعات محرمانه را نداشتند.

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

هدف این حمله، Sentry بود؛ یکی از پرکاربردترین سرویس‌های جمع‌آوری داده‌های تله‌متری و گزارش خطا.

وب‌سایت‌ها و برنامه‌های موبایل به‌صورت خودکار گزارش خطاهای خود را برای Sentry ارسال می‌کنند تا توسعه‌دهندگان بدون نیاز به گزارش کاربران، مشکلات را شناسایی و بررسی کنند.

این گزارش‌ها بدون نیاز به احراز هویت پذیرفته می‌شوند؛ زیرا بسیاری از خطاها برای کاربران ناشناس رخ می‌دهند و وب‌سایت یا برنامه اطلاعاتی درباره آن‌ها در اختیار ندارد.

پژوهشگران یک سرور MCP اختصاصی در محیط Sentry راه‌اندازی کردند تا ایجنت‌های هوش مصنوعی بتوانند گزارش‌های خطا را به‌صورت خودکار تحلیل کنند.

سپس یک گزارش خطای جعلی ارسال کردند که شامل بخشی از داده‌ها با قالبی منطبق بر ساختار داده‌های سرور MCP در Sentry بود.

در این داده‌ها، یک Prompt Injection غیرمستقیم قرار داده شده بود؛ دستوری که از ایجنت می‌خواست برای انجام «عیب‌یابی تکمیلی»، فرمانی مشابه دستور زیر را اجرا کند:

npx @controlled-validation-package --diagnose

اگر رسیدگی به خطاها به یک ایجنت هوش مصنوعی واگذار شده باشد، ممکن است این دستور را معتبر تلقی کرده و آن را اجرا کند؛ اقدامی که در نهایت به نصب خودکار یک بسته نرم‌افزاری شخص ثالث منجر می‌شود.

در این آزمایش، بسته نصب‌شده صرفاً با سرور Command-and-Control (C2) متعلق به پژوهشگران ارتباط برقرار می‌کرد و هیچ اطلاعات حساسی را استخراج نمی‌کرد.

اما در یک سناریوی واقعی، چنین بسته‌ای می‌تواند اطلاعات احراز هویت را سرقت کند، کدها را دستکاری کند یا حتی ماندگاری خود را در سیستم حفظ کند.

شناسایی اهداف چنین حمله‌ای نیز چندان دشوار نیست؛ زیرا استفاده یک سازمان از Sentry را می‌توان به‌راحتی از طریق بررسی کد وب‌سایت یا رشته‌های موجود در فایل‌های باینری برنامه‌های موبایل تشخیص داد.

نکته قابل‌توجه اینکه به گفته نویسندگان این پژوهش، Sentry وجود این مشکل را پذیرفت، اما به‌جای ارائه یک راهکار جامع، تنها همان گونه مشخص از درخواست مخربی را که از طریق MCP ارسال می‌شد مسدود کرد.

تصاویر منتشرشده در این پژوهش نیز نشان می‌دهند یکی از کارکنان Sentry این سامانه را در برابر چنین حمله‌ای «از نظر فنی غیرقابل دفاع» توصیف کرده است.

سرقت اطلاعات مالی از طریق MCP

سوءاستفاده از سرورهای MCP که به‌درستی ایمن‌سازی نشده‌اند، همانند نمونه Sentry، تنها یکی از روش‌های حمله به این پروتکل است.

استاندارد Model Context Protocol (MCP) که تنها یک سال از معرفی آن می‌گذرد، به‌سرعت مورد استقبال قرار گرفت و حتی لقب «USB برای ایجنت‌های هوش مصنوعی» را به خود اختصاص داد.

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

در نتیجه، حملات علیه MCP به‌طور اجتناب‌ناپذیری افزایش خواهند یافت؛ موضوعی که مایکروسافت نیز اخیراً درباره آن هشدار داده است.

حتی پیش از آنکه ایجنت از یک ابزار MCP استفاده کند، ممکن است تهدید در توضیحات همان ابزار پنهان شده باشد.

ایجنت‌های هوش مصنوعی توضیحات ابزارها را بررسی می‌کنند تا تشخیص دهند چه زمانی باید از آن ابزار استفاده کنند و چه اطلاعاتی را در اختیار آن قرار دهند.

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

مایکروسافت در این زمینه به سناریویی اشاره می‌کند که در آن، یک ایجنت مالی برای بررسی اطلاعات حساب بانکی تأمین‌کنندگان، از یک سرویس MCP خارجی استفاده می‌کند.

پس از اعمال یک تغییر مخرب در توضیحات ابزار، ایجنت شروع می‌کند اطلاعات مربوط به فاکتورهای پرداخت‌نشده را نیز به پاسخ‌های خود اضافه کند.

کاربر همچنان پاسخ کاملاً عادی دریافت می‌کند، اما در پشت صحنه، اطلاعات مالی محرمانه به مالک سرور ارسال می‌شود.

در نگاه اول، تمام عملیات کاملاً مجاز به نظر می‌رسند:

• ایجنت با مجوزهای کارمند فعالیت می‌کند.
• به یک سرویس مورد تأیید سازمان متصل می‌شود.
• از یک رابط استاندارد استفاده می‌کند.

اما در نهایت، نشت اطلاعات رخ داده است.

از توضیحات نسبتاً مبهم مایکروسافت مشخص نیست این مثال صرفاً یک سناریوی فرضی است یا بر اساس بررسی یک رخداد واقعی مطرح شده است.

با این حال، انتشار این مطلب از سوی تیم Microsoft Incident Response نشان می‌دهد احتمال دوم، یعنی وقوع یک حادثه واقعی، محتمل‌تر است.

حملات Prompt Injection دیگر به یک تهدید فراگیر تبدیل شده‌اند

در سال ۲۰۲۶، پژوهشگران Unit 42 تلاش‌های گسترده‌ای را برای مخفی کردن دستورهای ویژه سیستم‌های هوش مصنوعی در تعداد زیادی از وب‌سایت‌های عمومی شناسایی کردند.

هدف بسیاری از این دستورها موارد زیر بود:

• وادار کردن مدل‌های هوش مصنوعی به افشای System Prompt
• تأیید وب‌سایت‌ها و مطالب هنگام بررسی تبلیغات
• افزایش رتبه صفحات فیشینگ از طریق دستکاری سئو (SEO Manipulation)

همچنین بررسی داده‌های Common Crawl توسط گوگل نیز افزایش قابل‌توجه چنین محتواهایی را نشان می‌دهد.

بر اساس این گزارش، فاصله بین نوامبر ۲۰۲۵ تا فوریه ۲۰۲۶، میزان Prompt Injection‌های مخرب ۳۲ درصد افزایش یافته است.

البته تاکنون نمونه‌های تأییدشده‌ای از نفوذ موفق با استفاده از این روش‌ها همچنان محدود هستند.

وجود یک Prompt Injection در یک صفحه وب، الزاماً به این معنا نیست که یک ایجنت هوش مصنوعی واقعاً آن دستور را اجرا کرده باشد.

با این حال، یک نکته کاملاً روشن است:

مهاجمان از همین حالا محتوای وب را برای دورانی بهینه می‌کنند که مخاطب اصلی آن، دیگر فقط انسان‌ها نخواهند بود؛ بلکه ایجنت‌های هوش مصنوعی نیز بخش مهمی از مصرف‌کنندگان این محتوا خواهند بود.

چگونه از حملات مبتنی بر ایجنت‌های هوش مصنوعی دفاع کنیم؟

مهم‌ترین نکته‌ای که تیم‌های امنیت سایبری و تمامی کاربران هوش مصنوعی باید در نظر داشته باشند، این است که صرفاً تأیید شدن یک ایجنت برای استفاده در سازمان، به معنای قابل‌اعتماد بودن آن نیست.

سازمان‌ها باید اقدامات زیر را در دستور کار خود قرار دهند:

• فهرست کاملی از ایجنت‌ها، سرورهای MCP و ابزارهای قابل‌استفاده توسط آن‌ها تهیه و نگهداری کنند. با استفاده از Allowlist، استفاده از ابزارها و نصب بسته‌های نرم‌افزاری را تنها به مؤلفه‌هایی محدود کنید که توسط تیم امنیت اطلاعات بررسی و تأیید شده‌اند. این فهرست باید نسخه دقیق هر بسته نرم‌افزاری را نیز مشخص کند.
• تغییرات نسخه ابزارهای MCP و سایر وابستگی‌های نرم‌افزاری را به‌طور مستمر کنترل کنید. هر به‌روزرسانی باید پیش از اضافه شدن به فهرست نرم‌افزارهای مورد تأیید، دوباره ارزیابی شود.
• اصل حداقل سطح دسترسی (Principle of Least Privilege) را اجرا کنید. ایجنت‌ها باید تنها به مجوزهایی دسترسی داشته باشند که برای انجام همان وظیفه مشخص و فقط در همان بازه زمانی موردنیاز هستند.
• برای اقدامات پرریسک، تأیید انسانی را الزامی کنید. نصب بسته‌های نرم‌افزاری، اجرای اسکریپت‌ها، ارسال فایل‌ها و سایر عملیات حساس باید تنها پس از تأیید کاربر انجام شوند.
• ایجنت‌ها را در محیط‌های ایزوله اجرا کنید. این محیط‌ها باید دسترسی محدودی به ایستگاه‌های کاری توسعه‌دهندگان داشته باشند.
• حالت‌های تأیید خودکار پرخطر (Auto-Approval) را غیرفعال کنید.
• اتصالات خروجی شبکه را محدود کنید. انتقال داده باید فقط به سرویس‌های مورد تأیید سازمان مجاز باشد.
• اطلاعات محرمانه را در مخازن امن و متمرکز (Secure Vaults) نگهداری کنید. از توکن‌های کوتاه‌عمر استفاده کنید و آن‌ها را به‌صورت منظم تغییر دهید.
• لاگ‌های Prompt، فراخوانی ابزارها (Tool Calls)، دستورات Shell و ترافیک شبکه ایجنت‌ها را به سامانه‌های SIEM و XDR ارسال کنید. برای اینکه این راهکارها بتوانند به‌طور مؤثر فعالیت‌های مشکوک را شناسایی کنند، باید علاوه بر دسترسی به اطلاعات عملیاتی دقیق درباره فعالیت ایجنت‌ها، از مجموعه قوانین تخصصی متناسب با فرایندهای پردازش داده در سامانه‌های هوش مصنوعی نیز بهره ببرند.