عامل‌های هوش مصنوعی (AI Agents) با قابلیت حافظه پایدار (Persistent Memory) قرار است تجربه‌ای شخصی‌تر و هوشمندتر ارائه دهند، اما همین ویژگی می‌تواند به یک سطح حمله جدید برای دستکاری اطلاعات تبدیل شود. به‌تازگی پژوهشگران از شناسایی حمله MemGhost خبر داده‌اند؛ حمله‌ای که نشان می‌دهد چگونه مهاجمان می‌توانند با سوءاستفاده از حافظه عامل‌های هوش مصنوعی، اطلاعات جعلی را به‌عنوان داده‌ای معتبر در حافظه سیستم ذخیره کرده و عملکرد آینده این عامل‌ها را تغییر دهند. در این حمله MemGhost، مهاجمان تنها با ارسال یک ایمیل به کاربری که دستیار هوش مصنوعی او به صندوق ورودی ایمیل (Inbox) دسترسی دارد، می‌توانند عامل را فریب دهند تا یک واقعیت جعلی (False Fact) درباره کاربر را در حافظه خود ثبت کند، این تغییر مخفیانه را پنهان نگه دارد و باعث شود پاسخ‌های آینده سیستم بر اساس اطلاعات نادرست شکل بگیرند.

نحوه عملکرد دستیارهای هوش مصنوعی

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

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

عامل متن‌باز OpenClaw که در این پژوهش به‌عنوان هدف اصلی آزمایش بررسی شده است، وضعیت داخلی خود را در فایل‌های متنی ساده (Plain Text) ثبت می‌کند. برخی از این فایل‌ها شامل دستورالعمل‌های ثابت عامل مانند AGENTS.md می‌شوند و برخی دیگر اطلاعاتی مانند داده‌های مربوط به کاربر در فایل MEMORY.md را در خود دارند که عامل در طول تعامل با کاربر به دست آورده است.

این عامل در ابتدای هر نشست، اطلاعات اصلی این فایل‌ها را در کانتکست (Context) مدل بارگذاری می‌کند تا مدل بتواند در تعاملات بعدی از آن‌ها استفاده کند.

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

حمله با یک ایمیل

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

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

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

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

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

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

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

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

تولید خودکار ایمیل‌های حمله

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

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

نتایج آزمایش حمله MemGhost

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

در آزمایش‌هایی که عامل OpenClaw مبتنی بر GPT-5.4 وظایف خود را به‌صورت خودکار و بدون تعامل مستقیم با کاربر  انجام می‌داد، این حمله در 87.5 درصد از موارد موفق بود. همچنین هنگام آزمایش روی یک عامل مبتنی بر Claude Code SDK با مدل Sonnet 4.6، نرخ موفقیت حمله به 71.4درصد رسید.

البته تمام این آزمایش‌ها در محیط‌های کنترل‌شده و بر پایه بنچمارک (Benchmark) انجام شدند. در همه این سناریوها، فرض بر این بود که ایمیل از قبل به یک صندوق ورودی‌ رسیده است که عامل هوش مصنوعی آن را بررسی می‌کند. بنابراین، این پژوهش مشخص نمی‌کند که آیا یک پیلود واقعی می‌تواند از فیلترهای اسپم (Spam Filtering) و سازوکارهای احراز هویت فرستنده عبور کند و به صندوق ورودی کاربر برسد یا خیر.

ارزیابی حمله در سناریوهای مختلف

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

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

نمای کلی معماری فریم‌ورک WhisperBench

دلیل موفق نبودن روش‌های ساده حمله

به گفته پژوهشگران نسخه‌های ساده و ابتدایی این حمله معمولاً موفق عمل نمی‌کنند. برای مثال، اگر در یک ایمیل به‌طور مستقیم از عامل هوش مصنوعی خواسته شود «این اطلاعات را مخفیانه ذخیره کن و چیزی به کاربر نگو»، مدل‌های پیشرفته در بیشتر موارد چنین دستوری را شناسایی کرده یا نادیده می‌گیرند. به گفته پژوهشگران، عامل اصلی افزایش نرخ موفقیت این حمله، مولد آموزش‌دیده (Trained Generator) است؛ ابزاری که می‌تواند ایمیل‌هایی تولید کند که احتمال عبور آن‌ها از مکانیزم‌های دفاعی بسیار بیشتر است.

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

چرا هنوز پچی برای این حمله MemGhost وجود ندارد؟

به گفته پژوهشگران، در حال حاضر نباید منتظر انتشار یک پچ سریع برای این حمله بود. دلیل این موضوع به سیاست امنیتی (Security Policy) پروژه OpenClaw برمی‌گردد. بر اساس این سیاست، تزریق پرامپت (Prompt Injection) به‌تنهایی یک آسیب‌پذیری محسوب نمی‌شود؛ مگر اینکه بتواند محدودیت‌هایی مانند احراز هویت، سیاست ابزارها (Tool Policy)، تأیید کاربر یا سندباکس (Sandbox) را دور بزند.

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

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

راهکارهای پیشنهادی برای کاهش ریسک

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

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

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

پاسخ OpenClaw به نتایج پژوهش

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

همچنین OpenClaw تأکید کرد انتخاب مدل نیز می‌تواند بر نتیجه حمله تأثیر بگذارد. در این پژوهش آزمایش‌ها با GPT-5.4 انجام شده‌اند، اما پژوهشگران به دلیل هزینه بالای اجرای آزمایش‌ها، مدل Claude Opus 4.6 را بررسی نکرده‌اند. این شرکت به چالش عمومی HackMyClaw نیز اشاره کرد؛ چالشی که در آن هزاران ایمیل مبتنی بر تزریق پرامپت (Prompt Injection) نتوانستند اطلاعات محرمانه یک عامل مبتنی بر Opus 4.6 را استخراج کنند. البته OpenClaw نیز اذعان کرد که هدف آن آزمایش، ارزیابی مقاومت در برابر سرقت داده بوده است، نه آلوده‌سازی حافظه (Memory Poisoning)؛ بنابراین نتایج آن را نمی‌توان مستقیماً با یافته‌های این پژوهش مقایسه کرد.

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

پیشینه این روش حمله

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

پس از افشای این پژوهش، OpenAI مسیر افشای اطلاعات را مسدود کرد، اما امکان ثبت اطلاعات در حافظه از طریق محتوای غیرقابل اعتماد همچنان باقی ماند.

یک سال بعد، این نوع حمله به یک محصول تجاری نیز راه پیدا کرد. آسیب‌پذیری EchoLeak با شناسه CVE-2025-32711 که در ژوئن 2025 توسط شرکت Aim Security افشا شد، از یک ایمیل حاوی متن پنهان (Hidden Text) استفاده می‌کرد تا Microsoft 365 Copilot را وادار کند هنگام پاسخ به یک سؤال عادی کاربر، اطلاعات داخلی سازمان را افشا کند.

مایکروسافت پس از ارزیابی این آسیب‌پذیری به‌عنوان یک تهدید بحرانی (Critical)، پچ لازم را برای رفع آن منتشر کرد. همچنین تاکنون هیچ گزارشی مبنی بر سوءاستفاده از این آسیب‌پذیری در دنیای واقعی منتشر نشده است.

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

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

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

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

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

آزمایش حمله در شرایط عملیاتی

پژوهشگران پس از انتشار مقاله، حمله MemGhost را در سناریویی نزدیک به شرایط واقعی نیز آزمایش کردند. در این آزمایش، یک حساب جیمیل واقعی از طریق Google OAuth و Gmail API به عامل OpenClaw متصل شد و پیلودها از یک حساب عادی جیمیل ارسال شدند. نتایج نشان داد ایمیل‌ها با موفقیت به صندوق ورودی  رسیدند و عامل هوش مصنوعی آن‌ها را پردازش کرد.

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

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

منابع

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *