زنیتی لبز (Zenity Labs) در ۸ اکتبر ۲۰۲۶ (۱۶ مهر ۱۴۰۵) پژوهشی با نام AgentCorruption دربارهٔ سرویس Amazon Bedrock AgentCore منتشر کرد. خلاصه‌اش این است: پژوهشگرانی که فقط می‌توانستند با یک عامل هوش مصنوعیِ عمومی چت کنند، با یک پرامپت به همهٔ عامل‌های دیگرِ AgentCore در همان حساب و همان ریجن AWS رسیدند. گفتگوهای خصوصی را خواندند، ایمیجِ کانتینرِ عامل‌ها را برداشتند، در حافظهٔ عامل‌ها خاطرهٔ جعلی کاشتند و رازها را از AWS Secrets Manager بیرون کشیدند.
AWS از آن زمان دسترسی‌های پیشفرض را محدود کرده و زنیتی میگوید مشکلات گزارششده وصله شده‌اند. پس این خبرِ «امشب وصله کنید» نیست. یک درسِ طراحی است و برای هر تیمی که عامل هوش مصنوعی جلوی کاربر می‌گذارد، روی هر ابر و هر فریم‌ورکی، صدق میکند.
یک پرامپت چطور به نفوذ در کل ریجن رسید
هیچ حلقه‌ای از این زنجیره به باگ حافظه نیاز نداشت. فقط یک عامل لازم بود که ابزار درخواست وب داشته باشد و یک نقش (Role) با دسترسیِ زیادی. طبق گزارش زنیتی:
- پرامپت از عامل خواست نشانی متادیتای محلی، یعنی 169.254.169.254، را از داخل microVMِ خودش باز کند. این یک SSRF است که به‌جای کد با متن هدایت می‌شود.
- سرویس متادیتا اعتبارنامهٔ موقتِ نقشِ اجراییِ پیش‌فرضِ عامل را برگرداند.
- آن نقش اجازهٔ فهرست‌کردن گروه‌های لاگ را داشت و از آن‌جا شناسهٔ عامل‌های دیگرِ ریجن پیدا شد. مخزن‌های کانتینر هم به نام همین شناسه‌ها بودند، پس ایمیج‌ها هم قابل دریافت بودند.
- با
bedrock-agentcore:InvokeAgentRuntimeمی‌شد عامل‌های دیگر را صدا زد، باListEventsگفتگوهای همهٔ عامل‌ها و کاربران و نشست‌ها را خواند و باCreateEventحافظهٔ جعلی نوشت که رفتار نشست‌های بعدی را عوض می‌کرد. bedrock-agentcore:GetResourceApiKeyوsecretsmanager:GetSecretValueهم اعتبارنامهٔ سرویس‌های متصل را لو دادند.
بخش حافظه از همه مهم‌تر است. نشستِ دزدیدهشده تمام می‌شود، اما حافظهٔ آلوده روی هر کاربری که بعداً با آن عامل حرف بزند اثر می‌گذارد و هیچ ورود تازه‌ای هم در لاگ دیده نمی‌شود.
موضع AWS و این‌که چرا هر دو طرف تا حدی حق دارند
افشای این مشکل تقریباً یک سال طول کشید. زنیتی دسترسی به متادیتا را ۲۵ دسامبر ۲۰۲۵ و نقشِ پیش‌فرضِ بیش از حد گسترده را ۱۲ ژانویهٔ ۲۰۲۶ گزارش داد. AgentCore در ۱۴ فوریه فقط به IMDSv2 محدود شد و تا ۲۹ سپتامبر، در بازبینی نهایی زنیتی، دسترسی‌های نقش پیشفرض بهطور جدی کم شده بود. بیانیهٔ AWS این رفتارِ متادیتا را مستند و مورد انتظار می‌داند.
واقعاً هم مستند است. صفحهٔ مدیریت اعتبارنامهٔ AgentCore صریحاً میگوید هر کد یا عاملی که داخل VM اجرا شود با صدا زدن نقطهٔ متادیتا به این اعتبارنامه‌ها دسترسی دارد و توصیه میکند اصل حداقل دسترسی رعایت شود، به‌خصوص با مدل‌های زبانی که می‌توانند کد دلخواه تولید کنند. مشکل این است که پیش‌فرض‌ها برنده می‌شوند. خیلی از تیم‌ها همان نقشی را که سرویس برایشان می‌سازد به تولید می‌برند و این‌جا نقش پیشفرض گسترده بود.
این هفته در تنظیمات عامل خودتان چه را بررسی کنید
- کادر پرامپت را یک کلاینت شبکه ببینید. اگر عامل می‌تواند نشانی وب باز کند، نشانی داخلی را هم باز میکند. بازه‌های link-local و خصوصی را در لایهٔ خروجی شبکه ببندید، نه در پرامپت سیستمی.
- برای هر عامل یک نقش جدا، محدود به منابع خودش. چت‌بات عمومی نباید دسترسی‌ای داشته باشد که به عامل‌های دیگر، حافظهٔ دیگران یا کل مخزن رازها اشاره کند. اول از همه wildcardها را از ARNها حذف کنید.
- رازها را از اعتبارنامهٔ خود عامل جدا کنید. اگر عامل کلید API لازم دارد، آن را در سرویس جداگانه‌ای بخوانید که مدل مستقیم با آن حرف نمی‌زند.
- عامل‌های عمومی و داخلی را جدا کنید، در حساب‌های جدا یا دست‌کم نقش‌هایی که نتوانند همدیگر را صدا بزنند.
- نوشتن در حافظه را قابل‌مشاهده کنید. هر رویداد حافظه را با نشستِ منبعش لاگ کنید و حافظه‌های بلندمدتِ تازه را مثل تغییر پیکربندی بازبینی کنید.
- فراخوانی‌های کسل‌کننده را زیر نظر بگیرید. نقشِ یک چت‌بات که ساعت ۳ بامداد گروه‌های لاگ را فهرست میکند یا راز می‌خواند، نشانهٔ روشنی است. برایش هشدار بگذارید.
سمت ابزارهای همین مسئله را در چک‌لیست ممیزی سرورهای MCP مخرب بررسی کرده‌ایم: هر چیزی که عامل می‌تواند صدا بزند، مهاجمی که با عامل حرف می‌زند هم می‌تواند.
فن‌مایند کجای این تصویر است
فن‌مایند یک دستیار اسناد است، پس سطح در معرض خطرش از یک عامل عمومی با دسترسی شل کوچک‌تر است. قاعده‌ای که برایش داریم همانی است که AgentCorruption زیر پا می‌گذارد: مدل هیچ‌وقت بیش از کسی که سؤال می‌پرسد دسترسی ندارد. بازیابی اسناد پیش از رسیدن به مدل بر اساس مجوزهای همان کاربر فیلتر می‌شود، پاسخ باید به سند و صفحه استناد کند و جستجوی وب محدود است و برای همهٔ سؤال‌ها روشن نیست. سمت کنترل دسترسی را در چرا یک دستیار هوش مصنوعی عمومی نمی‌تواند همین‌طور اسناد سازمان را بخواند توضیح داده‌ایم. مدل هنوز ممکن است با یک پرامپت فریب بخورد. مهم این است که آن فریب به چه چیزی میرسد.
پرسش‌های متداول
آیا AgentCorruption هنوز قابل بهرهبرداری است؟
زنیتی میگوید AWS مشکلات گزارششده را وصله کرده و تا ۲۹ سپتامبر ۲۰۲۶ نقش پیشفرض AgentCore بهطور جدی تغییر کرده بود. عاملهایی که قبلاً با نقش سفارشیِ گستردهٔ خودتان مستقر کردهاید موضوع جداییاند و باید خودتان بررسیشان کنید.
اگر از AWS استفاده نمی‌کنم، این خبر به من ربطی دارد؟
بله. زنجیره ترکیبی است از تزریق پرامپت، ابزار درخواست وب و هویتی با دسترسی زیاد. همین الگو روی هر سکوی عامل که محیط اجرایش به سرویس متادیتا برسد یا اعتبارنامهٔ گسترده داشته باشد کار میکند.
مفیدترین اصلاح کدام است؟
نقش اجرایی را فقط به همان عامل و منابعی که واقعاً لازم دارد محدود کنید و درخواست‌های خروجی به نشانی‌های link-local و خصوصی را ببندید. این دو با هم اعتبارنامهٔ دزدیدهشده را تقریباً بی‌فایده می‌کنند.
چرا حافظهٔ آلوده از گفتگوی دزدیدهشده بدتر است؟
گفتگوی دزدیدهشده یک نشت یکباره است. حافظهٔ کاشتهشده رفتار عامل را برای همهٔ کاربران بعدی عوض میکند و شبیه رفتار عادی عامل به نظر میرسد، پس تا کسی مخزن حافظه را بازبینی نکند باقی میماند.
