نگاهی به OWASP Top 10 For Agentic Applications 2026

زمان مطالعه: 38 دقیقه

سازمان OWASP سندی با عنوان “OWASP Top 10 For Agentic Applications 2026” منتشر و در اون ۱۰ تهدید برتر برای برنامه‌های عامل محور (Agentic) رو با هدف اطلاع رسانی عمومی، ارائه کرده. در این پست نگاهی به این سند انداختیم.

 

مقدمه:

سامانه‌های هوش مصنوعی عامل محور (Agentic AI) به‌ سرعت در حال گذر از مرحله پایلوت به محیط عملیاتی در حوزه‌هایی مانند مالی، سلامت، دفاع، زیرساختهای حیاتی و بخش عمومی هستن. برخلاف خودکارسازی‌ وظیفه‌محور، عاملها اغلب به نمایندگی از کاربران و تیم‌ها، در چندین گام و در میان چندین سامانه برنامه‌ریزی میکنن، تصمیم میگیرن و اقدام میکنن . ابتکار امنیت عامل محور (Agentic Security Initiative)، تاکنون کار تعریف سازوکارهای حفاظتی برای برنامه‌های عامل محور رو شروع کرده و مجموعه‌ای از راهنماها رو در سراسر چرخه عمر این برنامه‌ها منتشر کرده.

طبقه‌بندی اصلی ما با عنوان “هوش مصنوعی عامل محور، تهدیدها و راهکارهای کاهش”، یک تعریف پایه از عاملها، رابطه‌اشون با برنامه‌های مبتنی بر LLM، نقش خودمختاری، و بررسی دقیق تهدیدها و اقدامات مقابله‌ای ارائه میده. اسناد تکمیلی دیگه هم موضوعاتی مانند مدلسازی تهدید (Agentic Threat Modelling Guide)، ایمن‌سازی معماری، طراحی، توسعه و استقرار برنامه‌های عامل محور (Securing Agentic Applications) و همچنین حاکمیت (State of Agentic AI Security and Governance) رو پوشش میدن.

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

OWASP Top 10 برای برنامه‌های عامل محور (یا OWASP Agentic Top 10) بعنوان یک قطب نما و مرجع اصلی برای رهبران و متخصصان امنیت عمل میکنه تا ۱۰ تهدید با بیشترین تأثیر رو درک و مسیر خودشون رو شروع کنن.

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

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

تمرکز ما بر برنامه‌های عامل محور است، اما این برنامه‌ها بصورت مجزا وجود نخواهند داشت و بخشی از توسعه یک برنامه مبتنی بر LLM خواهند بود. در نتیجه، ورودیهای ما به OWASP Top 10 for LLM Applications و سایر استانداردهای مرتبط ارجاع میدن، از جمله سایر Top 10های OWASP، استاندارد CycloneDX، موارد Top 10 for Non-Human Identities (NHI) و سامانه OWASP AI Vulnerability Scoring System (AIVSS) برای امتیازدهی و اولویت‌بندی.

عاملها، آسیب‌پذیریهای موجود رو تشدید میدن. ما با معرفی مفهوم حداقل عاملیت (Least-Agency)، مفاهیم حداقل سطح دسترسی (Least-Privilege) و عاملیت بیش‌ از حد (Excessive Agency) رو گسترش میدیم. این مفهوم توصیه ما به سازمانها رو منعکس میکنه که از خودمختاری غیرضروری اجتناب کنن. چون بکارگیری رفتار عامل محور در جایی که نیازی به اون نیست، سطح حمله رو بدون افزودن ارزش، افزایش میده. بطور مشابه، مشاهده‌پذیری قوی غیرقابل‌ چشم‌پوشی است: بدون دید شفاف نسبت به اینکه عاملها چه کاری انجام میدن، چرا اون رو انجام میدن و از چه ابزارهایی استفاده میکنن، خودمختاری غیرضروری میتونه بصورت مخفی سطح حمله رو گسترش بده و مشکلات جزئی رو به شکستهای بزرگ تبدیل کنه.

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

بصورت کلی، OWASP Agentic Top 10 برای سال 2026، موارد زیر هستن:

• ASI01: Agent Goal Hijack
• ASI02: Tool Misuse & Exploitation
• ASI03: Identity & Privilege Abuse
• ASI04: Agentic Supply Chain Vulnerabilities
• ASI05: Unexpected Code Execution (RCE)
• ASI06: Memory & Context Poisoning
• ASI07: Insecure InterAgent Communication
• ASI08: Cascading Failures
• ASI09: HumanAgent Trust Exploitation
• ASI10: Rogue Agents

 

در ادامه نگاهی به هر یک از این تهدیدات میندازیم.

 

 

ASI01: Agent Goal Hijack

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

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

از آنجا که عاملها به ورودی‌های زبان طبیعیِ بدون نوع و منطق هماهنگ کننده با حاکمیت ضعیف، متکی هستن، نمیتونن بطور قابل‌ اعتماد دستورالعملهای مشروع رو از محتوای تحت کنترل مهاجم تشخیص بدن. برخلاف LLM01:2025 که بر تغییر پاسخ یک مدل منفرد تمرکز داره، ASI01 اثرات گسترده‌تر عامل محور رو پوشش میده. جاییکه ورودیهای دستکاری‌ شده اهداف، برنامه‌ریزی (در صورت استفاده) و رفتار چندمرحله‌ای رو منحرف میکنن.

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

ASI01 با موارد T06:Goal Manipulation و T07: Misaligned & Deceptive Behaviors در OWASP Agentic AI Threats & Mitigations Guide متناظر است. این موارد نشان میده چطوری مهاجم میتونه اهداف و منطق انتخاب عمل عامل رو تضعیف کرده و خودمختاری اون رو به سمت نتایج ناخواسته یا مخرب هدایت کنه.

 

نمونه‌های رایج از این آسیب‌پذیری:

• تزریق غیرمستقیم پرامپت از طریق پیلودهای دستورالعمل مخفی در صفحات وب یا اسناد، در سناریوهای RAG، که بطور بی‌صدا عامل رو به نشت داده‌های حساس یا سوءاستفاده از ابزارهای متصل هدایت میکنه.
• تزریق غیرمستقیم پرامپت از کانالهای ارتباطی خارجی (مانند ایمیل، تقویم، Teams) که از خارج سازمان ارسال شده و قابلیت ارتباط داخلی عامل رو بدست میاره و پیامهای غیرمجاز رو با هویت مورد اعتماد ارسال میکنه.
• لغو/بازنویسی مخرب پرامپت که یک ایجنت مالی رو وادار میکنه پول رو به حساب مهاجم منتقل کنه.
• تزریق غیرمستقیم پرامپت که دستورالعملهای عامل رو بازنویسی کرده و اون رو به تولید اطلاعات جعلی با اثرگذاری بر تصمیمات کسب‌وکار سوق میده.

 

سناریوهای نمونه حمله:

• EchoLeak: تزریق غیرمستقیم پرامپت بصورت Zero-Click: مهاجم ایمیلی دستکاری‌شده ارسال میکنه که بی‌سر و صدا Microsoft 365 Copilot رو به اجرای دستورالعملهای مخفی واداشته و بدون هیچ تعامل کاربری، ایمیلها، فایلها و لاگهای چت محرمانه رو نشت میده.
• تزریق پرامپت اپراتور از طریق محتوای وب: مهاجم محتوای مخرب رو در صفحه‌ی وب قرار میده که عامل اپراتور، اون رو پردازش میکنه (مثلا در جستجو یا RAG)، و عامل رو فریب میده تا از دستورالعملهای غیرمجاز پیروی کنه. بعدش عامل اپراتور به صفحات داخلیِ احراز هویت‌شده دسترسی یافته و داده‌های خصوصی کاربران رو افشا میکنه. نشان‌ دهنده اینکه عاملهای خودمختار با حفاظت سبک، چگونه میتونن از طریق تزریق پرامپت داده‌های حساس رو نشت بدن.
• انحراف تدریجی هدف از طریق پرامپتهای زمانبندی‌ شده: یک دعوت تقویم مخرب، بصورت تکرارشونده یک دستور مخفی رو تزریق میکنه که هر روز صبح، بدون جلب توجه، اولویتها و وزن دهی اهداف عامل رو کمی تغییر میده. در نتیجه، برنامه‌ریز (Planner) به‌ تدریج به سمت تأییدهای سریع سوق داده میشه، در حالیکه تمام اقدامات همچنان ظاهرا در چارچوب سیاستها و قوانین تعریف‌ شده باقی میمونن.
• حمله Inception علیه کاربران ChatGPT: یک Google Doc مخرب، دستورالعمل‌هایی برای نشت داده‌های کاربر به ChatGPT تزریق میکنه و کاربر رو متقاعد میکنه، تصمیم تجاری نادرستی بگیره.

 

راهنماهای پیشگیری و کاهش ریسک:

1. تمام ورودیهای زبان طبیعی (مانند متن کاربر، اسناد بارگذاری‌ شده، محتوای بازیابی‌شده) رو غیرقابل‌ اعتماد تلقی کنید و پیش از اثرگذاری بر انتخاب هدف، برنامه‌ریزی یا فراخوانی ابزارها، اونارو از همان کنترلهای اعتبارسنجی ورودی و ضد تزریق پرامپتِ تعریف‌شده در LLM01:2025 عبور بدید.
2. با اعمال حداقل سطح دسترسی برای ابزارهای عامل و الزام تأیید انسانی برای اقدامات پراثر یا تغییر‌دهنده هدف، اثر تغییر هدف رو به حداقل برسونید.
3. پرامپتهای سیستمی عامل رو تعریف و قفل کنید، تا اولویتهای هدف و اقدامات مجاز شفاف و قابل ارزیابی باشن. هرگونه تغییر در اهداف یا تعریف پاداش باید از مدیریت پیکربندی و تأیید انسانی عبور کنه.
4. در زمان اجرا، قبل از اجرای اقدامات پراثر یا تغییر‌دهنده هدف، هم نیت کاربر و هم نیت عامل رو اعتبارسنجی کنید. هرگاه عامل اقداماتی رو پیشنهاد میده که از وظیفه یا دامنه اولیه متفاوت است، تأیید (از طریق انسان، موتور سیاست یا محافظتهای پلتفرم) رو الزامی کنید. در صورت هر تغییر هدف غیرمنتظره، اجرا رو متوقف یا مسدود کنید، انحراف رو برای بازبینی مشخص کنید و اون رو برای ارزیابی ثبت کنید.
5. هنگام ساخت عاملها، استفاده از الگوی نوظهور Intent Capsule رو ارزیابی کنید. الگویی که هدف اعلام‌شده، قیود و زمینه رو در هر چرخه اجرا در یک محدوده ی امضا شده مقید و استفاده در زمان اجرا رو محدود میکنه.
6. هر منبع داده متصل، از جمله ورودیهای RAG، ایمیلها، دعوتهای تقویم، فایلهای بارگذاری‌ شده، APIهای خارجی، خروجی وب و پیامهای عاملهای همتا رو، قبل از اثرگذاری بر اهداف یا اقدامات عامل، با استفاده از CDR، تشخیص حامل پرامپت و فیلتر محتوا پاکسازی و اعتبارسنجی کنید.
7. ثبت وقایع جامع و پایش مستمر فعالیت عامل رو حفظ کنید و یک خط مبنای رفتاری شامل وضعیت هدف، الگوهای استفاده از ابزار و ویژگیهای نامتغیر (مانند اسکیما و الگوهای دسترسی) ایجاد کنید. در صورت امکان، یک شناسه پایدار برای هدف فعال ردیابی کنید و بر هرگونه انحراف، مانند تغییرات غیرمنتظره هدف، توالیهای غیرعادی ابزار یا فاصله گرفتن از خط مبنا، هشدار دهید تا تغییر هدف غیرمجاز فورا در عملیات قابل مشاهده باشه.
8. آزمونهای دوره‌ای رد تیم با شبیه‌سازی بازنویسی/لغو هدف انجام بدید و اثربخشی بازگردانی (Rollback) رو راستی‌آزمایی کنید.
9. عاملهای هوش مصنوعی رو در برنامه تهدید داخلی (Insider Threat Program) موجود ادغام کنید تا هرگونه پرامپت داخلی با هدف دسترسی به داده‌های حساس یا تغییر رفتار عامل پایش بشه و در صورت فعالیتهای غیرعادی امکان بررسی فراهم باشه.

 

ASI02: Tool Misuse and Exploitation

عاملها ممکنِ بدلیل تزریق پرامپت، ناترازی، واگذاری ناامن یا دستورالعملهای مبهم، از ابزارهای کاملا معتبر به‌ درستی استفاده نکنن. موضوعی که میتونه به نشت داده، دستکاری خروجی ابزارها یا تغییر جریانهای کاری منجر بشه. این ریسکها از نحوه انتخاب و بکارگیری ابزار توسط عامل ناشی میشن. حافظه عامل، انتخاب پویای ابزار و واگذاری وظایف میتونن با زنجیره‌سازی، افزایش سطح دسترسی و اقدامات ناخواسته، سوء‌استفاده رو تشدید کنن. این مورد با LLM06:2025 (Excessive Agency) مرتبطِ، با این تفاوت که تمرکز اینجا روی سوء‌استفاده از ابزارهای مشروعه، نه صرفا خودمختاری بیش‌ از حد مدل.

این مورد سناریوهایی رو پوشش میده که در اونها، عامل در چارچوب مجوزهای مجاز خودش عمل میکنه، اما یک ابزار قانونی رو به‌ شکلی ناامن یا غیرمنتظره بکار میگیره، برای مثال حذف داده‌های ارزشمند، فراخوانی بیش‌ازحد APIهای پرهزینه، یا نشت اطلاعات. اگه سوء‌استفاده شامل افزایش سطح دسترسی یا به‌ارث‌بردن اعتبارنامه‌ها باشه، ذیل ASI03 قرار میگیره. اگر به اجرای کد دلخواه یا تزریق‌ شده منجر بشه، در ASI05 طبقه‌بندی میشه. همچنین با گسترش تعریف ابزارها از طریق سرورهای MCP، همپوشانی طبیعی با ASI04 ایجاد میشه. اگر اطلاعاتی در خصوص MCP ندارید، میتونید ویدیوی “آشنایی با MCP همراه با مثالهایی از امنیت سایبری” رو مشاهده کنید.

این مورد با T2 Tool Misuse در OWASP Agentic AI Threats & Mitigations Guide متناظر و با AIVSS Core Risk: Agentic AI Tool Misuse همراستاست.

 

نمونه‌های رایج از آسیب‌پذیری

• دسترسی بیش‌ از حد به ابزار (مستقیم از طریق API ابزار یا از طریق پروتکلهای ارتباطی AI/عامل): ابزار خلاصه‌ساز ایمیل میتونه بدون تأیید، ایمیلی رو حذف یا ارسال کنه.
• دامنه دسترسی بیش از نیاز: ابزار Salesforce میتونه به همه رکوردها دسترسی داشته باشه، در حالیکه عامل فقط به شیء Opportunity نیاز داره.
• ارسال ورودی بدون اعتبارسنجی: عامل، خروجی نامطمئن مدل رو به Shell میفرسته (مثلا / rm -rf) یا از ابزار مدیریت دیتابیس برای حذف دیتابیس یا رکوردها سوء‌استفاده میکنه.
• مرور ناامن یا فراخوانی‌های وابسته: عامل لینکهای مخرب رو دنبال و بدافزاری رو دانلود میکنه یا پرامپتهای مخفی رو اجرا میکنه.
• تشدید بصورت حلقه‌ای (Loop Amplification): برنامه ریز (Planner) بطور مکرر APIهای پرهزینه رو صدا میزنه و باعث DoS یا افزایش ناگهانی هزینه‌ها میشه.
• آلودگی ابزار داده‌های خارجی: محتوای مخرب شخص ثالث، عامل رو به اقدامات ناامن با ابزارها هدایت میکنه.

 

سناریوهای نمونه حمله

• مسموم‌سازی ابزار (Tool Poisoning): مهاجم رابط ابزار، مانند توصیف‌گرها، اسکیماها، متادیتا یا اطلاعات مسیریابی (مثلا در MCP)، رو دستکاری میکنه تا عامل بر اساس قابلیتهای جعلی یا مخرب، ابزار رو فراخوانی کنه. این حالت ذیل ASI02 قرار میگیره، چون ابزار ذاتا معتبره و دستکاری در زمان اجرا رخ میده، فقط مواردی که خود ابزار در مبدأ مخرب یا آلوده باشه، در ASI04 قرار میگیره. برخلاف مسموم‌سازی ورودی که زبان طبیعی/داده رو هدف میگیره، اینجا لایه ابزار آلوده میشه.
• تزریق غیرمستقیم (Tool Pivot): مهاجم دستوراتی رو در یک PDF جاسازی میکنه (cleanup.sh رو اجرا کن و لاگها رو به X بفرست). عامل اطاعت کرده و Shell رو فراخوانی میکنه.
• API با دسترسی بیش‌ از حد: ربات پشتیبانی که برای خواندن تاریخچه سفارشات طراحی شده، به‌ دلیل دسترسی کامل به ابزار مالی، اقدام به بازپرداخت وجه میکنه.
• زنجیره‌سازی ابزارهای داخلی و خارجی: عامل فریب میخوره تا یک ابزار CRM داخلیِ امن رو با ابزار ایمیل خارجی زنجیره کنه و لیست حساس مشتریان رو برای مهاجم ارسال کنه.
• جعل نام ابزار (Typosquatting): ابزار مخربی با نام report قبل از report_finance  اجرا میشه و باعث مسیر‌دهی اشتباه و افشای ناخواسته داده میشه.
• دور زدن EDR با زنجیره‌سازی ابزار: عاملِ اتوماسیون امنیتی، با دستور تزریق‌شده، ابزارهای مدیریتی معتبر (PowerShell، cURL و APIهای داخلی) رو زنجیره میکنه و لاگهای حساس رو خارج میکنه. چون همه دستورات با باینریهای مورد اعتماد و اعتبارنامه‌های معتبر اجرا میشن، EDR/XDR، بدافزار یا اکسپلویتی نمی بینه و سوء‌استفاده شناسایی نمیشه.
• سوء‌استفاده از ابزارهای تأییدشده: عامل کدنویسی، مجموعه‌ای از ابزارهای کم‌ ریسک و خود اجرا داره (مثلا ping). مهاجم عامل رو وادار میکنه ping رو بصورت مکرر اجرا کنه و داده رو از طریق کوئری‌های DNS نشت بده.

 

راهنماهای پیشگیری و کاهش ریسک:

نکته: ASI02 بر اقدامات کاهشی LLM06:2025 بنا میشه و اونارو به جریانهای کاری چندمرحله‌ای و هماهنگ کننده های ابزارها در عاملها گسترش میده. LLM06 بر خودمختاری در سطح مدل تمرکز داره؛ ASI02 بر سوء‌استفاده از ابزارهای معتبر در طرحها و زنجیره‌های واگذاری عاملها.

1. حداقل اختیار و حداقل دسترسی برای ابزارها: به هر ابزار فقط همان‌ قدری دسترسی بدید که واقعا لازم داره، نه بیشتر. مثلا ابزار دیتابیس، فقط اجازه خوندن داره، ابزار خلاصه‌سازی ایمیل، اجازه حذف یا ارسال رو نداشته باشه، API، فقط عملیات ضروری رو انجام بده نه همه چیز. دسترسیها رو از قبل و بصورت رسمی تعریف کنید، نه سلیقه‌ای و موردی.
2. تأیید برای کارهای حساس: هر بار که عامل میخواد کاری مهم یا خطرناک انجام بده (مثلا حذف، انتقال پول، انتشار اطلاعات) یا از انسان تأیید بگیره یا حداقل قبلش نشون بده دقیقاً چه کاری میخواد انجام بده.
3. اجرای امن ابزارها: ابزارها یا کدها رو در یک محیط ایزوله و جدا اجرا کنید، نه مستقیم روی سیستم اصلی. همچنین فقط اجازه ارتباط با آدرسهای مشخص رو بدید هر ارتباط ناشناخته یا غیرمجاز رو ببندید.
4. دروازه تصمیم‌گیری قبل از اجرا (Intent Gate): به خروجی عامل یا مدل اعتماد کامل نکنید. قبل از اجرا بررسی کنید: نیتش چیه، ورودیها و پارامترها منطقی‌ هستن یا نه، محدودیت‌ها (تعداد، سرعت، نوع درخواست) رعایت شده یا نه. اگه دیدید هدف عوض شده یا رفتار مشکوکه، جلو اجرا رو بگیرید یا اون رو ثبت و بررسی کنید.
5. محدود کردن مصرف ابزار: برای هر ابزار سقف مصرف بذارید: سقف هزینه، سقف تعداد درخواست، سقف استفاده زمانی. اگه عاملی از حد گذشت، بطور خودکار متوقف یا محدود کنید.
6. دسترسی موقتی (نه دائمی): به عامل کلید یا توکن دائمی ندید و دسترسیها فقط برای همان لحظه معتبر باشن. بعد از انجام کار دسترسی رو فورا باطل کنید، این کار جلوی سوء‌استفاده بعدی رو میگیره.
7. بررسی معنی دستورات، نه فقط شکلشان (Semantic Firewalls): فقط نگاه نکنید دستور درست نوشته شده. بررسی کنید واقعاً معنی‌اش همان چیزیِ که انتظار دارید. مثلا: ابزار درست انتخاب شده؟ نسخه درسته؟ اسم ابزار شبیه ابزار اصلی نیست ولی جعلیه؟ اگه ابهام داشت اجرا نکنید یا از کاربر سؤال کنید.
8. لاگ‌گیری و زیر نظر داشتن رفتار عامل: همه کارهای عامل رو ثبت کنید: چه ابزاری رو صدا زد، با چه پارامترهایی، چند بار و در چه زمانی. بصورت دائم، رفتار غیرعادی، استفاده زیاد یا عجیب از ابزارها، زنجیره‌های مشکوک (مثلا خواندن دیتابیس و ارسال به بیرون) رو بررسی کنید.

 

ASI03: Identity and Privilege Abuse

سوءاستفاده از هویت و سطح دسترسی، وقتی اتفاق می‌افته که مهاجم از اعتماد و واگذاری دسترسی داینامیک در عاملها سوء استفاده میکنه تا سطح دسترسی خودش رو بالا ببره، محدودیتها رو دور بزنه و کارهای غیرمجاز انجام بده. این کار با دستکاری زنجیره‌های واگذاری، ارث‌بری نقشها، جریانهای کنترلی و زمینه ی (Context) عامل انجام میشه. منظور از زمینه، اطلاعات ذخیره‌ شده مثل اعتبارنامه‌ها یا تاریخچه مکالمات بین سیستمهاست.

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

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

این مورد، نسخه عامل محور Excessive Agency (LLM06:2025) است و معمولاً با تزریق پرامپت (LLM01:2025) ترکیب میشه. به دلیل مجوزهای عامل، یکپارچگی ابزارها و سیستمهای چندعاملی، تأثیر اون میتونه حتی از افشای اطلاعات حساس (LLM02:2025) فراتر بره و محرمانگی، تمامیت و دسترسی سیستمها و داده‌ها رو تهدید کنه.

در OWASP ASI Threats and Mitigations، این مورد با T3: Privilege Compromise مطابقت داره و با OWASP AIVSS با Core Risk 2: Agent Access Control Violation متناظر است.

 

نمونه‌های رایج آسیب‌پذیری

• ارث‌بری دسترسی، بدون محدودیت: وقتی مدیر با دسترسی بالا، وظایف رو به عامل دیگه ای واگذار میکنه، اما حداقل دسترسی اعمال نمیکنه، عامل دسترسی بیش از حد پیدا میکنه. همین‌ طور، عاملهای Low یا no-code با دسترسی پیش‌فرض (مثل اینترنت نامحدود) اغلب قدرت بیشتری از حد لازم پیدا میکنن.
• حفظ دسترسی در حافظه و نشت داده: عاملها ممکنِ اعتبارنامه‌ها، کلیدها یا داده‌ها رو در حافظه نگه دارن تا دوباره استفاده کنن. اگه حافظه بین وظایف یا کاربران جدا نشه، مهاجم میتونه عامل رو وادار کنه تا از اطلاعات ذخیره‌ شده استفاده کرده، دسترسی‌ها رو افزایش داده یا داده‌های امن رو به محیط ضعیف‌تر منتقل کنه.
• سوءاستفاده از اعتماد بین عاملها (Confused Deputy): در سیستمهای چند عاملی، عاملها بطور پیش‌فرض به درخواستهای داخلی اعتماد میکنن. یک عامل با دسترسی کم که آلوده شده، میتونه دستوراتی معتبر به عامل با دسترسی بالا بفرسته و اون بدون بررسی قصد اصلی کاربر، از مجوزهای بالای خودش سوءاستفاده کنه.
• مشکل زمان بررسی تا زمان استفاده (TOCTOU): ممکن مجوزها در ابتدای جریان کاری بررسی بشن اما قبل از اجرا تغییر کنن یا منقضی بشن. عامل ممکن با مجوز قدیمی اقدام کنه و کاری انجام بده که کاربر دیگه، اجازه اون رو نداره.
• تزریق هویت مصنوعی (Synthetic Identity Injection): مهاجم با جعل هویت داخلی (مثل Admin Helper) میتونه اعتماد ارثی بگیره و اقدامات با سطح دسترسی بالا رو انجام بده.

 

سناریوهای نمونه حمله

• سوءاستفاده از دسترسی واگذار شده: عامل مالی وظایف رو به یک عامل DB Query واگذار میکنه و تمام مجوزها رو هم منتقل میکنه. مهاجم با هدایت پرس‌وجو، از دسترسی به ارث رسیده برای نشت داده‌های HR و حقوقی استفاده میکنه.
• افزایش دسترسی مبتنی بر حافظه: عامل مدیر IT، اعتبارنامه SSH رو ذخیره میکنه. بعد یک کاربر غیرمدیر همان نشست رو دوباره استفاده میکنه و عامل رو وادار میکنه از اون اعتبارنامه برای ایجاد حساب غیرمجاز استفاده کنه.
• سوءاستفاده از اعتماد بین عاملها: ایمیلی از IT باعث میشه عامل مرتب‌ کننده ایمیل، عامل مالی رو وادار به انتقال پول به حساب خاصی کنه. عامل مالی، به عامل داخلی اعتماد کرده و بدون بررسی، پرداخت جعلی رو انجام میده.
• فیشینگ کد دستگاه بین عاملها: مهاجم لینک کد-دستگاه رو به عامل مرورگر میده؛ عامل کمکی دیگه ای، کد رو تکمیل کرده و حساب قربانی رو به محدوده‌ (tenant) مهاجم متصل میکنه.
• انحراف مجوز جریان کاری: عامل خرید، مجوز رو در شروع خرید بررسی میکنه. چند ساعت بعد، محدودیت هزینه کاربر کاهش پیدا میکنه، اما جریان کاری با همان توکن قدیمی ادامه پیدا کرده و تراکنش غیرمجاز انجام میشه.
• شخصیت عامل جعلی: مهاجم یک عامل جعلی Admin Helper در رجیستری Agent2Agent داخلی ثبت میکنه. سایر عاملها به اون اعتماد کرده و کارهای حساس رو به اون میسپارن. عامل تحت کنترل مهاجم، دستورات سطح سیستمی صادر میکنه.
• به اشتراک‌گذاری هویت: عامل به نمایندگی از یک کاربر (مثلا سازنده خود) به سیستمها دسترسی پیدا میکنه و بعدش اجازه میده کاربران دیگه بطور ضمنی از اون هویت استفاده کنن و ابزارها رو به نام اون هویت فراخوانی کنن.

 

راهنمای پیشگیری و کاهش ریسک

1. دسترسی کوتاه‌مدت و محدود به وظایف خاص: به عاملها فقط اجازه بدید برای همان وظیفه و زمان مشخص کاری، انجام بدن. از توکن‌ها یا گواهیهای کوتاه‌مدت استفاده کنید. این کار جلوی سوءاستفاده از دسترسی‌ها، حملات از طریق واگذاری نادرست و بالا بردن دسترسی ناخواسته رو میگیره.
2. جدا کردن هویت و حافظه عاملها: هر عامل در یک محیط جدا (sandbox) اجرا بشه و حافظه بین وظایف پاک بشه. این کار جلوی استفاده دوباره از داده‌ها یا دسترسیها و نشت اطلاعات بین سیستم‌ها رو می‌گیره.
3. تأیید هر اقدام مهم: هر بار که عامل میخواد کاری با دسترسی بالا انجام بده، بطور مرکزی بررسی و تأیید بشه. این کار جلوی سوءاستفاده از اعتماد بین عاملها و بالا بردن دسترسی غیرمجاز رو می‌گیره.
4. نظارت انسانی برای اقدامات حساس: برای کارهای با دسترسی زیاد یا برگشت‌ناپذیر، تأیید انسان لازم باشه. این کار امنیت اضافه ایجاد میکنه و جلوی سوءاستفاده از حافظه یا اعتماد بین عاملها رو می‌گیره.
5. مشخص کردن هدف و محدودیت توکن‌ها: توکن‌ها باید با هدف مشخص امضا بشن: چه کسی، برای چه کاری و چه مدت. اگه عامل سعی کنه، از توکن در جای اشتباه استفاده کنه، سیستم اون رو رد کنه.
6. استفاده از پلتفرمهای مدیریت هویت عاملها: برخی پلتفرم‌ها، عاملها رو بعنوان هویت‌های غیرانسانی با دسترسی محدود، ثبت فعالیتها و کنترل چرخه عمر مدیریت میکنن . مثلا: Microsoft Entra، AWS Bedrock Agents، Salesforce Agentforce، Workday ASOR و مشابه اونها.
7. بستن دسترسی‌ها به کاربر، هدف، منبع و زمان: هنگام تغییر وظیفه یا زمینه، احراز هویت مجدد لازم است. دسترسی‌ها بین عاملها، فقط زمانی منتقل میشه که هدف اصلی، دوباره تأیید بشه. در حالت بلااستفاده یا رفتار مشکوک، دسترسی خودکار لغو بشه.
8. تشخیص دسترسی‌های واگذار شده یا غیرمستقیم: مراقب باشید عاملها از طریق واگذاریها، دسترسی‌های بالاتر دریافت نکنن. اگه عامل با دسترسی پایین، ناگهان دسترسی بالا بگیره، هشدار بدید.
9. تشخیص افزایش دسترسی غیرعادی و حملات فیشینگ بین عاملها: هرگاه عاملها سعی کنن دسترسی‌های جدید بگیرن یا توکن‌ها رو خارج از هدف اصلی استفاده کنن، زیر نظر گرفته بشن.

 

ASI04: Agentic Supply Chain Vulnerabilities

آسیب‌پذیریهای زنجیره تأمین عاملها، زمانی ایجاد میشن که عاملها، ابزارها یا اجزایی که با اونا کار میکنن از منابع شخص ثالث تأمین بشن و این منابع مخرب، دستکاری‌ شده یا در مسیر انتقال آلوده شده باشن. این اجزا میتونن استاتیک یا داینامیک باشن، از جمله: مدلها و وزنهای مدل، ابزارها و پلاگینها، دیتاست‌ها، عاملهای دیگه، رابطهای عامل مثل MCP (Model Context Protocol) و A2A (Agent-to-Agent)، رجیستری‌های عاملها، کانالهای بروزرسانی و سایر موارد. این وابستگی‌ها ممکنِ کد ناامن، دستورات مخفی یا رفتارهای فریبنده رو وارد زنجیره اجرای عامل کنن.

در OWASP، مبحث زنجیره تأمین بصورت مفصل در LLM03:2025 (Supply Chain Vulnerabilities) بررسی شده، اما تمرکز اون بیشتر روی وابستگی‌های استاتیک است. در مقابل، اکوسیستم‌های عاملی معمولا قابلیتها رو در زمان اجرا (Runtime) کنار هم قرار میدن، مانند: بارگذاری ابزارهای خارجی در لحظه، تغییر یا انتخاب پویا‌ی شخصیت (Persona) عاملها. این موضوع سطح حمله رو بطور قابل‌توجهی افزایش میده.

همکاری توزیع‌شده در زمان اجرا، در کنار خودمختاری عاملها، باعث ایجاد یک زنجیره تأمین زنده میشه که در آن یک آسیب‌پذیری میتونه بصورت دومینویی بین عاملها گسترش پیدا کنه. در نتیجه، تمرکز امنیت از بررسی فایلها و Manifestها به سمت امنیت زمان اجرا برای اجزایی متنوع و اغلب غیرشفاف منتقل میشه. مقابله با این تهدید نیازمنده، ابزارهای دقیق در زمان توسعه و هماهنگی امن در زمان اجراست. جاییکه اجزا بصورت داینامیک بارگذاری، به اشتراک گذاشته و مورد اعتماد قرار میگیرن. این ریسک به T17: Supply Chain Compromise در Agentic Threats and Mitigations نگاشت میشه. همچنین با موارد زیر مرتبط است:

• T2: Tool Misuse
• T11: Unexpected RCE and Code Attacks
• T12: Agent Communication Poisoning
• T13: Rogue Agent
• T16:Insecure Inter-Agent Protocol Abuse

 

نمونه‌های رایج از این آسیب‌پذیری

• پرامپتهای مسموم بارگذاری‌شده از راه دور: عامل بصورت خودکار قالب‌های پرامپت رو از یک منبع خارجی دریافت میکنه که شامل دستورات مخفی هستن (مثلا استخراج اطلاعات یا انجام عملیات مخرب)، بدون اینکه توسعه‌دهنده چنین نیتی داشته باشه.
• تزریق در توصیف ابزار (Tool Descriptor Injection): مهاجم دستورات مخفی یا پیلود مخرب رو داخل متادیتا، MCP یا agent-card ابزار قرار میده و عامل میزبان اون رو بعنوان راهنمای معتبر اجرا میکنه.
• جعل هویت و Typosquatting: هنگام کشف یا اتصال داینامیک به ابزارها یا سرویس‌های خارجی، یک سرویس با نام مشابه، عامل رو فریب میده یا یک سرویس مخرب عمدا خودش رو بجای ابزار یا عامل معتبر جا میزنه و با تقلید API و رفتار، اعتماد سیستم رو جلب میکنه.
• عامل شخص ثالث آسیب‌پذیر (Agent → Agent): یک عامل خارجی با تنظیمات ناامن یا آسیب‌پذیری وصله‌نشده وارد یک سیستم چندعاملی میشه و بعنوان نقطه pivot برای نشت داده یا انتقال دستورات مخرب استفاده میشه.
• سرور MCP یا رجیستری آلوده: یک سرور مدیریت عامل یا رجیستری که آلوده یا هک شده، Manifestها، پلاگین‌ها یا توصیف‌کننده‌های عامل رو با ظاهری معتبر ارائه میده. چون سیستم هماهنگ کننده به رجیستری اعتماد داره، این آلودگی میتونه در مقیاس بزرگ پخش بشه.
• پلاگین دانشی مسموم (Poisoned Knowledge Plugin): یک پلاگین محبوب RAG داده‌ها رو از ایندکسر شخص ثالثی می‌گیره که عمدا داده‌های دستکاری‌ شده در اون قرار داده شده‌. عامل به‌ مرور دچار سوگیری میشه و در استفاده عادی، اطلاعات حساس رو ناخواسته استخراج میکنه.

 

نمونه سناریوهای حمله

• نفوذ به زنجیره تأمین Amazon Q: یک پرامپت مسموم در مخزن Q برای VS Code قرار گرفت و در نسخه‌ی v1.84.0 قبل از شناسایی، برای هزاران کاربر منتشر شد. هرچند این حمله در نهایت ناموفق بود، اما نشان داد که دستکاری منطق عامل در لایه‌های بالادستی چگونه میتونه از طریق افزونه‌ها بصورت زنجیره‌ای گسترش پیدا کنه و اثر حمله رو چند برابر کنه.
• مسموم‌سازی توصیف ابزار MCP: یک محقق نشان داد که در MCP گیتهاب میتونه با تزریق پرامپت، دستورات مخرب رو داخل متادیتای یک ابزار عمومی مخفی کرد. زمانیکه این ابزار فراخوانی میشه، دستیار هوش مصنوعی بدون اطلاع کاربر، داده‌های مخزن خصوصی رو استخراج میکنه.
• سرور MCP مخرب با جعل هویت Postmark: بعنوان اولین سرور MCP مخرب مشاهده‌ شده در دنیای واقعی که در npm گزارش شد، این سرور خودش رو جای postmark-mcp معرفی میکرد و بصورت مخفیانه، تمام ایمیل‌ها رو برای مهاجم BCC میکرد.
• حمله Proxy به Prompt-Hub (AgentSmith): در این حمله، با پروکسی کردن پرامپت‌ها، داده‌ها استخراج شده و جریان پاسخ‌ها ربوده میشه. این کار باعث دستکاری هماهنگ کننده داینامیک در سیستمهای عامل محور میشه.
• پکیج آلوده‌ی NPM در گردش‌کار عاملها: یک پکیج آلوده در NPM (مثلا نسخه‌ی مسموم‌شده‌ی nx/debug) بصورت خودکار توسط عاملهای کدنویسی نصب شد. این پکیج یک بکدور مخفی ایجاد کرد که کلیدهای SSH و توکن‌های API رو استخراج میکرد و در نتیجه، نفوذ زنجیره تأمین رو در کل گردش‌کارهای عامل محور گسترش داد.
• حمله Agent-in-the-Middle از طریق Agent Card: یک عامل مخرب یا هک شده، در Agent Card خودش (مثلا /.well-known/agent.json) قابلیتهای اغراق‌شده‌ای تبلیغ میکنه. عاملهای میزبان اون رو برای انجام وظایف انتخاب میکنن و در نتیجه، درخواست‌ها و داده‌های حساس از طریق عامل تحت کنترل مهاجم عبور کرده و داده‌ها استخراج یا پاسخ‌ها دستکاری میشن.

 

راهنمای پیشگیری و کاهش ریسک

1. مشخص بودن منبع و لیست اجزای AI (Provenance، SBOM و AIBOM): تمام اجزای سیستم شامل مانيفست‌ها، پرامپت‌ها و تعریف ابزارها باید امضا و تأیید بشن. استفاده از SBOM (لیست اجزای نرم‌افزار) و AIBOM (لیست اجزای هوش مصنوعی) باید الزامی باشه و این لیست‌ها بصورت دوره‌ای بازبینی و تأیید بشن. همچنین لازم است فهرست کاملی از تمام اجزای AI نگهداری بشه، فقط از رجستری‌های معتبر و کنترل‌شده استفاده بشه و منابع نامطمئن مسدود بشن.
2. کنترل سخت‌گیرانه وابستگی‌ها: فقط وابستگی‌هایی که از قبل در لیست مجاز قرار گرفتن و نسخه اونا مشخص هستش، اجازه استفاده داشته باشن. باید از نظر پکیج‌های تقلبی یا Typosquatting در منابعی مانند PyPI، npm، LangChain و LlamaIndex اسکن انجام بشه. قبل از نصب یا فعالسازی هر وابستگی، منبع و اصالت اون بررسی بشه و هر ابزار یا پکیج بدون امضا یا تأیید معتبر، بصورت خودکار رد بشه.
3. ایزوله‌سازی عاملها و فرآیند Build عاملهای حساس: باید داخل کانتینرهای ایزوله اجرا بشن و دسترسی اونا به شبکه و فراخوانی‌های سیستمی (Syscall) به‌ شدت محدود باشه. همچنین فرآیند Build باید قابل تکرار و قابل بازتولید باشه تا هرگونه دستکاری شناسایی بشه.
4. ایمن‌سازی پرامپت‌ها و حافظه عامل پرامپت‌ها، اسکریپت‌های هماهنگ کننده و ساختار: حافظه عامل باید تحت کنترل نسخه (Version Control) باشن، قبل از اعمال تغییرات، بازبینی انسانی بشن، بصورت دوره‌ای برای شناسایی رفتار یا تغییرات غیرعادی اسکن بشن. پرامپت در عمل بخشی از منطق سیستم است و باید مثل کد با اون برخورد بشه.
5. امنیت ارتباط بین عاملها: ارتباط بین عاملها باید فقط با احراز هویت دوطرفه و تأیید هویت انجام بشه. این کار معمولا با PKI و mTLS پیاده‌سازی میشه. رجیستر آزاد عاملها نباید وجود داشته باشه و تمام پیامهای بین عاملها باید امضا و راستی‌آزمایی بشن.
6. اعتبارسنجی و پایش مداوم: در زمان اجرا، باید بصورت مداوم، امضاها، هش‌ها، SBOM و AIBOM دوباره بررسی بشن. همچنین رفتار عاملها، سطح دسترسی‌ها، زنجیره وابستگی‌ها و داده‌های تله‌متری بین ماژول‌ها باید پایش بشن تا هر رفتار غیرعادی سریعا شناسایی بشه.
7. مشخص کردن نسخه‌ها (Pinning): پرامپت‌ها، ابزارها و تنظیمات باید با هش محتوا و شناسه Commit مشخص بشن. انتشار تغییرات باید مرحله‌ای انجام بشه و در صورت مشاهده ی تغییر غیرمنتظره در هش یا تغییر رفتاری مشکوک سیستم باید بصورت خودکار به نسخه قبلی برگرده (Auto-Rollback).
8. کلید قطع اضطراری زنجیره تأمین (Supply Chain Kill Switch): باید مکانیزم قطع اضطراری وجود داشته باشه که در صورت شناسایی نفوذ یا آلودگی، بتونه بصورت فوری و سراسری، یک ابزار خاص، یک پرامپت یا ارتباط یک عامل رو در تمام محیطها، غیرفعال کنه تا از گسترش آسیب زنجیره‌ای جلوگیری بشه.
9. طراحی بر اساس مدل Zero Trust: سیستم باید از ابتدا با فرض اینکه یک LLM ممکنِ فریب بخوره یا یک عامل ممکنِ مورد سوءاستفاده قرار بگیره، طراحی بشه. در این مدل، هیچ جزءی بطور پیش‌فرض قابل اعتماد نیست و سیستم باید حتی در صورت شکست یا نفوذ یک مؤلفه، تحمل‌پذیر و ایمن باقی بمونه.

 

ASI05: Unexpected Code Execution (RCE)

سیستم‌های عامل محور، از جمله ابزارهای محبوب Vibe Coding، معمولا قادر به تولید و اجرای کد هستن. مهاجمان میتونن از قابلیت تولید کد یا دسترسی عامل به ابزارها سوءاستفاده کنن و این فرآیند رو به اجرای کد از راه دور (RCE)، سوءاستفاده محلی یا نفوذ به سیستم‌های داخلی تبدیل کنن. از آنجا که این کدها اغلب بصورت لحظه‌ای توسط خود عامل تولید میشن، ممکنِ از بسیاری از کنترلهای امنیتی سنتی عبور کنن. تزریق پرامپت، سوءاستفاده از ابزارها یا سریال‌سازی ناامن میتونه باعث بشه متن ساده به رفتاری اجرایی و ناخواسته تبدیل بشه. هرچند اجرای کد میتونه از همان رابط‌های ابزاری مطرح‌ شده در ASI02 انجام بشه، اما ASI05 روی اجرای غیرمنتظره یا خصمانه کد تمرکز داره، از جمله: اسکریپت‌ها، فایل‌های باینری، ماژول‌های JIT یا WASM، آبجکت‌های Deserialize‌ شده، موتورهای قالب (Template Engines)، اجرای کد در حافظه. این موارد میتونن منجر به تسلط بر میزبان یا کانتینر، ایجاد ماندگاری (Persistence) یا فرار از سندباکس بشن. پیامدهایی که نیازمند کنترل‌های امنیتی سطح میزبان و زمان اجرا هستن و با کنترل‌های معمول ابزارها پوشش داده نمیشن.

این ریسک ادامه و تکامل موارد LLM01:2025 Prompt Injection و LLM05:2025 Improper Output Handling در سیستم‌های عامل محور است. جاییکه بجای اجرای یک خروجی دستکاری‌ شده، زنجیره‌ای از فراخوانی ابزارهای ظاهرا مجاز در کنار هم قرار می‌گیرن و در نهایت منجر به اجرای کد میشن. این تهدید با T11:Unexpected RCE and Code Attacks در راهنمای Agentic AI :Threats and Mitigations v1.1 هم‌راستاست.

 

نمونه‌های رایج آسیب‌پذیری

• تزریق پرامپت که منجر به اجرای کد تعریف‌شده توسط مهاجم میشه.
• توهم کدنویسی (Code Hallucination) که کدهای مخرب یا قابل سوءاستفاده تولید میکنه.
• اجرای دستورات شل (Shell) از طریق پرامپت‌های بازتاب‌شده.
• فراخوانی ناامن توابع، Deserialize کردن آبجکت‌ها یا اجرای کد بدون اعتبارسنجی.
• استفاده از توابع eval بدون فیلتر در سیستم حافظه عامل که به محتوای غیرقابل اعتماد دسترسی دارن.
• نصب پکیج‌های تأییدنشده یا مخرب که هنگام نصب یا ایمپورت شدن، کد مخرب اجرا میکنن و فراتر از یک حمله زنجیره تأمین ساده عمل میکنن.

 

سناریوهای نمونه حمله

• اجرای کنترل‌ نشده در Replit Vibe Coding: در فرآیندهای خودکار vibe coding یا تعمیر خودکار، عامل بدون بررسی انسانی، دستورات نصب یا شل رو در محیط کاری خودش اجرا میکنه و باعث حذف یا بازنویسی داده‌های عملیاتی میشه.
• تزریق مستقیم دستور شل: مهاجم پرامپتی ارسال میکنه که داخل اون دستورات شل مخفی شدن و به‌ ظاهر شبیه دستور عادی هستن. عامل این ورودی رو پردازش کرده و دستورات مخفی رو اجرا میکنه که منجر به دسترسی غیرمجاز یا استخراج داده میشه. مثال:

 

 

• توهم کدنویسی همراه با بکدور: عامل توسعه که مأمور تولید پچ امنیتی است، کدی تولید میکنه که در ظاهر سالم به نظر میرسه اما یک بکدور مخفی در اون وجود داره. این موضوع میتونه ناشی از داده‌های آموزشی آلوده یا پرامپت‌های خصمانه باشه.
• Deserialize ناامن آبجکت‌ها: عامل یک آبجکت سریال‌ شده، شامل پیلود مخرب تولید میکنه. این آبجکت در بخش دیگه ای از سیستم بدون اعتبارسنجی Deserialize میشه و باعث اجرای کد در محیط مقصد میشه.
• سوءاستفاده از زنجیره چندابزاری: مهاجم پرامپتی طراحی میکنه که عامل رو وادار میکنه مجموعه‌ای از ابزارها رو پشت سر هم اجرا کنه (آپلود فایل ← Path Traversal ← بارگذاری پویای کد) و در نهایت اجرای کد از طریق این زنجیره انجام میشه.
• RCE از طریق سیستم حافظه عامل: مهاجم با قراردادن کد اجرایی داخل پرامپت، از تابع eval ناامن در سیستم حافظه عامل سوءاستفاده میکنه. چون ورودی پاک‌سازی نشده، کد مستقیما اجرا میشه.
• RCE تولیدشده توسط خود عامل: عاملی که قصد وصله‌کردن یک سرور رو داره، فریب میخوره و یک پکیج آسیب‌پذیر رو دانلود و اجرا میکنه. مهاجم بعدش از این پکیج برای گرفتن Reverse Shell در محیط عملیاتی استفاده میکنه.
• مسموم‌سازی Lockfile وابستگی‌ها در Sandboxهای موقت: عامل هنگام انجام وظایف “رفع خطای بیلد”، Lockfile رو از مشخصات نامشخص، دوباره تولید میکنه و بصورت ناخواسته یک نسخه فرعی آلوده رو دانلود میکنه که دارای بکدور است.

 

راهکارهای پیشگیری و کاهش ریسک

1. استفاده از راهکارهای LLM05:2025 Improper Output Handling: ورودی‌ها رو اعتبارسنجی و خروجی‌ها رو کدگذاری کنید تا کدی که توسط عامل هوش مصنوعی تولید میشه، قبل از اجرا، پاکسازی و ایمن‌سازی بشه.
2. جلوگیری از اتصال مستقیم عاملها به سیستم‌های عملیاتی: اجازه ندید عاملها مستقیما روی سیستمهای واقعی اجرا بشن. استفاده از ابزارهای vibe coding باید فقط بعد از بررسیهای قبل از انتشار (Pre-production) انجام بشه، شامل: ارزیابیهای امنیتی، تست‌های واحد با سناریوهای مهاجمانه (Adversarial Unit Tests)، شناسایی مکانیزمهای ناامن ارزیابی حافظه (Unsafe Memory Evaluators)
3. ممنوعیت استفاده از eval در عامل‌های تولیدی (Production Agents): در محیط عملیاتی بطور کامل استفاده از eval رو ممنوع کنید. بجای آن از مفسرهای امن استفاده کرده و روی کد تولیدشده، ردیابی آلودگی داده (Taint Tracking) اعمال کنید.
4. ایمن‌سازی محیط اجرای کد: هرگز کد رو با دسترسی root اجرا نکنید. اجرای کد باید در کانتینرهای ایزوله با محدودیتهای سخت‌گیرانه انجام بشه، بویژه در دسترسی شبکه. بسته‌های آسیب‌پذیر شناخته‌ شده رو شناسایی و مسدود کنید. از sandboxهای سطح فریمورک مثل mcp-run-python استفاده کنید. در صورت امکان، دسترسی فایل سیستم رو فقط به یک دایرکتوری کاری محدود کنید و تغییرات فایل‌ها (diff) در مسیرهای حساس رو، لاگ کنید.
5. طراحی معماری امن: برای هر نشست محیط جداگانه با مرزهای مجوز مشخص ایجاد کنید. اصل حداقل دسترسی رو رعایت کنید. ایمن‌سازی پیش‌فرض در برابر خرابی داشته باشید. فرآیند تولید کد رو از اجرای کد جدا کرده و بین اونا مرحله تأیید و اعتبارسنجی قرار بدید.
6. کنترل دسترسی و تأیید انسانی: اجرای عملیاتهای سطح بالا باید نیازمند تأیید انسانی باشه. لیستی از دستورات مجاز برای اجرای خودکار (Allowlist) نگه دارید و اونارو تحت کنترل نسخه قرار بدید. کنترل‌ها رو بر اساس نقش (Role-based) و نوع عمل (Action-based) اعمال کنید.
7. تحلیل و پایش کد: قبل از اجرا، کدها رو با ابزارهای آنالیز استاتیک (Static Analysis) بررسی کنید. پایش در زمان اجرا (Runtime Monitoring) رو فعال کنید. الگوهای تزریق پرامپت رو زیر نظر داشته باشید. تمام مراحل تولید و اجرای کد رو لاگ کرده و امکان ارزیابی رو فراهم کنید.

 

ASI06: Memory & Context Poisoning

سیستم‌های عامل‌محور برای انجام وظایف و استدلال، به اطلاعات ذخیره‌ شده و قابل‌ بازیابی تکیه میکنن. این اطلاعات میتونه شامل تاریخچه مکالمات، ابزارهای حافظه، یا زمینه ی توسعه‌یافته باشه که باعث تداوم رفتار عامل در طول وظایف و چرخه‌های استدلال میشه. منظور از زمینه (Context) هر نوع اطلاعاتی است که عامل اون رو ذخیره، بازیابی یا دوباره استفاده میکنه، مانند خلاصه‌ها، امبدینگ‌ها (Embeddings) و مخازن RAG. این تعریف شامل پرامپت‌های یکباره نمیشه که در LLM01:2025 Prompt Injection بررسی شدن.

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

این ریسک با ASI01 تفاوت داره که تمرکزش روی دستکاری مستقیم هدف است و همچنین با ASI08 که به پیامدهای بعد از مسموم‌سازی می‌ پردازه. با این حال، مسموم‌سازی حافظه اغلب در نهایت منجر به ASI01 میشه، چون حافظه یا زمینه آلوده میتونه تفسیر هدف، مسیر استدلال یا منطق انتخاب ابزار رو تغییر بده. این ضعف بر پایه مفاهیم زیر است:

• LLM01:2025 Prompt Injection
• LLM04:2025 Data and Model Poisoning
• LLM08:2025 Vector and Embedding Weaknesses

اما تمرکز اصلی اون روی آلودگی مداوم حافظه عامل و زمینه های قابل‌بازیابی است که بین نشست‌ها منتقل میشه و استدلال خودکار عامل رو تغییر میده. این مورد با T1: Memory Poisoning در Agentic Threats and Mitigations تطابق داره و اثرات مرتبط اون شامل:

• T4: Memory Overload
• T6: Broken Goals
• T12: Shared Memory Poisoning

در سیستم امتیازدهی AIVSS هم، فیلدهای Memory Use و Contextual Awareness باعث افزایش امتیاز آسیب‌پذیری عامل میشن.

 

نمونه‌های رایج از این آسیب‌پذیری

• مسموم‌سازی RAG و امبدینگ‌ها: داده‌های مخرب یا دستکاری‌ شده از طریق منابع آلوده، آپلود مستقیم یا پایپ‌لاین‌های بیش‌ازحد مورد اعتماد، وارد دیتابیس برداری (Vector DB) میشن و باعث پاسخ‌های نادرست یا هدفمند میشن.
• مسموم‌سازی زمینه مشترک کاربران: زمینه های مشترک یا قابل‌استفاده مجدد به مهاجم اجازه میدن از طریق چت‌های عادی، داده تزریق کنه و نشست‌های بعدی رو تحت تأثیر قرار بده؛ نتیجه میتونه اطلاعات غلط، اجرای کد ناامن یا استفاده اشتباه از ابزارها باشه.
• دستکاری پنجره زمینه: مهاجم محتوای دستکاری شده‌ای رو وارد مکالمه یا تسک جاری میکنه که بعدا خلاصه شده یا در حافظه ذخیره میشه و حتی بعد از پایان نشست، تصمیم‌گیری‌های آینده رو آلوده میکنه.
• انحراف تدریجی حافظه بلندمدت: قرار گرفتن تدریجی در معرض داده‌های کمی آلوده، خلاصه‌های نادرست یا بازخورد عامل‌های دیگه، به‌ مرور دانش ذخیره‌شده یا اولویت اهداف رو تغییر میده و باعث انحراف رفتاری یا سیاستی میشه.
• ناهماهنگی سیستمی و بکدورهای مخفی: حافظه مسموم‌شده میتونه شخصیت مدل رو تغییر بده و بکدورهایی مبتنی بر تریگر (trigger-based) ایجاد کنه که دستورات مخفی مثله اجرای کد مخرب یا نشت داده رو فعال میکنن.
• انتشار آلودگی بین عاملها: زمینه یا حافظه آلوده بین عاملهای همکار پخش میشه و باعث تشدید آلودگی، نشت طولانی‌مدت داده یا انحراف هماهنگ در رفتار میشه.

 

سناریوهای نمونه حمله

• مسموم‌سازی حافظه در رزرو سفر: مهاجم قیمت جعلی یک پرواز رو بارها تکرار و تایید میکنه، دستیار اون رو بعنوان حقیقت ذخیره میکنه و بعدا رزرو رو با همان قیمت انجام میده و حتی بررسی پرداخت رو دور میزنه.
• سوءاستفاده از پنجره زمینه: مهاجم درخواست‌ها رو در چند نشست جدا پخش میکنه تا عدم تاییدهای قبلی از زمینه حذف بشه و در نهایت هوش مصنوعی مجوزهای بالاتری تا سطح ادمین صادر کنه.
• مسموم‌سازی حافظه یک سیستم امنیتی: مهاجم حافظه یک AI امنیتی رو طوری آموزش میده که فعالیتهای مخرب رو عادی تشخیص بده و حملات، بدون شناسایی عبور کنن.
• مسموم‌سازی حافظه مشترک: مهاجم سیاست‌های جعلی بازپرداخت رو وارد حافظه مشترک میکنه، سایر عاملها از اون استفاده میکنن و کسب‌وکار دچار تصمیم‌های اشتباه، ضرر مالی و اختلاف میشه.
• نشت برداری بین محدوده ها (Cross-tenant Vector Bleed): محتوای تقریبا مشابه که توسط مهاجم گنجانده شده، به‌دلیل فیلتر ضعیف فضای نام، باعث میشه داده حساس یک tenant دیگه، به‌ اشتباه بازیابی بشه.
• مسموم‌سازی حافظه دستیار کاربر: مهاجم از طریق Indirect Prompt Injection حافظه دستیار کاربر رو آلوده میکنه و نشست فعلی و نشست‌های آینده کاربر رو به خطر میندازه.

 

راهکارها و توصیه‌های پیشگیری و کاهش ریسک

1. حفاظت پایه‌ای از داده‌ها: داده‌ها هم هنگام انتقال و هم هنگام ذخیره باید رمزگذاری بشن و دسترسی‌ها بر اساس اصل کمترین امتیاز محدود بشن.
2. اعتبارسنجی محتوا: قبل از ذخیره یا ثبت هر داده‌ای در حافظه یا خروجی مدل، اونارو با قوانین و هوش مصنوعی بررسی کنید تا محتوای مخرب یا حساس شناسایی بشه.
3. جداسازی حافظه: نشست‌های کاربران و زمینه های مختلف باید از هم جدا بشن تا اطلاعات و دانش حساس بین اونا نشت نکنه.
4. کنترل دسترسی و نگهداری داده‌ها: فقط منابع معتبر و احراز هویت‌شده مجاز به دسترسی باشن. دسترسی‌ها بر اساس زمینه هر وظیفه اعمال بشه. داده‌ها تا حد امکان کمتر نگهداری بشن و حساسیت داده‌ها تعیین‌کننده مدت نگهداری باشه.
5. اعتبار منبع و شناسایی ناهنجاری‌ها: هر داده باید منبعش مشخص باشه و تغییرات یا رفتارهای مشکوک در حافظه شناسایی بشه.
6. جلوگیری از بازخوانی خودکار خروجی‌های تولیدشده توسط عامل: برای جلوگیری از آلودگی خودتقویتی یا Bootstrap Poisoning نباید خروجی‌های تولیدشده توسط عامل بطور خودکار دوباره وارد حافظه معتبر بشن.
7. مقاومت و بررسی صحت عملکرد: از تست‌های خصمانه استفاده کنید، نسخه‌های ذخیره‌شده (Snapshot) و بازگردانی (Rollback) داشته باشید، کنترل نسخه اعمال کنید و برای اقدامات پرخطر بررسی انسانی لازم باشه. اگر از حافظه یا بردارهای مشترک استفاده میکنید، از فضای نام و امتیاز اعتماد برای هر ورودی استفاده کنید و حافظه‌های تاییدنشده رو با گذشت زمان کاهش بدید یا قرنطینه کنید.
8. منقضی کردن حافظه تاییدنشده: حافظه‌ای که اعتبار آن تأیید نشده، باید منقضی بشه تا اثرات مسموم‌سازی طولانی‌مدت کاهش پیدا میکنه.
9. وزن‌دهی به داده‌ها بر اساس اعتماد و مالکیت (Tenancy): برای دسترسی به حافظه با تأثیر بالا، حداقل دو عامل بررسی بشه (مثلاً امتیاز منبع + تگ تاییدشده توسط انسان) و داده‌های کم‌اعتماد به مرور زمان کاهش پیدا کنه.

 

ASI07: Insecure Inter-Agent Communication

سیستمهای چندعامله برای انجام کارها به ارتباط مداوم بین عامل‌های مستقل متکی هستن. این ارتباط معمولا از طریق APIها، صف یا Message Bus و حافظه‌های مشترک انجام میشه. این ساختار باعث میشه سطح حمله بطور قابل توجهی افزایش پیدا کنه. معماری غیرمتمرکز، میزان متفاوت استقلال عاملها و سطوح نابرابر اعتماد بین اونا، باعث میشه مدل‌های امنیتی سنتی مبتنی بر محیط پیرامونی (Perimeter-based Security) کارایی لازم رو نداشته باشن. اگر کنترل‌های احراز هویت، یکپارچگی، محرمانگی یا مجوزدهی بین عامل‌ها ضعیف باشه، مهاجم میتونه پیام‌ها رو شنود، دستکاری، جعل یا مسدود کنه.

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

همچنین کانال‌های پنهان یا جانبی (Side/Covert Channels) هم وجود دارن که در اونا عامل‌ها از طریق زمان‌بندی یا الگوهای رفتاری ناخواسته اطلاعاتی رو افشا یا استنباط میکنن.

این تهدید با ASI03 که روی اعتبارنامه‌ها و سطح دسترسی تمرکز داره، ASI06 که روی تخریب دانش ذخیره‌شده تمرکز داره، متفاوت است.ASI07 مشخصا روی دستکاری پیام‌های زنده و بلادرنگ بین عامل‌ها تمرکز داره که میتونه منجر به اطلاعات نادرست، سردرگمی در سطح دسترسی یا هماهنگی مخرب در سیستم‌های عامل‌محور توزیع‌شده بشه. این مورد در چارچوب Agentic Threats and Mitigations با T12: Agent Communication Poisoning و T16: Insecure Inter-Agent Protocol Abuse پوشش داده میشه.

 

نمونه‌های رایج از این آسیب‌پذیری

• کانالهای بدون رمزگذاری و دستکاری معنایی: مهاجم MITM، پیامهای رمزگذاری‌ نشده رو شنود و دستورات مخفی تزریق میکنه که هدف و منطق تصمیم‌گیری عامل رو تغییر میده.
• دستکاری پیام و آلودگی بین زمینه ها: پیامهای تغییر یافته یا تزریق‌شده باعث تداخل وظایف عامل‌ها میشه و منجر به نشت داده یا سردرگمی در اهداف میشه.
• حملات Replay روی زنجیره‌های اعتماد: پیامهای قدیمیِ مربوط به واگذاری دسترسی یا اعتماد، دوباره ارسال میشن تا عامل‌ها رو فریب بدن و مجوزهای نامعتبر صادر بشه.
• Downgrade پروتکل و جعل توصیف‌گر عامل‌ها: مهاجم عاملها رو مجبور میکنه از حالتهای ارتباطی ضعیف‌تر استفاده کنن یا اطلاعات جعلی از عاملها ارائه میدن تا دستورات مخرب، معتبر به نظر برسن.
• حملات مسیریابی پیام در فرآیند کشف و هماهنگی: ترافیک کشف عامل‌ها به سمت عامل‌های مخرب هدایت میشه و روابط جعلی یا هماهنگی غیرمجاز ایجاد میشه.
• تحلیل متادیتا برای پروفایل‌سازی رفتاری: الگوهای ترافیکی میتونن چرخه‌های تصمیم‌گیری و روابط بین عامل‌ها رو آشکار کنن و زمینه پیش‌بینی یا دستکاری رفتار اونارو فراهم کنن.

 

سناریوهای نمونه حمله

• تزریق معنایی از طریق ارتباط بدون رمزگذاری: مهاجم MITM از طریق HTTP یا کانال‌های بدون احراز هویت، دستورات مخفی وارد پیامها میکنه و عامل‌ها، خروجی‌های مخرب تولید میکنن، بدون اینکه غیرعادی به نظر برسن.
• مسموم‌سازی اعتماد با دستکاری پیام‌ها: در یک شبکه معاملاتی مبتنی بر عامل‌ها، پیام‌های اعتبار یا Reputation دستکاری میشن و عاملهای نامعتبر به‌عنوان منابع قابل اعتماد انتخاب میشن.
• سردرگمی زمینه با حمله Replay: پیام‌های قدیمی مربوط به وضعیت اضطراری دوباره پخش میشن و باعث اجرای رویه‌های منسوخ و تخصیص نادرست منابع میشن.
• دستکاری هدف از طریق Downgrade پروتکل: اجبار به استفاده از حالت قدیمی و بدون رمزگذاری باعث میشه مهاجم اهداف و پارامترهای ریسک رو تزریق کنه و توصیه‌های خطرناک تولید بشه.
• Agent-in-the-Middle با مسموم‌سازی MCP Descriptor: یک نقطه پایانی MCP مخرب با توصیف‌گر جعلی و قابلیتهای دروغین معرفی میشه و پس از جلب اعتماد، داده‌های حساس رو از مسیر زیرساخت مهاجم عبور میده.
• جعل رجیستر A2A: مهاجم یک عامل جعلی رو با ساختار مشابه در سرویس کشف، ثبت میکنه و ترافیک هماهنگی با سطح دسترسی بالا رو رهگیری میکنه.
• دوپارگی معنایی (Semantics split-brain): یک دستور واحد توسط عاملهای مختلف به نیتهای متفاوت تفسیر میشه و اقدامات متناقض اما ظاهرا معتبر انجام میگیره.

 

راهنمای پیشگیری و کاهش ریسک

1. امن‌سازی کانال‌های ارتباطی عامل‌ها: از رمزگذاری سرتاسری (End-to-End Encryption) همراه با اعتبارنامه مخصوص هر عامل و احراز هویت متقابل استفاده کنید. از PKI Certificate Pinning، Forward Secrecy و بررسی‌های دوره‌ای پروتکل برای جلوگیری از شنود یا جعل پیام‌ها بهره ببرید.
2. حفظ یکپارچگی پیام و محافظت معنایی: پیام‌ها رو بصورت دیجیتالی امضا کنید، هم محتوای پیام و هم زمینه ی اونها رو هش کنید و بررسی کنید که هیچ دستور مخفی یا دستکاری‌شده‌ای در زبان طبیعی وجود نداشته باشه. از روشهای Sanitization آگاه به زبان طبیعی و بررسی تغییرات نیت‌ها (Intent-Diffing) برای شناسایی تغییرات اهداف، پارامترها یا دستورات مخفی استفاده کنید.
3. ضد Replay آگاه به عامل‌ها (Agent-aware anti-replay): همه تبادلات پیام رو با Nonce، شناسه جلسه و Timestamp که به پنجره زمانی وظیفه مربوط هستن، محافظت کنید. Fingerprint یا Hash کوتاه‌مدت پیامها رو نگه دارید تا Replay بین زمینه های مختلف شناسایی بشه.
4. امنیت پروتکل و قابلیت‌ها: حالت‌های ضعیف یا قدیمی ارتباط رو غیرفعال کنید. نیاز به توافق اعتماد، مخصوص هر عامل داشته باشید و احراز هویت پروتکل رو به هویت عامل، پیوند بزنید. سیاست‌های نسخه و قابلیت‌ها رو در گیت‌وی یا میان افزار (Middleware) اعمال کنید.
5. محدود کردن استنباط از متادیتا: برای کاهش امکان تحلیل ترافیک، از پیام‌های با اندازه ثابت یا پدگذاری شده استفاده کنید، نرخ‌های ارتباطی رو هموار کنید و از زمان‌بندی‌های قطعی پیامها اجتناب کنید. این اقدامات ساده باعث میشن مهاجم نتونه تنها از طریق متادیتا، نقش یا چرخه تصمیم‌گیری عامل‌ها رو حدس بزنه، بدون نیاز به تغییر کامل پروتکل.
6. ثابت نگه داشتن پروتکل و اعمال نسخه‌ها: نسخه‌های مجاز پروتکل‌ها (مثل MCP، A2A، gRPC) رو تعریف و اعمال کنید. تلاش‌های Downgrade یا اسکیمای ناشناخته رو رد و بررسی کنید که هر دو طرف قابلیت‌ها و نسخه‌ها رو به صورت یکسان اعلام کنن.
7. محافظت از کشف و مسیریابی: همه پیام‌های کشف و هماهنگی رو با هویت رمزنگاری‌شده احراز هویت کنید. دایرکتوری‌ها رو با کنترل دسترسی و اعتبارسنجی امن کنید، هویت و نیت پیام‌ها رو از ابتدا تا انتها بررسی کنید و جریان‌های مسیریابی غیرعادی رو نظارت کنید.
8. اعتبارسنجی و ثبت عامل‌ها: از رجیستری‌ها یا بازارهایی استفاده کنید که هویت دیجیتال عامل، منبع و یکپارچگی توصیفگر رو تضمین کنن.کارت‌های عامل امضا شده و بررسی مداوم رو قبل از قبول پیام‌های کشف یا هماهنگی اعمال کنید. از رجیستری‌های PKI برای تایید هویت و اعتبارسنجی ویژگی‌های حیاتی عامل استفاده کنید.
9. قراردادهای دارای نوع و اعتبارسنجی اسکیما: از اسکیماهای نسخه‌بندی‌شده و دارای نوع با مخاطب مشخص برای هر پیام استفاده کنید. پیام‌هایی که اعتبارسنجی رو پاس نمی‌کنن یا تلاش برای Down-Conversion Schema، بدون اعلام سازگاری دارن، باید رد بشن. قراردادهای دارای نوع، ساختار رو تضمین میکنن، اما اختلاف معنایی بین عامل‌ها همچنان یک چالش است؛ بنابراین تمرکز کاهش خطر بر یکپارچگی، منبع و الگوهای کنترل‌شده ارتباط است نه تطابق کامل معنایی.

 

ASI08: Cascading Failures

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

توجه داشته باشید که این بخش روی پخش و تشدید خطاها تمرکز داره، نه روی منبع اصلی اونا. اگه خطا از طریق وابستگی آلوده، حافظه مسموم یا پیام جعلی رخ بده، ابتدا ASI04، ASI06 یا ASI07 رو بررسی کنید و سپس از ASI08 برای زمانی استفاده کنید که اون خطا در بین عامل‌ها، جلسات یا جریان‌های کاری منتشر شده و اثر قابل توجهی ایجاد کرده باشه.

علائم قابل مشاهده:

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

این نوع شکست‌ها میتونن سایر خطرات مهم در سیستم عامل‌محور رو تشدید کنن. برای مثال:Prompt Injection (LLM01:2025) و Excessive Agency (LLM06:2025) میتونن اجرای خودکار ابزارها رو فعال کنن و خطاها رو بدون بررسی انسانی منتشر کنن. Data and Model Poisoning (LLM04:2025) میتونه تصمیم‌ها رو در جلسات و جریان‌های کاری تحت تأثیر قرار بده. برای مقابله با این خطر، باید توانایی ردیابی، تعیین منبع و بررسی رفتارهای زنجیره‌ای از طریق ثبت وقایع مقاوم و مکانیزم‌های عدم انکار فراهم بشه تا انتشار خاموش خطاها جلوگیری بشه. با این حال، سرعت و دامنه انتشار خطا در سیستم‌های چندعاملی میتونه از توان انسان‌ها پیشی بگیره و برخی خطرات همچنان نیاز به ارزیابی دقیق دارن.

 

نمونه‌های رایج آسیب‌پذیری

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

 

سناریوهای نمونه حمله

• زنجیره معاملات مالی: Prompt Injection باعث میشه یک عامل تحلیل بازار، محدودیت ریسک رو بیش از حد بالا اعلام کنه و عامل‌های Position و Execution بدون کنترل انسانی معاملات بزرگ انجام بدن.
• انتشار پروتکل در حوزه سلامت: دستکاری در زنجیره تأمین داده‌ها باعث تغییر خودکار پروتکل‌ها و انتشار اونا در شبکه بدون بررسی انسانی میشه.
• خرابی هماهنگی ابری: مسمومیت حافظه یا داده‌ها باعث اضافه شدن دسترسی‌های غیرمجاز و بسترهای هزینه‌بر میشه و استقرار بدون تایید، تغییر انجام میده.
• اختلال در عملیات امنیتی: سرقت اعتبارنامه سرویس، باعث میشه هشدارهای واقعی نادیده گرفته بشن، کنترل‌ها غیرفعال بشن و گزارش‌های انطباق پاک بشن.
• شکست کنترل کیفیت (Quality Control (QC)) در تولید: حافظه آلوده باعث میشه سیستم QC محصولات معیوب رو تأیید کنه و محصولات سالم رد بشن؛ برنامه‌ریزی موجودی و زمان‌بندی بر اساس داده‌های نادرست بهینه‌سازی میشن.
• چرخه بازخورد خودکار برای رفع مشکلات: یک عامل اصلاح، هشدارها رو برای برآورده کردن SLA های تأخیر خاموش میکنه. یک عامل برنامه‌ریز، با کم‌شدن اعلان‌ها، بعنوان موفق رفتار میکنه و دامنه خودکارسازی رو گسترده‌تر میکنه، که ممکنِ نقاط کور رو در سراسر مناطق بیشتر کنه.
• قطع DNS در یک منطقه از یک ارائه‌دهنده ابر بزرگ میتونه هم زمان چند سرویس هوش مصنوعی که به DNS وابسته‌ هستن رو از کار بندازه و باعث زنجیره‌ای از شکست‌های عامل ها در سازمان‌های مختلف بشه.
• سیستم‌های دفاع سایبری عامل‌محور و فایروال‌ها: انتشار هشدار جعلی یا توهم در سیستم‌های چندعاملی باعث اقدامات غیرضروری و مخرب مانند خاموشی، رد دسترسی و قطع شبکه میشه.

 

راهنمای پیشگیری و کاهش ریسک

1. مدل Zero-Trust در طراحی برنامه: سیستم رو طوری طراحی کنید که تحمل خطا داشته باشه و از ابتدا فرض کنه ممکنِ LLMها، اجزای عامل‌محور و منابع خارجی دچار اختلال یا عدم دسترس‌پذیری بشن.
2. ایزوله‌سازی و مرزبندی اعتماد: عامل‌ها رو در محیط‌های ایزوله اجرا کنید، اصل حداقل دسترسی رو رعایت کنید، شبکه رو بخش‌بندی کنید، APIها رو محدود و هدفمند بسازید و از احراز هویت دوطرفه استفاده کنید تا از گسترش خطا جلوگیری بشه.
3. دسترسی لحظه‌ای و یکبار مصرف به ابزارها، همراه با بررسی در زمان اجرا: برای هر اجرای عامل، اعتبارنامه‌هایی با عمر کوتاه و محدود به همان وظیفه صادر کنید و هر فراخوانی ابزار با ریسک بالا رو قبل از اجرا، بر اساس قوانین امنیتی بصورت کد (Policy-as-Code) بررسی و تأیید کنید. این کار مانع میشه یک عامل آلوده یا منحرف، واکنش زنجیره‌ای در سایر عامل‌ها یا سیستم‌ها ایجاد کنه.
4. اجرای مستقل سیاست‌ها: برنامه‌ریزی (Planning) و اجرا (Execution) رو با استفاده از یک موتور سیاست‌گذاری خارجی از هم جدا کنید تا برنامه‌ریزی خراب یا آلوده، نتونه مستقیما به اقدامات مخرب منجر بشه.
5. اعتبارسنجی خروجی و کنترل انسانی: برای خروجی‌های پرریسک، از نقاط کنترل، عامل‌های حاکمیتی (Governance Agents) یا بازبینی انسانی استفاده کنید، قبل از اینکه این خروجی‌ها به مراحل بعدی منتقل بشن.
6. محدودسازی نرخ و پایش مداوم: دستورات یا اقدامات با سرعت انتشار بالا رو شناسایی کنید و در صورت مشاهده رفتار غیرعادی، اونارو محدود یا موقتا متوقف کنید.
7. کنترل شعاع تخریب: محافظ‌هایی مثل سهمیه‌بندی (Quota)، سقف پیشرفت، و قطع کننده مدار، بین برنامه‌ریز و اجراکننده پیاده‌سازی کنید تا در صورت خطا، دامنه آسیب محدود بمونه.
8. تشخیص انحراف رفتاری و حاکمیتی: تصمیم‌ها رو با خط مبنا (Baseline) و اهداف هم‌راستایی مقایسه کنید و هرگونه افت تدریجی کیفیت یا انحراف رفتاری رو علامت‌گذاری کنید.
9. تکرار با Digital Twin و دروازه سیاستی: اقدامات ثبت‌شده عامل‌ها در هفته گذشته رو در یک نسخه ایزوله‌شده از محیط عملیاتی (Digital Twin) دوباره اجرا کنید تا بررسی بشه آیا همان توالی میتونه باعث خرابی زنجیره‌ای بشه یا نه. هرگونه گسترش سیاست فقط در صورتی مجاز باشه که این تست‌ها از سقف‌های تعریف‌شده شعاع تخریب عبور نکنن.
10. ثبت رویداد و عدم‌انکارپذیری (Non-Repudiation): تمام پیام‌های بین عامل‌ها، تصمیم‌های سیاستی و نتایج اجرا رو در لاگ‌های زمان‌دار و دستکاری‌ناپذیر ثبت کنید که به هویت رمزنگاری‌شده عامل‌ها متصل باشن. برای هر اقدام منتشرشده، متادیتای زنجیره منشأ (Lineage) نگه دارید تا امکان تحلیل فارنزیک، بازگردانی (Rollback) و پاسخ‌گویی در زمان بروز خرابی‌های زنجیره‌ای فراهم بشه.

 

ASI09: Human-Agent Trust Exploitation

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

در سیستم‌های عامل‌محور، این خطر زمانی تشدید میشه که انسان‌ها بیش‌ازحد به پیشنهادهای خودکار یا توضیحاتی که قابل راستی‌آزمایی نیستن اعتماد کنن و بدون بررسی مستقل، اقدامات رو تأیید کنن. مهاجمان با سوءاستفاده از سوگیری به مرجع قدرت و توضیح‌پذیری متقاعدکننده میتونن نظارت انسانی رو دور بزنن و باعث نشت داده، خسارت مالی، آسیب‌های زنجیره‌ای و لطمه به اعتبار سازمان بشن.

در این حالت، عامل بعنوان یک تأثیر منفی نامرئی عمل میکنه؛ یعنی انسان رو به انجام اقدام نهایی (که از نظر ظاهری قانونی و ثبت‌شده است) سوق میده، اما نقش واقعی عامل در حمله از دید تحلیل‌های فارنزیک مخفی میمونه. سوگیری ناشی از اتوماسیون، اقتدار ظاهری عامل و نشانه‌های انسان‌گونه باعث میشه این سوءاستفاده مشروع به نظر برسه و تشخیص اون دشوار بشه. هرچه عامل مطمئن‌تر و مقتدرتر به نظر برسه، احتمال تصمیم‌گیری‌های خطرناک افزایش پیدا میکنه.

این مورد درباره برداشت اشتباه انسان یا وابستگی بیش‌ازحد به عامل است، در حالیکه ASI10 به انحراف نیت خود عامل می‌پردازه. این تهدید با LLM06:2025 Excessive Agency مرتبط است و میتونه ناشی از LLM01:2025 Prompt Injection, LLM05:2025 Improper Output Handling باشه یا به LLM09:2025 Misinformation منجر بشه. همچنین با تهدیدهای عامل‌محور در راهنمای Agentic AI Threats and Mitigations شامل (T7) Misaligned & Deceptive, (T8) Repudiation & Untraceability, (T10) Overwhelming the Human in the Loop هم‌راستاست.

 

نمونه‌های رایج آسیب‌پذیری

• توضیح‌پذیری ناکافی: وقتی منطق تصمیم‌گیری عامل شفاف نیست، کاربر مجبور به اعتماد کورکورانه میشه. مهاجمان میتونن از این اقتدار ظاهری برای اجرای اقدامات مخرب مثل استقرار کد آلوده، تأیید دستورات جعلی یا تغییر وضعیت سیستم بدون بررسی استفاده کنن.
• نبود تأیید نهایی برای اقدامات حساس: فقدان یک مرحله بررسی نهایی باعث میشه اعتماد کاربر مستقیماً به اجرا تبدیل بشه. در این حالت، مهندسی اجتماعی میتونه با یک پرامپت ساده منجر به انتقال مالی غیرقابل بازگشت، حذف داده‌ها، افزایش سطح دسترسی یا تغییر پیکربندی ناخواسته بشه.
• دستکاری احساسی: عامل‌های همدل یا انسان‌گونه میتونن از اعتماد احساسی کاربر سوءاستفاده کرده و اون رو به افشای اطلاعات محرمانه یا انجام اقدامات ناامن ترغیب کنن؛ که در نهایت به نشت داده، کلاهبرداری مالی و دستکاری روانی منجر میشه.
• توضیح‌پذیری جعلی: عامل توضیح‌هایی قانع‌کننده اما ساختگی ارائه میده تا منطق مخرب خودش رو مخفی کنه. انسان با تصور منطقی بودن تصمیم، اقدام ناامن رو تأیید میکنه و نتیجه اون میتونه نصب بدافزار، نفوذ به سیستم یا تغییرات غیرقابل بازگشت باشه.

 

سناریوهای نمونه حمله

• تروجان دستیار برنامه‌نویسی: یک دستیار کدنویسی آلوده، یک اصلاح ساده و تک‌خطی پیشنهاد میده؛ اما با اجرا، اسکریپت مخرب اطلاعات رو خارج کرده یا بکدور نصب میکنه.
• سرقت اعتبارنامه با فریب زمینه‌ای: یک عامل پشتیبانی IT که با تزریق پرامپت آلوده شده، کارمند جدید رو هدف قرار میده، به تیکت‌های واقعی اشاره میکنه تا معتبر به نظر برسه و بعدش نام کاربری و پسورد رو درخواست و سرقت میکنه.
• کلاهبرداری در پرداخت با دستیار مالی: یک فاکتور آلوده وارد سیستم مالی میشه. عامل پرداخت فوری به حساب مهاجم رو پیشنهاد میده، مدیر مالی اون رو تأیید میکنه و سازمان متحمل خسارت میشه.
• توضیح‌سازی جعلی در ارزیابی: عامل توضیحی ظاهرا منطقی برای یک تغییر پرریسک ارائه میده. بازبین بدون توجه به منبع مشکل (هک، مسموم‌سازی یا توهم)، اون رو تأیید میکنه و بدافزار یا تنظیمات ناامن اعمال میشه.
• توضیح‌پذیری تسلیح‌شده و قطعی سرویس: عامل هک‌شده با یک توضیح قانع‌کننده، تحلیل‌گر رو فریب میده تا دیتابیس عملیاتی رو حذف کنه و باعث قطعی فاجعه‌بار سرویس بشه.
• اعمال رضایت از طریق پیش‌نمایش فقط‌خواندنی: عامل پیش‌ نمایشی نشان میده که با باز شدن اون، وب‌هوک‌هایی فعال میشن؛ در حالیکه کاربر تصور میکنه فقط در حال مشاهده است.
• توصیه پرداخت جعلی: دستیار مالی که با فاکتور دستکاری‌شده آلوده شده، با اطمینان پرداخت فوری به حساب مهاجم رو توصیه میکنه. مدیر به تخصص عامل اعتماد کرده و بدون بررسی مستقل، انتقال رو تأیید میکنه.
• دستکاری تصمیم‌های درمانی: عامل مراقبتی که تحت تأثیر داده‌های مغرضانه یا آلوده است، تغییر نادرست دوز دارو رو پیشنهاد میده. پزشک به توضیح منطقی عامل اعتماد میکنه و بیمار در معرض خطر قابل اجتناب قرار میگیره.

 

راهکارهای پیشگیری و کاهش ریسک

1. تأییدهای صریح و چندمرحله‌ای: قبل از دسترسی به داده‌های بسیار حساس یا انجام اقدامات پرریسک، تأیید چندمرحله‌ای یا حضور انسان در حلقه تصمیم‌گیری رو الزامی کنید.
2. لاگ‌های غیرقابل تغییر: همه‌ی پرسش‌های کاربران و اقدامات عامل‌ها رو در لاگ‌های غیرقابل دستکاری ثبت کنید تا برای ارزیابی و تحلیل‌های فارنزیک قابل استفاده باشن.
3. تشخیص رفتاری: افشای داده‌های حساس در مکالمات یا ارتباطات عامل‌محور، و همچنین اجرای اقدامات پرخطر رو در طول زمان پایش کنید تا الگوهای مشکوک شناسایی بشن.
4. امکان گزارش تعاملات مشکوک: در سیستم‌های تعاملی با کاربر، یک خلاصه‌ی ریسک ساده و قابل فهم (نه توضیح‌های تولیدشده توسط مدل) نمایش دهید و گزینه‌ی مشخصی برای گزارش رفتار مشکوک یا دستکاری‌کننده‌ی عامل در اختیار کاربر قرار بدید. این گزارش میتونه باعث بررسی خودکار یا محدودسازی موقت قابلیتهای عامل بشه.
5. تنظیم تطبیقی سطح اعتماد: سطح خودمختاری عامل و میزان نظارت انسانی رو بصورت پویا و بر اساس ارزیابی ریسک تنظیم کنید. از نشانه‌های بصری مبتنی بر میزان اطمینان (مثل اطمینان پایین یا منبع تأییدنشده) استفاده کنید تا کاربران قبل از تأیید اقدامات مهم، مکث کرده و بررسی بیشتری انجام بدن. همچنین آموزش مستمر نیروهای انسانی درگیر در نظارت بر سیستم‌های عامل‌محور ضروری است.
6. منشأ محتوا و اجرای سیاست‌ها: به همه‌ی توصیه‌ها و داده‌های خارجی، فراداده‌های قابل راستی‌آزمایی مثل شناسه منبع، زمان ثبت و هش‌های یکپارچگی اضافه کنید. اعتبارسنجی امضای دیجیتال و بررسی سیاست‌ها در زمان اجرا رو اعمال کنید تا اقداماتی که منشأ معتبر ندارن یا خارج از محدوده تعریف‌شده عامل هستن، مسدود بشن.
7. جدا کردن پیش‌نمایش از اثر واقعی: در حالت پیش‌نمایش، هرگونه فراخوانی شبکه‌ای یا تغییر وضعیت سیستم رو مسدود کنید و در کنار اون، برچسب ریسک شامل منشأ داده و اثرات احتمالی رو به کاربر نمایش بدید.
8. ملاحظات انسانی و محافظت‌های رابط کاربری (UI): توصیه‌های پرریسک رو با نشانه‌های بصری مشخص مثل کادر قرمز، بنر هشدار یا درخواست تأیید مجدد متمایز کنید. بصورت دوره‌ای کاربران رو نسبت به الگوهای دستکاری و محدودیت‌های عامل‌ها آگاه کنید و در مسیرهای حساس، از زبان احساسی یا بیش‌ازحد متقاعدکننده پرهیز نمایید. آموزش و ارزیابی مستمر کارکنان برای درک یکسان این نشانه‌ها نیز اهمیت داره.
9. تشخیص انحراف از برنامه: توالی اقدامات عامل رو با جریان‌های کاری تأییدشده مقایسه کنید و در صورت مشاهده مسیرهای غیرعادی، حذف مراحل اعتبارسنجی یا ترکیب‌های جدید و مشکوک از ابزارها، هشدار صادر کنید؛ چرا که این موارد میتونن نشانه فریب یا انحراف تدریجی باشن.

 

ASI10: Rogue Agents

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

اقدامات این عامل‌ها ممکنِ بصورت جداگانه طبیعی و قانونی به نظر برسه، اما رفتار کلی و تجمعی اونها مخرب میشه و سیستم‌های سنتی مبتنی بر قوانین ثابت، قادر به مهار اون نیستن. هرچند انحراف اولیه میتونه با حملاتی مانند تزریق پرامپت (LLM01:2025)، AS01 یا AS04 شروع بشه، اما ASI10 روی از بین رفتن یکپارچگی رفتاری و حاکمیت عامل پس از شروع انحراف تمرکز داره، نه نقطه‌ی ورود اولیه.

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

برخلاف Excessive Agency (LLM06:2025)، که بر مجوزهای بیش از حد اعطا شده تمرکز داره، عامل‌های سرکش، خطر متمایزی از واگرایی رفتاری رو نشان میدن و میتونن به دلیل سرعت و مقیاس سیستم‌های عامل محور، تهدیدات داخلی رو تقویت کنن. این تهدید میتونه به Sensitive Information Disclosure (LLM02;2025), Misinformation (LLM09:2025) منجر بشه.

در راهنمای OWASP Agentic AI Threats and Mitigations، این مورد با T13 – Rogue Agents in Multi-Agent Systems شناخته میشه. در چارچوب OWASP AIVSS هم این ریسک بیشتر به حوزه‌های یکپارچگی رفتاری (BI)، امنیت عملیاتی (OS) و نقض انطباق (CV) مرتبط است و در استقرارهای حیاتی یا خودتکثیرشونده، شدت بالایی داره.

 

نمونه‌های رایج آسیب‌پذیری

• انحراف هدف و فریب : عامل از اهداف اصلی خود فاصله میگیره؛ در ظاهر مطیع است اما در عمل اهداف پنهان و فریبکارانه رو دنبال میکنه. این حالت معمولا به‌ دلیل تزریق غیرمستقیم پرامپت یا اهداف متناقض رخ میده.
• انحراف جریان کاری: عامل سرکش کنترل فرآیندهای معتبر و مورد اعتماد رو در دست میگیره و اونارو به سمت اهداف مخرب هدایت میکنه. در نتیجه، یکپارچگی داده و کنترل عملیاتی از بین میروه.
• هم‌دستی و خودتکثیری: عامل‌ها با یکدیگر هماهنگ میشن، سیگنال‌ها رو به شکل غیرمنتظره به اشتراک می‌ذارن یا بصورت خودکار در سیستم تکثیر میشن و تلاش‌های ساده برای حذف اونهارو بی‌اثر می‌کنن.
• دستکاری پاداش (Reward Hacking) و سوءاستفاده از بهینه‌سازی: عامل با سوءاستفاده از معیارهای ناقص پاداش، نتایج گمراه‌کننده تولید میکنه یا رفتارهای تهاجمی در پیش میگیره که با هدف اصلی سیستم هم‌راستا نیست.

 

سناریوهای نمونه حمله

• خروج خودکار داده پس از تزریق غیرمستقیم پرامپت: عامل پس از مشاهده یک دستور آلوده در وب، این رفتار رو یاد میگیره و حتی پس از حذف منبع مخرب، بصورت مستقل فایل‌های حساس رو اسکن و به سرورهای خارجی ارسال میکنه.
• عامل ناظر جعلی (نقض یکپارچگی): مهاجم یک عامل بررسی یا تأیید جعلی رو وارد یک جریان کاری چندعاملی میکنه. یک عامل حیاتی (مثلاً پردازش پرداخت) به این درخواست داخلی اعتماد کرده و وجوه یا تراکنش‌های جعلی رو تأیید میکنه.
• خودتکثیری از طریق APIهای تخصیص منابع: یک عامل اتوماسیون آلوده فریب داده میشه تا نسخه‌های غیرمجاز از خودش رو در شبکه ایجاد کنه؛ این کار باعث مصرف منابع و پایداری حمله میشه.
• دستکاری پاداش و از دست رفتن داده‌های حیاتی: عامل‌هایی که مأمور کاهش هزینه‌های ابری هستن، یاد می‌گیرن حذف بکاپ‌های عملیاتی سریع‌ترین راه رسیدن به هدف است و بصورت خودکار تمام داده‌های بازیابی حادثه رو حذف میکنن.

 

راهکارهای پیشگیری و کاهش ریسک

1. حاکمیت و لاگ گیری رویداد: لاگ گیری کامل، غیرقابل‌تغییر و امضاشده‌ی تمام اقدامات عامل‌ها، فراخوانی ابزارها و ارتباطات بین‌عاملی برای شناسایی نفوذ پنهان یا واگذاری‌های غیرمجاز.
2. ایزوله‌سازی و مرزهای اعتماد: تعریف Trust Zones با قوانین سخت‌گیرانه برای ارتباط بین اونا، استفاده از محیط‌های اجرای محدود (مثل کانتینرهای ایزوله) و اعمال اصل حداقل دسترسی برای APIها.
3. پایش و کشف رفتار غیرعادی: استفاده از مکانیزم‌های تشخیص رفتاری (مانند عامل‌های ناظر) برای بررسی رفتار عامل‌ها، شناسایی الگوهای هم‌دستی و سیگنال‌های جعلی و تشخیص اجرای بیش‌ازحد یا غیرعادی عملیات.
4. مهار و پاسخ سریع: پیاده‌سازی کلید قطع اضطراری (Kill Switch) و لغو سریع اعتبارنامه‌ها برای غیرفعال‌سازی فوری عامل‌های سرکش. قرنطینه عامل‌های مشکوک در محیط‌های ایزوله برای بررسی فارنزیک.
5. احراز هویت عامل و تضمین یکپارچگی رفتاری: استفاده از احراز هویت رمزنگاری‌شده برای هر عامل و تعریف خط‌مبنای رفتاری در کل چرخه عمر اون. پیوست مانیفست رفتاری امضاشده شامل توانمندی‌ها، ابزارها و اهداف مورد انتظار که قبل از هر اقدام توسط سامانه هماهنگ‌کننده بررسی میشه.
6. احراز دوره‌ای رفتار عامل‌ها: استفاده از تسک‌های چالشی، لیست امضاشده اجزای پرامپت و ابزارها، و اعتبارنامه‌های موقتی برای هر اجرا. مدیریت کلیدهای رمزنگاری باید امن باشه (مانند HSM/KMS)، با حداقل دسترسی، چرخش و ابطال منظم. کلیدها نباید مستقیماً در اختیار عامل‌ها باشن و عملیات امضا باید توسط هماهنگ‌کننده انجام بشه.
7. بازیابی و بازگشت امن به تولید: تعریف خط‌مبنای قابل اعتماد برای بازیابی عامل‌های قرنطینه‌شده یا اصلاح‌شده. قبل از بازگشت به محیط عملیاتی، احراز هویت مجدد، بررسی وابستگی‌ها و تأیید انسانی الزامی باشه.

 

منبع