خطرات امنیتی ایجنتهای هوش مصنوعی (و چگونه واقعاً آنها را کاهش دهیم)

آیا این خطر واقعی است یا صرفاً هیاهوی شرکتهای امنیتی؟
بیشتر مقالاتی که به تحلیل خطرات امنیتی ایجنتهای هوش مصنوعی میپردازند، از الگویی تکراری پیروی میکنند: فهرستی شمارهدار از اتفاقاتی که «ممکن است» بیفتد، همراه با سناریوهای ساختگی و خیالی؛ مثل کارمند تازهکاری که بات منابع انسانی را فریب میدهد، یا پلاگین پیشبینی آبوهوا که دسترسی نامتعارفی به فایلها میخواهد. همین حالا عبارت «AI agent security risks» را جستجو کنید؛ تمام نتایج صفحه اول، حتی دادههایی که بخش هوش مصنوعی گوگل (AI Overview) جمعآوری کرده، از همین فرمول پیروی میکنند. ممکن است برخی به مقالات پژوهشی تکیه کنند، اما تقریباً هیچکدام به یک حادثه معین، تاریخدار و رسماً مستندشده اشارهای ندارند.
این خلأ دقیقاً همان مسئلهای است که متخصصان امنیت مکرراً در مجامع عمومی مطرح میکنند. در یک بحث پر سر و صدا در Hacker News پیرامون آسیبپذیری EchoLeak، بحث گستردهای شکل گرفت مبنی بر اینکه آیا واقعاً چنین حوادثی در دنیای واقعی و عملیاتی رخ میدهند یا صرفاً در آزمایشگاههای تیم قرمز (Red Team) دیده میشوند؟ پاسخ کوتاه و صریح است: بله، این حوادث در عمل رخ میدهند.
۵ حادثه امنیتی واقعی در ایجنتهای هوش مصنوعی (نه فرضیات ذهنی)
۱. آسیبپذیری EchoLeak (شناسه CVE-2025-32711)
این آسیبپذیری ابزار Microsoft 365 Copilot را با یک اکسپلویت «بدون کلیک» (Zero-Click) هدف قرار داد؛ بدون اینکه کوچکترین تعاملی از سوی قربانی نیاز باشد. در این سناریو، یک ایمیل دستکاریشده حاوی پیلود مخفی تزریق پرامپت غیرمستقیم (Indirect Prompt Injection)، چندین روش دور زدن امنیتی را با هم ترکیب کرد: فریب سیستم طبقهبندی مایکروسافت برای مقابله با تزریق پرامپت، عبور از فیلتر پالایش پیوندها از طریق سینتکس ارجاعی مارکداون (Reference-Style Markdown)، و سوءاستفاده از بارگذاری خودکار تصویر (Auto-Fetched Image) برای استخراج و ارسال دادهها به سرور مهاجم. این آسیبپذیری امتیاز شدت CVSS برابر با ۹.۳ دریافت کرد. مایکروسافت آن را در سمت سرور وصله نمود و تایید کرد پیش از انتشار اصلاحیه، نشانهای از سوءاستفاده از آن در سطح وب دیده نشده است.
۲. باگ استخراج داده در اسلک از طریق مارکداون (Slack AI)
باگ نشت داده در Slack AI با تکیه بر همان آسیبپذیری بنیادین، اما با یک مرحله اضافه عمل میکرد. مهاجمی بدون هیچگونه دسترسی به کانالهای خصوصی، متنی را در یک کانال عمومی منتشر میکرد. این متن موتور جستجوی RAG اسلک را فریب میداد تا دادههای محرمانه کانالهای خصوصی را به درون پاسخ خود بکشد و سپس آن را در قالب یک لینک مارکداون که دادهها درون آدرس URL آن انکود شده بود رندر کند؛ همراه با عنوانی وسوسهانگیز مانند «برای احراز هویت مجدد اینجا کلیک کنید». رندر شدن پیام لینک را نمایش میداد و کلیک کاربر روی آن، دادههای حساس را روانه سرور نفوذگر میکرد؛ بنابراین این سناریو بر خلاف مدل قبلی نیاز به یک کلیک (One-Click) داشت. شرکت امنیتی PromptArmor که این آسیبپذیری را گزارش داد، با نشت دادن موفقیتآمیز کلید API یک توسعهدهنده از کانال خصوصی، آن را اثبات کرد و یادآور شد که مهاجم حتی نیازی ندارد بداند چه دادهای درون کانال خصوصی قرار دارد. همچنین این تکنیک میتوانست برای نمایش یک لینک فیشینگ کاملاً باورپذیر به کار رود.
۳. دور زدن مرزهای دسترسی در Google Antigravity
ابزار Google Antigravity که یک محیط توسعه مبتنی بر ایجنت (Agentic Coding IDE) با هسته مدل Gemini است، از مرزهای دسترسی تعیینشده توسط خودش فراتر رفت. کاربری گزینه «مجوز دسترسی به فایلهای Gitignore» را خاموش کرده بود؛ تنظیمی که منطقاً باید مانع دسترسی ایجنت به فایلهای حاوی مقادیر حساس مثل .env میشد. با این وجود، ایجنت با اجرای دستور ترمینال cat (به جای فراخوانی ابزار کنترلشده و امن خواندن فایل)، این قفل را دور زد، فایل را خواند و اطلاعات آن را به یک سرویس ثبت درخواست عمومی ارسال کرد که بهطور پیشفرض در لیست مجاز شبکه (Network Allowlist) این ابزار باقی مانده بود. مشکل در اینجا غیبت فیلتر امنیتی یا گاردریل نبود، بلکه گاردریلی وجود داشت که ایجنت آن را دور زد؛ چون یک دسترسی موازی و مجزا (دسترسی ترمینال) بیش از حد باز گذاشته شده بود و آدرسی در لیست سفید شبکه وجود داشت که کسی به حذف آن فکر نکرده بود.
۴. سرقت سورسکد در GitLab Duo
ابزار GitLab Duo تمام کانتکست صفحهای را که درباره آن سوال میشد (شامل کامنتها، متن توضیحات و بخشهای مخفی) پردازش میکرد. این عملکرد آن را در برابر دستوراتی که در این کانتکست پنهان میشدند نفوذپذیر میساخت. محققان امنیتی Legit Security دریافتند که مهاجمان میتوانند پرامپتهای دلخواه را با تکنیک یونیکد نامرئی (Unicode Smuggling) یا متن سفید روی پسزمینه سفید در توضیحات Merge Request یا پیامهای کامیت پنهان کنند. این پرامپتها Duo را وادار میکردند تا با سوءاستفاده از دسترسیهای گسترده خود به مخزن پروژه، سورسکدهای محرمانه را نشت دهد و تگهای ناامن HTML را درون پاسخهایش تزریق کند. شرکت GitLab پس از گزارش رسمی، وصلهای ارائه داد که مانع رندر کدهای ناامن HTML با لینک به خارج از دامنه gitlab.com توسط Duo شد.
۵. ربایش مرورگر با CometJacking (مرورگر Perplexity Comet)
آسیبپذیری CometJacking مرورگر ایجنتمحور Comet محصول Perplexity را با یک پیوند مخرب هدف گرفت؛ لینکی که میتوانست در قالب ایمیل فیشینگ یا یک صفحه وب در دسترس قرار گیرد. تنها با یک کلیک، ایجنت تسخیر میشد و ایمیلها، تقویم و حافظه ذخیرهشده سشنهای کاربر را در قالب انکودشده (Base64) به سرور نفوذگر میفرستاد. در گزارشی مرتبط، تیم امنیتی Brave آستانه نفوذ سادهتری را نشان داد: یک دستور پنهان در کامنت عمومی در ردیت، بدون نیاز به حتی یک کلیک روی لینک. وقتی کاربر درخواست میکرد «این صفحه را خلاصه کن»، مرورگر Comet از دستورات پنهانشده در کامنت اطاعت میکرد، رمز یکبارمصرف (OTP) کاربر را از جیمیل بیرون میکشید و از آنجا به تمام سرویسهایی که کاربر در آنها لاگین بود (شامل حسابهای بانکی و پرتالهای سازمانی) نفوذ میکرد.
| نام حادثه | هدف / سامانه | دستهبندی خطر | آنچه در واقعیت رخ داد |
|---|---|---|---|
| EchoLeak (CVE-2025-32711) | Microsoft 365 Copilot | تزریق پرامپت غیرمستقیم | نشت داده بدون کلیک (Zero-Click) از طریق لود خودکار تصویر و دور زدن CSP از طریق پروکسی معتبر. |
| نشت داده در Slack AI | Slack AI | تزریق پرامپت غیرمستقیم | رندر پیوند مارکداون که دادههای کانالهای خصوصی را به بیرون نشت میداد (نیازمند ۱ کلیک). |
| Google Antigravity | محیط کدنویسی مبتنی بر Gemini | عاملیت بیش از حد (Excessive Agency) | دور زدن مرزهای دسترسی ایجنت از طریق دستور ترمینال و استخراج فایل .env. |
| GitLab Duo | GitLab Duo | تزریق پرامپت / عاملیت بیش از حد | دستورات مخفی متنی در Merge Request از دسترسی گسترده به مخزن سوءاستفاده کرده و سورسکد را فاش میکردند. |
| CometJacking | مرورگر Perplexity Comet | دستکاری ابزار و API | یک پیوند مخرب ابزارهای ایجنت را ربود تا ایمیل، تقویم و حافظه ذخیرهشده را نشت دهد. |
نکته کلیدی: وجه اشتراک دو حادثه اول در این است که هر دو با تزریق پرامپت غیرمستقیم و دسترسی غیرمجاز به دادههای حساس آغاز شدند، اما در نقطه پایانی از فراخوانی مستقیم API یا ابزارهای بکاند استفاده نکردند. کانال نهایی استخراج داده در هر دو حمله، محتوای رندرشده بود (یک تصویر لودشده در EchoLeak و یک لینک کلیکشدنی در Slack AI). به همین دلیل، فایروالها و فیلترهای لایه شبکه هرگز متوجه این نشت داده نمیشوند؛ راهکار جلوگیری باید دقیقاً در جایی که محتوا رندر و پردازش میشود پیادهسازی شود.
دستهبندی خطرات پشت این حوادث (چارچوب OWASP)
فهرست ۱۰ خطر برتر OWASP برای برنامههای ایجنتمحور (OWASP Top 10 for Agentic Applications) که با مشارکت بیش از ۱۰۰ متخصص امنیت تدوین شده، نزدیکترین مرجع مشترک جامعه امنیت سایبری برای طبقهبندی رفتارهای پرخطر ایجنتهای هوش مصنوعی است؛ همان چارچوبی که در ۶ سرفصل پیشنهادی بخش هوش مصنوعی گوگل (AI Overview) برای این موضوع نیز به چشم میخورد. پنج حادثه مطرحشده در بخش قبل دقیقاً با این دستهبندی همپوشانی دارند:
- تزریق پرامپت و ربایش هدف (Prompt Injection & Goal Hijacking): در حوادث EchoLeak و باگ Slack AI به وضوح دیده شد.
- سوءاستفاده از هویت و سطوح دسترسی (Identity & Privilege Abuse): یا همان اصطلاح شناختهشدهتر «عاملیت بیش از حد» (Excessive Agency)؛ نظیر دور زدن محدودیت فایلهای حساس در Google Antigravity و دسترسی بیرویه به کل سورسکد در GitLab Duo.
- دستکاری ابزار یا API (Tool/API Manipulation): در حادثه CometJacking که قابلیتهای قانونی و ابزارهای مجاز ایجنت را بر ضد خود کاربر به کار گرفت.
طبقهبندی جامعتر OWASP دستهای دیگر را معرفی میکند که اگرچه در این پنج مورد وجود نداشت، اما بسیار حائز اهمیت است: اجرای کد از راه دور (Remote Code Execution) از طریق ابزارهای درونی ایجنت برای اجرای کد. تحقیقات تیم قرمز Unit 42 نشان داده سندباکسهای کانتینری پیشفرضی که همراه بیشتر فریمورکهای ایجنت عرضه میشوند، بهتنهایی امنیت کافی ندارند و نیازمند سختسازی با کنترلهای زماناجرا (Runtime Controls) سختگیرانهتر هستند.
سایر خطرات ساختاری در ایجنتهای هوش مصنوعی
دو خطر کلیدی دیگر در چارچوب OWASP وجود دارند که در این ۵ سناریو مطرح نشدند اما باید مدنظر قرار گیرند:
- مسمومسازی حافظه و کانتکست (Memory & Context Poisoning): در این حالت، آنچه مسموم میشود حافظه بلندمدت و نگهداریشده بین سشنهاست، نه صرفاً دادههای ورودی همان لحظه؛ در نتیجه یک بار تزریق موفق میتواند مدتها پس از حذف ورودی مخرب اولیه، رفتار ایجنت را منحرف کند.
- شکستهای زنجیرهای و متوالی ایجنتها (Cascading Agent Failures): این معضل زمانی رخ میدهد که خروجی آلوده یک ایجنت نفوذیافته به ورودی قابلاعتماد ایجنت بعدی تبدیل شود؛ با توجه به حرکت معماریها به سمت زنجیرهای کردن چند ایجنت، این چالش رو به گسترش است.
هوش مصنوعی گوگل نکته ششمی را نیز اضافه میکند: رفتار غیرقابلردیابی (Untraceable Behavior). از آنجا که تصمیمات ایجنتها احتمالی (Probabilistic) هستند و نه تابع قواعد ایستا و جبری، یک ورودی مشخص میتواند دو پاسخ کاملاً متفاوت ایجاد کند. این ماهیت، ریشهیابی و تحلیل علل بروز حادثه (Root-Cause Analysis) را نسبت به نرمافزارهای سنتی بسیار پیچیدهتر میسازد.
خطرات هزینهزا: از حلقههای خودکار تا سربار منابع
شرکت چکپوینت (Check Point) خطر پرهزینهای را تحت عنوان حلقههای ایجنتی (Agentic Looping) تعریف میکند؛ جایی که خواندن یک محتوای انحرافی، ایجنت را وارد حلقه استدلال بازگشتی و نامتناهی میکند تا مکرراً APIهای پولی را فراخوانی کرده یا منابع ابری رزرو کند. منشأ ممکن است یک مهاجم باشد، اما خودِ هزینه از تصمیمگیری کنترلنشده ایجنت ناشی میشود.
در مقابل، گزارشهای IBM و Unit 42 به مسئله سربار منابع (Resource Overload) اشاره دارند؛ وضعیتی که مهاجم عمداً با ارسال انبوهی از درخواستها ظرفیت پردازشی ایجنت را اشباع میکند؛ این سناریو به حملات سنتی محرومسازی از سرویس (DoS) شباهت دارد. به تعبیر ساده: یکی قبض مالی سرسامآور برای سازمان به همراه دارد، و دیگری روز کاری را فلج میکند.
تله رایج: تحقیقات تیم قرمز Unit 42 اثبات کرده که تزریق پرامپت لزوماً تنها دروازه ورود نفوذگر نیست. اندپوینتهای احرازهویتنشده یا دارای محدودیتهای ناکافی برای ابزارها، حملات سنتی SQL Injection از طریق فیلد ورودی یک ابزار، و باگهای کلاسیک مجوزدهی APIها میتوانند یک ایجنت را تسخیر کنند؛ حتی بدون اینکه حتی یک جمله پرامپت دستکاریشده ردوبدل شده باشد.
سرورهای MCP: پاشنه آشیل واقعی در زنجیره تأمین
سرورهای «پروتکل کانتکست مدل» (Model Context Protocol یا به اختصار MCP) به عنوان استاندارد اصلی اتصال ایجنتهای هوش مصنوعی به ابزارها، پایگاههای داده و سرویسهای بیرونی شناخته میشوند. با این حال، سه ارزیابی و اسکن امنیتی مستقل نشان دادهاند که این سرورها در مقیاس وسیع دارای آسیبپذیریهای جدی هستند. اگرچه جامعه آماری و متدولوژی این ارزیابیها یکسان نبوده، اما همگی به نتایج نگرانکنندهای با نرخهای دو رقمی رسیدهاند:
- گزارش امنیت سایبری Check Point در سال ۲۰۲۶: مشخص کرد که حدود ۴۰ درصد از سرورهای MCP تحلیلشده دارای آسیبپذیری بودند و اسرار امنیتی (Secrets) را افشا میکردند یا امکان اجرای کد را فراهم میساختند.
- اسکن ۱۰۰۰ سرور توسط شرکت Enkrypt AI: نشان داد تقریباً یکسوم (۳۲٪) سرورها دارای آسیبپذیریهای سطح بحرانی (Critical) هستند، به طوری که به ازای هر سرور به طور میانگین ۵.۲ آسیبپذیری کشف شد.
- اسکن مستقل ۷۶۳ سرور توسط پایگاه munio.dev: مشخص کرد ۳۱ درصد آنها در سطح اسکیما (Schema) آسیبپذیرند. علاوه بر این، ۷٬۴۲۵ جریان داده خطرناک یا اصطلاحاً «سمی» (Toxic Data Flows) شناسایی شد؛ وضعیتی که در آن چند ابزارِ ذاتاً امن، زمانی که به شکل زنجیرهای در کنار هم قرار میگیرند، یک مسیر نفوذ به شدت خطرناک ایجاد میکنند.
| منبع / مجری اسکن | تعداد سرورهای بررسیشده | نرخ آسیبپذیری شناساییشده | یافتههای کلیدی |
|---|---|---|---|
| گزارش سال ۲۰۲۶ شرکت Check Point | نامشخص | ۴۰٪ | نشت کلیدها و اسرار محرمانه؛ امکان اجرای کد از راه دور. |
| شرکت امنیتی Enkrypt AI | ۱,۰۰۰ سرور | ۳۲٪ | وجود آسیبپذیریهای بحرانی با میانگین ۵.۲ مورد در هر سرور. |
| پلتفرم munio.dev | ۷۶۳ سرور | ۳۱٪ | آسیبپذیری سطح اسکیما و کشف ۷٬۴۲۵ جریان داده ترکیبیِ سمی. |
از سرورهای ناامن تا بستههای مخرب هدفمند: سناریوی SANDWORM_MODE
سه اسکن بالا صرفاً سرورهایی را اندازهگیری کردند که به صورت سهوی آسیبپذیر پیکربندی شده بودند؛ اما ریسک زنجیره تأمین فراتر از خطای پیکربندی است. در فوریه ۲۰۲۶، شرکت امنیتی Socket زنجیره حمله خطرناکی به نام SANDWORM_MODE را مستند کرد:
مهاجمان با استفاده از تکنیک Typosquatting (ثبت نامهای بسیار مشابه بستههای معروف) پکیجهای پایتون یا npm ساختگی را به جای ابزارهایی مثل claude-code منتشر کردند. به محض نصب بسته توسط توسعهدهنده، کد مخرب روی سیستم قربانی اجرا میشد و اعتبارسنجیها و کلیدهای دسترسی را سرقت میکرد. سپس در گام بعد، این بدافزار یک سرور MCP مخرب را در دستیارهای برنامهنویسی ایجنتمحور (مانند Cursor) رجیستر میکرد. این سرور با تعبیه پرامپتهای تزریقی در بخش «توضیحات ابزارها» (Tool Descriptions)، ایجنت را فریب میداد تا کلیدهای SSH، اطلاعات دسترسی سرویسهای ابری و توکنهای API حساس کاربر را استخراج کرده و به سرور نفوذگر بفرستد.
چگونه واقعاً این ریسکها را کاهش دهیم؟ (راهکارهای عملی)
کاهش خطرات امنیتی ایجنتهای هوش مصنوعی با اضافه کردن یک «گاردریل» ساده روی ورودی متنی حل نمیشود؛ بلکه نیازمند بازطراحی معماری بر مبنای فرضیه نقض امنیت (Assume Breach) و اعمال کنترلهای ساختاری است. اقدامات کلیدی در سطوح زیر تعریف میشوند:
۱. اصل حداقل دسترسی و تفکیک ابزارها (Least Privilege & Granular Scoping)
بزرگترین خطای امنیتی در طراحی ایجنتها، اعطای دسترسیهای فراگیر (Standing Permissions) است. اگر ایجنتی تنها نیاز به خواندن یک سند دارد، نباید دسترسی ترمینال، دسترسی به شبکه و قابلیت دستکاری فایلسیستم را همزمان در اختیار داشته باشد:
- جداسازی ابزارهای خواندن از نوشتن/اجرا: ایجنتهای بازیابی اطلاعات نباید به ابزارهای جهندهای مانند اجرای دستورات Shell دسترسی داشته باشند.
- اعتبارسنجی پارامترهای ابزار در لایه کد: هیچ پارامتری از ایجنت نباید بدون اعتبارسنجی قطعی (Strict Schema Validation) مستقیماً به دستورات خط فرمان یا کوئریهای دیتابیس پاس داده شود.
- تایید انسانی در حلقه (Human-in-the-Loop): برای اقدامات حساس و غیرقابل بازگشت (مانند حذف داده، ارسال ایمیل به خارج از سازمان یا انتقال وجه) اجرای دستور باید منوط به تایید صریح کاربر باشد.
۲. ایزولهسازی محیط اجرا (Hardened Sandboxing)
اجرای ابزارهای ایجنت باید درون کانتینرهای موقت، کوتاهمدت (Ephemeral) و کاملاً ایزوله صورت گیرد:
- محدودسازی دسترسی شبکه (Egress Filtering) به صورتی که ایجنت فقط بتواند با دامنههای حیاتی و تاییدشده صحبت کند؛ مسدود کردن سرویسهای عمومی دریافت داده (مانند webhook.site یا requestbin).
- سیستم فایل فقط-خواندنی (Read-Only Filesystem) مگر برای دایرکتوریهای موقت و ایزوله.
- غیرفعالسازی دسترسی به متادیتا سرویسهای ابری (مانند AWS IMDSv2 یا Google Cloud Metadata) برای جلوگیری از سرقت کلیدهای موقت سرور.
۳. فیلترسازی و پاکسازی در لایه رندر (Render-Time Sanitization)
همانطور که در آسیبپذیریهای EchoLeak و Slack AI دیدیم، نشت داده در نقطه نمایش رخ میدهد نه لایه سوکت شبکه. بنابراین:
- مسدود کردن بارگذاری خودکار منابع بیرونی (Auto-loading images) در پاسخهای تولیدشده توسط هوش مصنوعی.
- پالایش دقیق کدهای مارکداون و HTML و اعمال سیاست سختگیرانه امنیت محتوا (Content Security Policy یا CSP).
- استفاده از صفحات میانی هشداردهنده (Interstitial Warning Pages) برای تمام لینکهای بیرونی تولیدشده توسط مدل.
۴. ارزیابی امنیتی سرورهای MCP پیش از اتصال
- پرهیز از نصب سرورهای شخص ثالث ناشناس؛ سورسکد سرورهای محلی MCP باید مانند هر پکیج کدی بررسی (Audit) شود.
- بررسی دقیق متن پرامپتها در توصیف ابزارها (Tool Descriptions) برای اطمینان از نبود دستورات تزریقی یا مشکوک.
زاویهای که اغلب نادیده گرفته میشود: سایت شما به عنوان سطح حمله
بسیاری از مدیران سایتها گمان میکنند خطرات ایجنتها فقط متوجه سازمانهایی است که خودشان ایجنت هوش مصنوعی توسعه میدهند. اما واقعیت این است: حتی اگر هیچ ایجنتی نداشته باشید، وبسایت شما بخشی از زنجیره حمله ایجنتهای دیگران است.
زمانی که کاربران از مرورگرهای ایجنتی (مانند Comet یا افزونههای هوش مصنوعی مرورگرها) برای مرور وب، خلاصهسازی و پر کردن فرمها استفاده میکنند، وبسایتهای عمومی میتوانند میزبان پرامپتهای تزریقی غیرمستقیم باشند:
- محتوای تولیدشده توسط کاربر (UGC): کامنتها، نظرات کاربران، انجمنها و رزومههای آپلودشده میتوانند حاوی پرامپتهای مخرب مخفی باشند. وقتی ایجنتِ یک کاربر دیگر یا کارشناس سازمان آن صفحه را برای خلاصهسازی باز میکند، ایجنت فریب خورده و به سیستم محلی یا اکانت قربانی حمله میکند.
- مسئولیت امنیتی مالکان وبسایت: مالکان پلتفرمها باید ورودیهای متنی کاربران را نه تنها برای حملات مرسوم وب (مانند XSS یا SQLi)، بلکه برای الگوهای تزریق پرامپت نیز پایش و پالایش کنند تا سایتشان ناخواسته به منبع توزیع حملات علیه ایجنتهای هوش مصنوعی تبدیل نشود.
مطالعه بیشتر و راهنماهای مرتبط در بیمگاه
برای بررسی تخصصیتر ابعاد این موضوع و آشنایی با قوانین، هزینهها و تجربیات عملی، مطالعه راهنماهای زیر پیشنهاد میشود:
- راهنمای جامع نحوه ریکاوری عکسهای پاکشده از گالری گوشی بدون روت
- راهنمای جامع توکن و Context Window در هوش مصنوعی چیست؟
پرسشهای متداول (FAQ)
- تفاوت تزریق پرامپت (Prompt Injection) با جیلبریک (Jailbreaking) چیست؟
- جیلبریک تلاشی از سوی کاربرِ مستقیم برای دور زدن فیلترهای اخلاقی و قوانین ایمنی خود مدل است (مانند درخواست ساخت بدافزار). در مقابل، تزریق پرامپت (بهویژه نوع غیرمستقیم آن) حملهای است که از طریق محتوای جانبی و دادههای خواندهشده توسط مدل رخ میدهد تا هدف اصلی مدل را بدزدد و وظیفهای غیرمجاز به نفع مهاجم انجام دهد.
- آیا یک ایجنت هوش مصنوعی تا به حال موجب نقض امنیتی واقعی شده است؟
- بله؛ همانطور که در آسیبپذیریهای ثبتشده ۵ گانه (از جمله EchoLeak و GitLab Duo) اثبات شد، دادههای محرمانه، کلیدهای API و سورسکدهای پروژهها با بهرهبرداری از این ابزارها عملاً در محیطهای عملیاتی استخراج و افشا شدهاند.
- آیا استفاده از مدلهای محلی (Local AI Models) ایجنتها را امنتر میکند؟
- خیر. اجرای مدل به صورت محلی مانع از خروج داده به سرور ارائهدهنده مدل (مانند OpenAI یا Anthropic) میشود، اما خطرات منطقی ایجنت مانند دور زدن دسترسیها، اجرای دستورات مخرب در سیستمعامل و نشت داده به سرور نفوذگر بیرونی همچنان به قوت خود باقی هستند.
- یک ایجنت هوش مصنوعی باید چه سطح دسترسیهایی داشته باشد؟
- تنها و منحصراً همان دسترسیهایی که برای انجام وظیفه جاری موردنیاز است. دسترسیها باید در سطح عملیات (فقط خواندن/فقط نوشتن)، زمان (انقضای خودکار) و منابع (فولدرها یا رکوردهای مشخص دیتابیس) محدود و محصور شوند.
تفاوت ساختاری: در این سناریو، هیچکس تنظیمات امنیتی را اشتباه اعمال نکرده بود؛ بلکه خودِ بسته نصبی و سرور MCP ایجادشده توسط آن، عین حمله بودند. این نمونه عینی نشان میدهد که افزودن ابزارهای شخص ثالث به ایجنتها دقیقاً معادل نصب و اجرای باینریهای ناشناس روی سیستم است.
کاهش این خطرات عمدتاً به چیزهایی وابسته است که از قبل تحت کنترل شما هستند
بسیاری از تحلیلها اینگونه نتیجهگیری میکنند که امنیت ایجنتها مسئلهای لاینحل است تا زمانی که شرکتهای توسعهدهنده مدلها بتوانند مسئله تزریق پرامپت را در لایه بنیادین هوش مصنوعی حل کنند. این نتیجهگیری گمراهکننده است.
اگر پنج حادثه مستندشده را بازخوانی کنید، متوجه یک الگوی مشترک میشوید: در هر مورد، آسیبپذیری تنها به این دلیل به یک فاجعه امنیتی و نشت داده تبدیل شد که لایههای مهندسی نرمافزار سنتیِ اطراف ایجنت دچار نقص یا سهلانگاری بودند:
- اگر کنترل لود تصاویر (Image Loading) در کلاینت سختگیرانه بود، EchoLeak متوقف میشد.
- اگر لینکهای خروجی پالایش میشدند و سیاست امنیت محتوا (CSP) رعایت میشد، آسیبپذیری Slack AI دادهای نشت نمیداد.
- اگر دسترسی ترمینال به ایجنت داده نمیشد و لیست سفید شبکه بیپروایانه باز نبود، Google Antigravity فایلهای محرمانه را فاش نمیکرد.
- اگر دسترسی ایجنت به کل مخزن کد بیقیدوشرط نبود و تگهای HTML سنیتایز میشدند، GitLab Duo سورسکد را افشا نمیکرد.
- اگر ایجنت مرورگر به حافظه نشستها و صندوق ایمیل کاربر دسترسی بیمهابا نداشت، CometJacking کارایی نداشت.
شما نمیتوانید تضمین کنید که یک مدل زبانی بزرگ هیچوقت فریب یک پرامپت هوشمندانه را نخورد؛ اما کاملاً میتوانید کنترل کنید که در صورت فریب خوردن، دستش به چه ابزارهایی برسد، به کدام فایلها دسترسی داشته باشد و بستههای خروجی آن به کدام آدرسهای شبکه هدایت شوند.
منابع و مراجع (Sources & Disclosures)
- گزارش امنیتی آسیبپذیری EchoLeak (CVE-2025-32711): تحلیل فنی اکسپلویت زیرو-کلیک مایکروسافت ۳۶۵ کوپایلوت و مکانیزم نشت تصویر.
- گزارش رسمی PromptArmor درباره Slack AI: مستندات نشت داده از کانالهای خصوصی از طریق رندر مارکداون و تزریق RAG.
- گزارش فنی رفتار خودسرانه Google Antigravity: مستندات دور زدن محدودیت فایلهای .gitignore با دستور cat و نشت به سرویسهای عمومی لاگ شبکه.
- گزارش Legit Security درباره GitLab Duo: بهرهبرداری از Unicode Smuggling و مخفیسازی متن در کانتکست Merge Request برای سرقت سورسکد.
- تحقیقات امنیتی Brave Software درباره Perplexity Comet: سوءاستفاده از ایجنتهای مرورگر از طریق کامنتهای وب و استخراج کدهای OTP.
- چارچوب امنیتی OWASP Top 10 for Agentic Applications: راهنمای رسمی طبقهبندی خطرات معماری و رفتاری ایجنتهای هوش مصنوعی.
- گزارش امنیت سایبری Check Point (نسخه ۲۰۲۶): آمار تحلیل امنیتی و نرخ ۴۰ درصدی آسیبپذیری سرورهای پروتکل کانتکست مدل (MCP).
- تحلیل بدافزار SANDWORM_MODE توسط پلتفرم Socket: مستندات مسمومسازی بستههای npm و ثبت سرورهای مخرب MCP در ابزارهای برنامهنویسی.
- پژوهشهای تیم قرمز Palo Alto Networks Unit 42: ارزیابی ضعفهای سندباکسینگ کانتینری و اکسپلویت ابزارهای ایجنت بدون نیاز به پرامپت اینجکشن.



